We Keep Coding

Missing class from package within Netbeans when using Spire.Doc.jar for docx files

I downloaded and installed the free Spire.Doc.jar file to work with .docx files. When I run it within Netbeans the functionality works fine however when I attempt to build the program I am getting the following error:
warning: Supported source version 'RELEASE_6' from annotation processor 'org.eclipse.persistence.internal.jpa.modelgen.CanonicalModelProcessor' less than -source '1.8'
Note: Creating static metadata factory ...
error: com.sun.tools.javac.code.Symbol$CompletionFailure: class file for com.spire.doc.packages.spryOb$1
not found
An annotation processor threw an uncaught exception.
Consult the following stack trace for details.
java.lang.RuntimeException: com.sun.tools.javac.code.Symbol$CompletionFailure: class file for com.spire.doc.packages.spryOb$1 not found
I have added the .jar file to my class path however there appears to be a class file missing from the com.spire.packages location.
Does anyone know if this is a Netbeans issue or does it look like there is an issue with the .jar file? I find it strange that it works when I run it within Netbeans but the above error occurs when I attempt to build the project.

I managed to get my application to build. What I had to do was remove the following code from my class and then it worked:
document.getMailMerge().MergeImageField = new MergeImageFieldEventHandler()
{
#Override
public void invoke(Object sender, MergeImageFieldEventArgs args)
{
mailMerge_MergeImageField(sender, args);
}
};
private static void mailMerge_MergeImageField(Object sender, MergeImageFieldEventArgs field)
{
String filePath = field.getImageFileName();
if (filePath != null && !"".equals(filePath))
{
try
{
field.setImage(filePath);
}
catch (Exception e)
{
e.printStackTrace();
}
}
}
I'm not sure why it didn't work with this included however I got this code from the following website:
https://www.c-sharpcorner.com/article/how-to-perform-mail-merge-in-word-document-in-java/
therefore I will inform them in case this happens to someone else in the future.

gradlew build failed for the task test with clover plugin

This is a gradle project and integrate with clover plugin for the test coverage. We are using Mockito for unit test cases.
gradle version
------------------------------------------------------------
Gradle 4.10.2
------------------------------------------------------------
Build time: 2018-09-19 18:10:15 UTC
Revision: b4d8d5d170bb4ba516e88d7fe5647e2323d791dd
Kotlin DSL: 1.0-rc-6
Kotlin: 1.2.61
Groovy: 2.4.15
Ant: Apache Ant(TM) version 1.9.11 compiled on March 23 2018
JVM: 1.8.0_241 (Oracle Corporation 25.241-b07)
OS: Linux 4.14.35-1902.10.4.1.el7uek.x86_64 amd64
build.gradle
buildscript {
dependencies {
classpath 'com.bmuschko:gradle-clover-plugin:2.2.3'
}
//....
}
apply from: "${rootDir}/build-support/coverage.gradle"
coverage.gradle
apply plugin: 'com.bmuschko.clover'
dependencies {
clover 'org.openclover:clover:4.3.1'
}
clover {
testIncludes = ['**/*Test.java']
report {
html = true
xml = true
}
}
The issue is whenever if I run ./gradlew clean build without including coverage.gradle , it passes all the test cases and builds the project.
however, if I include the coverage.gradle it is failing for some of the test cases.
After I dbugged a bit deeper, found out that Mockito has class DefaultStubbingLookupListener
and throwing NPE at the below code:
private static List<Invocation> potentialArgMismatches(Invocation invocation, Collection<Stubbing> stubbings) {
List<Invocation> matchingStubbings = new LinkedList<Invocation>();
for (Stubbing s : stubbings) {
if (UnusedStubbingReporting.shouldBeReported(s)
&& s.getInvocation().getMethod().getName().equals(invocation.getMethod().getName())
//If stubbing and invocation are in the same source file we assume they are in the test code,
// and we don't flag it as mismatch:
&& !s.getInvocation().getLocation().getSourceFile().equals(invocation.getLocation().getSourceFile())) {
matchingStubbings.add(s.getInvocation());
}
}
return matchingStubbings;
}
on the above code s.getInvocation().getLocation().getSourceFile() is coming null and so it throws the NPE on equality.
While without using clover (or excluding coverage.gradle)
this gives me proper source file information, e.g. s.getInvocation().getLocation().getSourceFile() = SomeControllerTest.java
If I remove failing test cases, then with the above gradle and Clover configuration I'm getting the colver.db files and even the coverage report is also generated.
But those test cases cannot be removed as without clover it runs smoothly. Further I followed couple of documentations on configuring sourcesets, but its the same result.
I cannot provide the complete test cases code because of the obvious reasons, however, below is the snippet if it helps to look further:
#Test
public void demoTestCaseCodeSnippet() {
ArrayList<String> result = getSomeArrayList();
String s1 = "text1";
String s2 = "text2";
given(commandHelper.getObjectList(any(HashMap.class), eq(String.class), eq("payloadName")))
.willReturn(result);
given(commandHelper.getObject(any(HashMap.class), eq(String.class), eq("payloadName")))
.willReturn(s1);
given(commandHelper.getObject(any(HashMap.class), eq(String.class), eq("payloadName")))
.willReturn(s2); //-----(3)
verify(//some code)
}
I know the above test case is not much of help, but as I stated earlier, that Mockito is giving me NPE because sourceFile is null, I think it is true for all the test cases with clover plugin, some test cases which are passed just because , it did not run those Mockito code snippet above. The results are same for gradle versions 4.10.1 also.
Looking for help/suggestions.

Could not load JIntellitype.dll from local file system or from inside JAR

I am trying to use JIntellitype to listen to global hotkeys but I get this error:
Exception in thread "main"
com.melloware.jintellitype.JIntellitypeException: Could not load
JIntellitype.dll from local file system or from inside JAR at
com.melloware.jintellitype.JIntellitype.(JIntellitype.java:114)
at
com.melloware.jintellitype.JIntellitype.getInstance(JIntellitype.java:177)
at utils.HotKey.(HotKey.java:19) at
ui.Main.Catch_Hotkeys(Main.java:78) at ui.Main.(Main.java:20)
at ui.Main.main(Main.java:15) Caused by: java.io.IOException:
FromJarToFileSystem could not load DLL:
com/melloware/jintellitype/JIntellitype.dll at
com.melloware.jintellitype.JIntellitype.fromJarToFs(JIntellitype.java:150)
at
com.melloware.jintellitype.JIntellitype.(JIntellitype.java:105)
... 5 more Caused by: java.lang.NullPointerException at
com.melloware.jintellitype.JIntellitype.fromJarToFs(JIntellitype.java:146)
... 6 more
I have loaded the jar file and I also pointed to the folder where the dlls are located through Referenced Libraries.
Here is the code I am trying to run:
import com.melloware.jintellitype.HotkeyListener;
import com.melloware.jintellitype.IntellitypeListener;
import com.melloware.jintellitype.JIntellitype;
public class HotKey extends Thread implements HotkeyListener, IntellitypeListener {
private final int CTRL_C_SHIFT = 10;
public HotKey()
{
JIntellitype.getInstance().unregisterHotKey(CTRL_C_SHIFT);
JIntellitype.getInstance().registerHotKey(CTRL_C_SHIFT, JIntellitype.MOD_CONTROL + (int)'C', JIntellitype.MOD_SHIFT);
if (!JIntellitype.isJIntellitypeSupported())
{
System.exit(1);
}
}
#Override
public void onIntellitype(int arg0)
{
}
#Override
public void onHotKey(int key)
{
if (key == CTRL_C_SHIFT)
{
System.out.println("smg");
}
}
}
Any idea how to fix this?

Your problem will occur because of a version problem between that OS version and the JRE version.
You should check:
Whether an appropriate dll file is installed in your OS system folder.
JIntellitype package has two dll files, one is for 32bit OSs and the other is for 64bit OSs, they have different names.
Check your Java Platform version in the properties of the projects.
You can try to change the Java Platform, if there are more than one types of JDKs.
Make sure about which one is for 64bit or 32bit version.
Have good luck!

I recommend you do something like this:
try
{
JIntellitype.getInstance().unregisterHotKey(CTRL_C_SHIFT);
MyHotKeyListener hotKeyListener = new MyHotKeyListener();
hotKeyListener.addObserver(new MyEventListener());
JIntellitype.getInstance().addHotKeyListener(hotKeyListener);
JIntellitype.getInstance().registerHotKey(CTRL_C_SHIFT, JIntellitype.MOD_CONTROL + (int)'C', JIntellitype.MOD_SHIFT);
}
catch (JIntellitypeException je)
{
logger.warn("JIntellitype initialization failed.");
// DO WHATEVER (NOTIFY USERS?)
}
I can point to other threads, including one where the creator of this library himself denies problems with the library. However, many users such as myself encounter these sort of problems from time to time where JIntellitype fails to initialize and the only solution is to reboot the computer. Because of this, you should catch the JIntellitype exception (the only exception thrown by the library) and warn users (via dialog window) that the hotkey failed to register. You should give them the option to continue without them, or to reboot the computer and trying again.
Trust me.... unless this is a constant problem (which means you configured it incorrectly), it is your best alternative. This WILL happen from time to time at random.

fatal error: webkit2/webkit2.h: No such file or directory

On Arch Linux, after upgrading to Gnome 3.14, I have several troubles with Webkit2Gtk.
Vala:
Consider the following vala test:
using Gtk;
using WebKit;
public class ValaWebkit : Window {
private WebView web_view;
public ValaWebkit(){
this.title = "Testing youtube";
set_default_size (800, 600);
web_view = new WebView();
add(web_view);
//this.web_view.open ("http://www.youtube.com/");
this.web_view.load_uri ("https://www.youtube.com/");
}
public static int main (string[] args) {
Gtk.init (ref args);
new ValaWebkit().show_all();
Gtk.main();
return 0;
}
}
Before upgrading to Gnome 3.14, I could copile like this valac --pkg gtk+-3.0 --pkg webkit2gtk-3.0 --vapidir . valawebkit.vala (I'm not pasting here webkit2gtk-3.0.vapi because it's too long). Now with gnome 3.14 if I try to compile i get
/home/luca/Sources/vala/webkit test/valawebkit.vala.c:8:29: fatal error: webkit2/webkit2.h: No such file or directory
#include <webkit2/webkit2.h>
^
compilation terminated.
error: cc exited with status 256
Compilation failed: 1 error(s), 0 warning(s)
Also, If I try to run the binary that I had compiled BEFORE upgrading to Gnome 3.14, I get this error:
./valawebkit: error while loading shared libraries: libwebkit2gtk-3.0.so.25: cannot open shared object file: No such file or directory
2) GJS / Eclipse / Java (SWT):
If I run either this gjs example, or eclipse (luna) or any other swt 4.4 based app, I get the following:
No bp log location saved, using default.
[000:000] Cpu: 6.58.9, x4, 2600Mhz, 7847MB
[000:000] Computer model: Not available
[000:000] Browser XEmbed support present: 1
[000:000] Browser toolkit is Gtk2.
[000:004] Using Gtk2 toolkit
[000:004] Warning(optionsfile.cc:47): Load: Could not open file, err=2
[000:004] No bp log location saved, using default.
I have the feeling that it is a kind of packaging issue on ArchLinux and Gnome 3.14. Does anyone is having the same issue? Is there a workaround both to compile and run against webkit2gtk?
EDIT
I made a little progress: I discovered that headers files I need are now under /usr/include/webkitgtk3.0 and /usr/include/libsoup-2.4. Now, compiling like this:
valac --pkg gtk+-3.0 --pkg webkit2gtk-3.0 --vapidir . --Xcc="-I/usr/include/webkitgtk-3.0" --Xcc "-I/usr/include/libsoup-2.4" --thread valawebkit.vala
works, but it sill fails on linker:
/tmp/ccQGhB3b.o: In function `vala_webkit_construct':
valawebkit.vala.c:(.text+0x6e): undefined reference to `webkit_web_view_new'
valawebkit.vala.c:(.text+0x101): undefined reference to `webkit_web_view_load_uri'
collect2: error: ld returned 1 exit status
error: cc exited with status 256
Compilation failed: 1 error(s), 0 warning(s)

There fact that you have to specify the --Xcc flags suggests that you are missing the pkgconfig file for WebKit. There should be a webkit2gtk-3.0.pc in /usr/lib/pkgconfig. The Arch package webkit2gtk has a pkgconfig file named webkit2gtk-4.0.pc. So, if you rename your VAPI file, that should link properly.

Actually with webkit2gtk-4.0 I don't need to provide a vapi file any more. So I can delete my webkit2gtk-4.0.vapi and complile like this (even simpler):
valac --pkg gtk+-3.0 --pkg webkit2gtk-4.0 --thread valawebkit.vala

Can I simulate a specific filesystem while unit testing?

I have been googling a little and did not find an answer which suited my specific case.
I am working on a project file manager classes, and discovered that it was developped to behave differently on Windows and Unix filesystems.
More specifically, it is compensating for the case-senstivity in Unix: when a file is not found, the manager will look for it in a case-insensitive way.
Before changing this code, I would like to implement some unit tests. However, our development machines and our CIP are both on Windows, and I have no Unix machine available. The machines and IDEs are provided by the customer. Virtualization is not an option, and dual-booting is even less.
Is there a way to test both Windows and Unix mode while being platform-independant for the build? I think the ideal would be to run the whole Test Class in a mode, and then in the other, but even a more hands-on solution would be great.
In production mode, the file managers are initialized using Spring, but they are the lowest level of the chain, using directly java.io.
Versions: Java 6, JUnit 4.9

You can use Jimfs with dependency
<dependency>
<groupId>com.google.jimfs</groupId>
<artifactId>jimfs</artifactId>
<version>1.1</version>
</dependency>
Then you could create a linux, windows and Mac file systems using
FileSystem fileSystem = Jimfs.newFileSystem(Configuration.osX());
FileSystem fileSystem = Jimfs.newFileSystem(Configuration.windows());
FileSystem fileSystem = Jimfs.newFileSystem(Configuration.unix());
example
class FilePathReader {
String getSystemPath(Path path) {
try {
return path
.toRealPath()
.toString();
} catch (IOException ex) {
throw new UncheckedIOException(ex);
}
}
}
class FilePathReaderUnitTest {
private static String DIRECTORY_NAME = "baeldung";
private FilePathReader filePathReader = new FilePathReader();
#Test
#DisplayName("Should get path on windows")
void givenWindowsSystem_shouldGetPath_thenReturnWindowsPath() throws Exception {
FileSystem fileSystem = Jimfs.newFileSystem(Configuration.windows());
Path path = getPathToFile(fileSystem);
String stringPath = filePathReader.getSystemPath(path);
assertEquals("C:\\work\\" + DIRECTORY_NAME, stringPath);
}
#Test
#DisplayName("Should get path on unix")
void givenUnixSystem_shouldGetPath_thenReturnUnixPath() throws Exception {
FileSystem fileSystem = Jimfs.newFileSystem(Configuration.unix());
Path path = getPathToFile(fileSystem);
String stringPath = filePathReader.getSystemPath(path);
assertEquals("/work/" + DIRECTORY_NAME, stringPath);
}
private Path getPathToFile(FileSystem fileSystem) throws Exception {
Path path = fileSystem.getPath(DIRECTORY_NAME);
Files.createDirectory(path);
return path;
}
}
All this copied from Baeldung.

You could dualboot Ubuntu easily by installing it with wubi.
I've learnt that unit-test should not access the file system for different reasons (speed being one of them).
For Java 6 look into theese:
http://docs.oracle.com/javase/6/docs/api/javax/tools/JavaFileManager.html
http://docs.oracle.com/javase/6/docs/api/javax/swing/filechooser/FileSystemView.html
If you were to use Java 7 this might help you:
http://download.oracle.com/javase/7/docs/technotes/guides/io/fsp/filesystemprovider.html

you could use a VM to test it on unix. Virtual Box by Oracle is agood virtualization software. Install Ubuntu, or Fedora, or some other unix based OS' Disk Image. Transfer your files to the VM. You can directly check out from your source control into the VM and you should be good to go. Atleast I am assuming that is what you want to do : test your software in both windows and linux, but currently don't have linux at your disposal