Develop Reference

How to change gtk to cocona, when SWT load native library?

I do not know why SWT load libswt-gtk-4332.jnilib. I used mac os and built SWT/Jface Project with Runnable Jar. I run Runnable Jar but I failed. Outputed the error log.
I executed it in mac:
java -jar -verbose threed-1.0-SNAPSHOT.jar
java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
no swt-gtk-4332 in java.library.path: [/Users/admin/Library/Java/Extensions, /Library/Java/Extensions, /Network/Library/Java/Extensions, /System/Library/Java/Extensions, /usr/lib/java, .]
no swt-gtk in java.library.path: [/Users/admin/Library/Java/Extensions, /Library/Java/Extensions, /Network/Library/Java/Extensions, /System/Library/Java/Extensions, /usr/lib/java, .]
Can't load library: /var/root/.swt/lib/macosx/x86_64/libswt-gtk-4332.jnilib
Can't load library: /var/root/.swt/lib/macosx/x86_64/libswt-gtk.jnilib
at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
at org.eclipse.swt.internal.C.<clinit>(Unknown Source)
at org.eclipse.swt.internal.Converter.wcsToMbcs(Unknown Source)
at org.eclipse.swt.internal.Converter.wcsToMbcs(Unknown Source)
at org.eclipse.swt.widgets.Display.<clinit>(Unknown Source)
at org.eclipse.swt.widgets.Widget.isValidSubclass(Unknown Source)
at org.eclipse.swt.widgets.Decorations.checkSubclass(Unknown Source)
at org.eclipse.swt.widgets.Shell.<init>(Unknown Source)
at org.eclipse.swt.widgets.Shell.<init>(Unknown Source)
at org.eclipse.jface.window.Window.createShell(Window.java:487)
at org.eclipse.jface.window.Window.create(Window.java:430)
at org.eclipse.jface.window.Window.open(Window.java:790)
at PlayerTableTree.run(Application.kt:20)
at ApplicationKt.main(Application.kt:303)
at ApplicationKt.main(Application.kt)

Solved. I used Jzy3d Library. Jzy3d SWT injected the gtk swt...
Thx for #greg-44, your comment was hint.

Java Web Start not working after updating Java 8u141 - java.lang.SecurityException: digest missing for org/apache/commons/httpclient

After updating Java 8u141, my java web start application, run by jnlp stopped working. Do not download the application. And throws these exceptions below. Can someone help me?
com.sun.deploy.net.JARSigningException: Could not verify resource signature: http://www.example.com/myjar.jar
at com.sun.deploy.security.JarVerifier.authenticateJarEntry(Unknown Source)
at com.sun.deploy.security.EnhancedJarVerifier.validate(Unknown Source)
at com.sun.deploy.cache.CacheEntry.processJar(Unknown Source)
at com.sun.deploy.cache.CacheEntry.access$2700(Unknown Source)
at com.sun.deploy.cache.CacheEntry$7.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
at com.sun.deploy.cache.Cache.downloadResourceToTempFile(Unknown Source)
at com.sun.deploy.cache.Cache.downloadResourceToCache(Unknown Source)
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Other:
java.lang.SecurityException: digest missing for org/apache/commons/httpclient
at sun.security.util.ManifestEntryVerifier.verify(Unknown Source)
at java.util.jar.JarVerifier.processEntry(Unknown Source)
at java.util.jar.JarVerifier.update(Unknown Source)
at java.util.jar.JarVerifier$VerifierStream.<init>(Unknown Source)
at java.util.jar.JarFile.getInputStream(Unknown Source)
at com.sun.deploy.security.JarVerifier.authenticateJarEntry(Unknown Source)
at com.sun.deploy.security.EnhancedJarVerifier.validate(Unknown Source)
at com.sun.deploy.cache.CacheEntry.processJar(Unknown Source)
at com.sun.deploy.cache.CacheEntry.access$2700(Unknown Source)
at com.sun.deploy.cache.CacheEntry$7.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source)
at com.sun.deploy.cache.Cache.downloadResourceToTempFile(Unknown Source)
at com.sun.deploy.cache.Cache.downloadResourceToCache(Unknown Source)
at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

I managed to solve this same issue yesterday. This is what worked for me:
Use 7-Zip to open the original, unsigned jar which is throwing the JARSigningException. Probably a good idea to make a copy of the jar first in case anything goes wrong.
Open the META-INF folder and copy MANIFEST.MF somewhere to your PC.
Open the MANIFEST.MF copy in a text editor. Look for a line that says something like "Name: org/apache/commons/httpclient". There could be a few lines like this, depending on the jar. Below this line will probably be other lines like "Implementation-Vendor:...", "Specification-Title:...", etc. In any case, delete all "Name:..." lines and all the subsequent lines in each block.
Save the file, and replace the existing MANIFEST.MF in the jar with the edited version. 7-Zip allows files to be replaced inside jars in-situ.
Re-sign the jar and deploy.
It seems when jars get signed, the "Name:" lines in the manifest can wind up in the middle of the signed classes, which only now seems to be a problem with the release of Java 8u141 but were obviously fine before.

The issue is already fixed in 8u144, please upgrade to 8u144 to avoid this issue http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

I had the same problem with the commons-httpclient-3.1.jar library. Actually I believe it's a bug in the web start, as It worked before and it works with the 8u152 early access. The solution I described here!

The issue is observed in signed JAR files whose manifest contains package version information[1] and does not have a trailing "/" in the name of the package (e.g.: Name: org/apache/xml/resolver). While we work towards resolving this issue, in the interim, users can work-around the issue as follows:
NOTE: We recommend use of this workaround only if the distributor of the JAR files can "re-sign" the JAR files.
Extract the contents of the signed JAR file (e.g.: jar xf jar-file ).
Modify META-INF/MANIFEST.MF file and add a trailing “/” to the name of the package ( e.g.: Name: org/apache/xml/resolver/).
Remove the current signature files ( e.g.: rm -f META-INF/.SF META-INF/.RSA META-INF/*.DSA ).
Recreate the JAR file ( e,g.: jar cfm jar-file META-INF/MANIFEST.MF input-file(s) ).
NOTE: You must use the jar utility. Other jar creation tools might re-introduce the issue.
Re-sign the JAR file.
[1] https://docs.oracle.com/javase/8/docs/technotes/guides/versioning/spec/versioning2.html#wp91706
Source:
http://www.oracle.com/technetwork/java/javase/8u141-relnotes-3720385.html#KnownIssues

This bug is addressed as part of the bug JDK-8184993 and the fix will be available in an out-of-cycle release of JDK 8u144, which is scheduled to be released on later hours of July 26.

jniavutil.dll: Can't find dependent libraries

When i run the code from the following link, https://github.com/sagioto/LipReading/blob/master/lipreading-gui/src/main/java/edu/lipreading/gui/MainFrame.java ; I get the following error :
Exception in thread "Thread-6" java.lang.UnsatisfiedLinkError: C:\Users\Harish ram\AppData\Local\Temp\javacpp13384533628877\jniavutil.dll: Can't find dependent libraries
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(Unknown Source)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.load0(Unknown Source)
at java.lang.System.load(Unknown Source)
at com.googlecode.javacpp.Loader.loadLibrary(Loader.java:418)
at com.googlecode.javacpp.Loader.load(Loader.java:368)
at com.googlecode.javacpp.Loader.load(Loader.java:315)
at com.googlecode.javacv.cpp.avutil.(avutil.java:75)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at com.googlecode.javacpp.Loader.load(Loader.java:334)
at com.googlecode.javacv.cpp.avcodec.(avcodec.java:85)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at com.googlecode.javacpp.Loader.load(Loader.java:334)
at com.googlecode.javacv.cpp.avformat.(avformat.java:76)
at com.googlecode.javacv.FFmpegFrameRecorder.(FFmpegFrameRecorder.java:111)
at com.googlecode.javacv.FFmpegFrameRecorder.(FFmpegFrameRecorder.java:104)
at com.googlecode.javacv.FFmpegFrameRecorder.(FFmpegFrameRecorder.java:107)
at com.googlecode.javacv.FFmpegFrameRecorder.(FFmpegFrameRecorder.java:101)
at main.java.edu.lipreading.gui.LipReaderPanel.getVideoFromSource(LipReaderPanel.java:150)
at main.java.edu.lipreading.gui.VideoCapturePanel$1.run(VideoCapturePanel.java:89)
at java.lang.Thread.run(Unknown Source)
I dont understand what is wrong. Can anyone help me ?

The code tries to use the JavaCV wrapper for FFmpeg (FFmpegFrameRecorder) you need FFmpeg installed in your system in order to use it.
Take a look at the requirements section at the main page of JavaCV and the Quick Start for OpenCV and FFmepg too.

RDF-Gravity 1.0 - unable to launch the application

I was trying to install RDF-Gravity 1.0 on Windows 7 x64bit machine. The installation failed with a message Unable to launch the application. The exception in the Details/Exceptionis provided below. I will be thankful to you, if any body knows how to get over it.
java.lang.SecurityException: com.sun.deploy.net.JARSigningException: Found unsigned entry in resource: http://semweb.salzburgresearch.at/apps/rdf-gravity/jws/colt.jar
at com.sun.deploy.cache.CacheEntry.checkAllJarEntriesSigned(Unknown Source)
at com.sun.deploy.cache.CacheEntry.getJarFile(Unknown Source)
at com.sun.javaws.security.SigningInfo.check(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResourcesHelper(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResources(Unknown Source)
at com.sun.javaws.Launcher.prepareResources(Unknown Source)
at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main.access$000(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: com.sun.deploy.net.JARSigningException: Found unsigned entry in resource: http://semweb.salzburgresearch.at/apps/rdf-gravity/jws/colt.jar
... 15 more
Edited: I have followed the useful comments by Joshua and they look promising. Since I do not have much knowledge about JNLP, I could not figure out "How to make the Java Web Start application working with disabled cache?". Alternatively, having gone through a blog for rdf visualization tools, I have found something similar to RDF-Gravity called welkin, which also visualizes RDF.

The reason why the Webstart version of RDF Gravity does no longer work on some systems is that the certificate for the colt.jar is no longer accepted by some JVM versions. For those who are interested in details this thread explains why this is the case.
People who are affected by that can download the RDF Gravity version available here. The "rdf-gravity.jar" contained in the zip archive is a runable jar.
best
Rupert

Where does SWT write dll files on windows?

I cannot find on the Internet where SWT tries to write the dll files. I have a computer where the jar does not run only because SWT cannot write DLLs.
UPDATE 1
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.sun.javaws.Launcher.executeApplication(Unknown Source)
at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
at com.sun.javaws.Launcher.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
no swt-win32-3738 in java.library.path
no swt-win32 in java.library.path
Can't load library: \\ubz01fst\Students\User2010\Com\xxx\swt-win32-3738.dll
Can't load library: \\ubz01fst\Students\User2010\Com\xxx\swt-win32.dll
at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
at org.eclipse.swt.internal.Library.loadLibrary(Unknown Source)
at org.eclipse.swt.internal.C.<clinit>(Unknown Source)
at org.eclipse.swt.widgets.Display.<clinit>(Unknown Source)
at install.Main.main(Main.java:162)

I find out the answer myself.
Since SWT 3.3 you don't have to include the native (DLL) library anymore, because they are in the jar itself and they are unpacked as soon as the SWT library is called.
The DLL files are unpacked from the jar and placed in the ".swt" folder under your "System.getProperty("user.home")".
In my case the problem was that System.getProperty("user.home") is set to "\ubz01fst\Students\User2010\Com\xxx" which is a UNC path and that is not writable ( this often happen in companies or organizations computers ).
I donno for which reason the System.getProperty("user.home") in computers is taken from the environment variable "HOMESHARE" of Windows
The solution consists in changing the System.getProperty("user.home") with a writable path, for example:
System.setProperty("user.home", System.getenv("USERPROFILE"));
before calling any SWT code.

Ok, I found the solution. The problem was about the dll generation. I was using 3.7m5 version, I downloaded a previous version (3.7) and the application ran properly.
Regards.