I need to run a Java application, which we are trying to port to Java 6, on an NT box.
I manage to run java 5 on it (although not officially supported), but when I try to run java 6 I get the following error:
Exception in thread "main" java.lang.UnsatisfiedLinkError: C:\Program Files\Java\jre1.6.0_05\bin\awt.dll: The specified procedure could not be found
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at sun.security.action.LoadLibraryAction.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.awt.NativeLibLoader.loadLibraries(Unknown Source)
at sun.awt.DebugHelper.<clinit>(Unknown Source)
at java.awt.EventQueue.<clinit>(Unknown Source)
at javax.swing.SwingUtilities.invokeLater(Unknown Source)
at ui.sequencer.test.WindowTest.main(WindowTest.java:136)
Anybody has any idea how to solve this?
This persists even when I move the java executables to another directory with no spaces in its name.
p.s.
I know, I should upgrade, but it's not up to me or my company - this is a very very bug huge gigantic company we work with, and they intend to keep NT for another 5 years.
OK, Thanks for all the viewers and to #Roel Spiker and #Partyzant for their answers.
It can't be done. Not unless you install windows2000 on the NT box. This is because awt.dll fr J6SE uses new methods in User32.dll, which is part of the windows OS (linked to kernel.dll et al). Use the dll dependency walker and see for yourself.
Another possible solution is to alter OpenJDK slightly to use other methods available in windows NT.
Java SE 6 requires at least Windows 2000.
I you are not using a GUI, for instance AWT, Swing or SWT, you could try starting you application in headless mode. See http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/ for more information. To start java in headless mode, use java -Djava.awt.headless=true
It would take care of the UnsatisfiedLinkError. I don't know if that's the only obstacle though.
Related
I have a Java program that reads and processes HDF5 files. I got the below error when I ran it on Eclipse (windows OS), and had to add a run configuration VM argument (-Dncsa.hdf.hdf5lib.H5.hdf5lib=\jhdf5.dll) to add the library and run properly. Now I'm exporting a runnable Jar file I get the error again, likely because it doesn't inherit the VM argument.
java.lang.UnsatisfiedLinkError: no jhdf5 in java.library.path
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at ncsa.hdf.hdf5lib.H5.loadH5Lib(H5.java:347)
at ncsa.hdf.hdf5lib.H5.<clinit>(H5.java:274)
at ncsa.hdf.hdf5lib.HDF5Constants.<clinit>(HDF5Constants.java:28)
at ncsa.hdf.object.h5.H5File.<init>(H5File.java:99)
at ncsa.hdf.object.h5.H5File.<init>(H5File.java:132)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at ncsa.hdf.object.FileFormat.<clinit>(FileFormat.java:229)
at hdf5Tool.HDF5Interface.readNodeStructureH5(HDF5Interface.java:73)
at wizardPages.DREAMWizard$STORMData$1.run(DREAMWizard.java:340)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:122)
Based on this post, I see that two possible options are to create a shell script or application bundle to incorporate the VM argument.
However, I'm curious is there is a more simple way to identify the library for the runnable JAR file. Any suggestions?
Not sure if you have specific needs, but maybe check out jhdf.io it's a pure Java HDF5 library so doesn't require native libraries to be loaded. It should be simple to add to a Maven or Gradle project with standard dependencies.
It's quite an early stage but should support reading data from most HDF5 file, if it doesn't work open an issue.
Disclaimer: I am the author of jhdf so might be biased.
I'm taking over this guy application and he left me pretty much nothing, even the coding is not commented. With luck (and a bit of time), I was able to improve the app and make it run like a charm on my computer.
But I'm having a problem, which is annoying and prevent me from upgrading the app. My app can run fine on any machines installed with java version 1.7.0_21, but when I update to newer version (for now it's 1.7.0_60), the app can not run, it just keeps having this stupid error and I can not do anything to fix it.
Here is the error log:
RenderJob.run: internal exception
java.lang.UnsatisfiedLinkError: com.sun.prism.d3d.D3DContext.nSetBlendEnabled(JZ
Z)I
at com.sun.prism.d3d.D3DContext.nSetBlendEnabled(Native Method)
at com.sun.prism.d3d.D3DContext.initState(D3DContext.java:84)
at com.sun.prism.d3d.D3DResourceFactory.<init>(D3DResourceFactory.java:5
7)
at com.sun.prism.d3d.D3DPipeline.createResourceFactory(D3DPipeline.java:
150)
at com.sun.prism.d3d.D3DPipeline.getD3DResourceFactory(D3DPipeline.java:
156)
at com.sun.prism.d3d.D3DPipeline.findDefaultResourceFactory(D3DPipeline.
java:182)
at com.sun.prism.d3d.D3DPipeline.getDefaultResourceFactory(D3DPipeline.j
ava:204)
at com.sun.prism.GraphicsPipeline.getDefaultResourceFactory(GraphicsPipe
line.java:97)
at com.sun.javafx.tk.quantum.QuantumRenderer$3.run(QuantumRenderer.java:
143)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.runAndReset(Unknown Source)
at com.sun.prism.render.RenderJob.run(RenderJob.java:37)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at com.sun.javafx.tk.quantum.QuantumRenderer$PipelineRunnable.run(Quantu
mRenderer.java:98)
at java.lang.Thread.run(Unknown Source)
I found another issue which is similar
Unable to deploy JavaFX applicaiton with external libraries in a JAR
but I can not apply that in my case since this program/framework need to run from a .bat file (which is command line actually) to creat a bunch of report files and folders.
Wich JavaFX version you have attached to your app?
I suspect the attached JavaFX version is not compatible with 1.7.0_60. I had some equal issues with that.
But the exception is new to me (its some internal prism stuff)
It has been my experience that the JFXRT jar is tightly coupled to the JRE/JDK version.update that it comes bundled with (in the case of oracles jvm). This means that the application needs to be ran on a jvm version.update as it was pulled from. You should be able to work around this by using the prescribed methods of building found here, http://docs.oracle.com/javafx/2/deployment/packaging.htm.
In my project I want to capture image from my webcam.
I configured step by step following the instructions from this "OpenCV-JavaCV : eclipse project configuration windows 7" blog post.
After configuration is finished, i tested samples codes and the application found my webcam
SETUP: Setting up device 0
SETUP: Namuga 1.3M Webcam
SETUP: Couldn't find preview pin using SmartTee
SETUP: Capture callback set
SETUP: Device is setup and ready to capture.
and then i got an error which is .dll error.
I use windows 7 x64.
Exception in thread "Thread-2" java.lang.UnsatisfiedLinkError: C:\Users\Administrator\AppData\Local\Temp\javacpp153028723186\jniopencv_core.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.opencv_core.<clinit>(opencv_core.java:131)
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.javacpp.Loader.load(Loader.java:315)
at com.googlecode.javacv.cpp.opencv_core$CvArr.<clinit>(opencv_core.java:158)
at com.googlecode.javacv.VideoInputFrameGrabber.grab(VideoInputFrameGrabber.java:158)
at GrabberShow.run(GrabberShow.java:24)
at java.lang.Thread.run(Unknown Source)
How can i solve this problem?
Check whether your Opencv version and JavaCv versions are matching each other. You can check that on the readme file on javacv-bin it specifically say about the required version of the opencv.
Unsatisfied link means that not all native code libraries required by jniopencv_core.dll could be found.
Did you deploy them all or just jniopencv_core.dll?
I faced this problem on Windows XP and Windows 7, and this is how I fixed it on both platforms, using Netbeans 7.2:
Install all required software:
FFmpeg (32-bit shared): Zeranoe FFmpeg offers win32 builds. Download and extract ffmpeg-20121020-git-04bf2e7-win32-shared.7z. Place its content at C:\ffmpeg.
Note: make sure C:\ffmpeg\bin is a valid path.
OpenCV 2.4.2 (32-bit): download OpenCV-2.4.2.exe and extract it. Place its content at C:\opencv.
Note: make sure C:\opencv\build\x86\vc10\bin is valid path.
JavaCV 0.2: download javacv-0.2-bin.zip and extract it. Move the extracted folder to C:\javacv-bin.
Microsoft Visual C++ redistributable package (32-bit): download and install vcredist_x86.exe.
Configure the environment:
Edit the environment variable PATH and append the following paths at the end:
C:\ffmpeg\bin;C:\opencv\build\x86\vc10\bin
Now you ready to create a new Netbeans project and test your application. But before you compile it,dDon't forget to right-click the Libraries folder at the pProjects window* and click Add Jar/FOLDER to select all the .jar files located at C:\javacv-bin.
Make sure you have the vm arg -Djava.library.path=<path-to-native> that points to the directory with your dlls.
I'm trying to call JDIC from my application, but I can't get it to run. What files do I need and where? From what I've been able to gather from their site, I basically need to put jdic.jar in classpath... however there is also a lib folder with jdic.jar with a bit different size, and jdic_native_applet.jar, jdic_stub_unix.jar, jdic_stub_windows.jar and several folders with what I gather are platform specific files.
I get this exception when instantiating AssociationService:
java.lang.ClassNotFoundException: org.jdesktop.jdic.filetypes.internal.AppAssociationReaderFactory_windows
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at org.jdesktop.jdic.filetypes.AssociationService.<init>(Unknown Source)
at QuickTest.main(QuickTest.java:101)
I've tried last "official" release and last alpha release. I'm running Java 6 and Win7 64bit. Does JDIC even work under Win7 (or 64bit, although I use 32bit Java)? I see no release after 2006, and no activity in the project after about 2008... while Win7 came in 2009.
I know that parts of JDIC, like Desktop, were included in Java 6, however that doesn't seem to be the case with file associations.
And if it doesn't, are there any (hopefully cross-platform) alternatives for managing file associations? There are some things for Windows only that I tried, but that requires running native commands with administrator privileges which I don't know how to pull, apart from asking user to run my app as administrator and then use Runtime.exec()...
If there are no alternatives to JDIC, I'm interested if anyone has managed to handle file associations well with cross-platform installers?
UPDATE: OK, figured part of it... everything from windows folder needs to be in root folder. However now I get this exception which brings me back to my original question:
Exception in thread "main" java.lang.UnsatisfiedLinkError: D:\Sources\TheWorkspace\Test\jdic.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1778)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1703)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1030)
at org.jdesktop.jdic.init.JdicManager$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at org.jdesktop.jdic.init.JdicManager.loadLibrary(Unknown Source)
at org.jdesktop.jdic.filetypes.internal.WinRegistryWrapper.<clinit>(WinRegistryWrapper.java:36)
at org.jdesktop.jdic.filetypes.internal.WinRegistryUtil.isSubKeyExist(WinRegistryUtil.java:192)
at org.jdesktop.jdic.filetypes.internal.WinRegistryUtil.isFileExtExist(WinRegistryUtil.java:910)
at org.jdesktop.jdic.filetypes.internal.WinRegistryUtil.isFileExtExist(WinRegistryUtil.java:939)
at org.jdesktop.jdic.filetypes.internal.WinAppAssociationReader.isFileExtExist(WinAppAssociationReader.java:163)
at org.jdesktop.jdic.filetypes.AssociationService.getFileExtensionAssociation(Unknown Source)
at QuickTest.main(QuickTest.java:103)
Can you recheck the java you are using to run this? The error typically occurs when trying to load a 32-bit dll from a 64-bit java. jdic does work for us on 64-bit Windows 7 with 32-bit java.
I'm an Eclipse newbie and I'm trying to build a mixed AWT/SWT application. Here's my code:
public class HelloWorldSWT {
public static void main(String[] args) {
Frame frame = new Frame("My AWT Frame"); // java.awt.Frame
frame.setLayout( new BorderLayout() );
Canvas canvas = new Canvas(); // java.awt.Canvas
frame.add(canvas, BorderLayout.CENTER);
frame.setVisible(true);
Display display = new Display(); // display object to manage SWT lifecycle.
Shell swtShell = SWT_AWT.new_Shell(display, canvas);
Button m_button = new Button(swtShell, SWT.PUSH);
m_button.setText( "button" );
// invoke the AWT frame rendering by making the frame visible
// This starts the EDT
frame.setVisible(true);
// standard SWT dispatch loop
while(!swtShell.isDisposed())
{
if(!display.readAndDispatch())
display.sleep();
}
swtShell.dispose();
}
}
This compiles fine, but when I run it as application in Eclipse, I get the following error:
Exception in thread "main"
java.lang.UnsatisfiedLinkError:
sun.awt.SunToolkit.getAppContext(Ljava/lang/Object;)Lsun/awt/AppContext;
at
sun.awt.SunToolkit.getAppContext(Native
Method) at
sun.awt.SunToolkit.targetToAppContext(Unknown
Source) at
sun.awt.windows.WComponentPeer.postEvent(Unknown
Source) at
sun.awt.windows.WComponentPeer.postPaintIfNecessary(Unknown
Source) at
sun.awt.windows.WComponentPeer.handlePaint(Unknown
Source) at
sun.java2d.d3d.D3DScreenUpdateManager.repaintPeerTarget(Unknown
Source) at
sun.java2d.d3d.D3DScreenUpdateManager.createScreenSurface(Unknown
Source) at
sun.awt.windows.WComponentPeer.replaceSurfaceData(Unknown
Source) at
sun.awt.windows.WComponentPeer.replaceSurfaceData(Unknown
Source) at
sun.awt.windows.WComponentPeer.setBounds(Unknown
Source) at
sun.awt.windows.WWindowPeer.setBounds(Unknown
Source) at
sun.awt.windows.WComponentPeer.initialize(Unknown
Source) at
sun.awt.windows.WCanvasPeer.initialize(Unknown
Source) at
sun.awt.windows.WPanelPeer.initialize(Unknown
Source) at
sun.awt.windows.WWindowPeer.initialize(Unknown
Source) at
sun.awt.windows.WFramePeer.initialize(Unknown
Source) at
sun.awt.windows.WComponentPeer.(Unknown
Source) at
sun.awt.windows.WCanvasPeer.(Unknown
Source) at
sun.awt.windows.WPanelPeer.(Unknown
Source) at
sun.awt.windows.WWindowPeer.(Unknown
Source) at
sun.awt.windows.WFramePeer.(Unknown
Source) at
sun.awt.windows.WToolkit.createFrame(Unknown
Source) at
java.awt.Frame.addNotify(Unknown
Source) at
java.awt.Window.show(Unknown Source)
at java.awt.Component.show(Unknown
Source) at
java.awt.Component.setVisible(Unknown
Source) at
java.awt.Window.setVisible(Unknown
Source) at
HelloWorldSWT.main(HelloWorldSWT.java:20)
What am I doing wrong?
Since version 3.3, SWT automatically finds its required platform-specific libraries, which are inside the swt.jar (at the top level of the JAR contents). So all you need is swt.jar in the classpath, and it works.
One way to get an UnsatisifiedLinkError is if you're using a swt.jar for another platform -- they're all named "swt.jar"; for example, if you download the one for Linux, and try to use it on Windows. The project will compile OK since all the API-level code is the same Java for every platform, but it will fail when you run because the native libraries are wrong.
However, since the error in this case happens in AWT, it might be something else, not directly related to SWT. First, make sure you've downloaded the Windows SWT release. When you import it into your workspace, it creates an Eclipse project named org.eclipse.swt, which contains the swt.jar. You then make org.eclipse.swt a required project for your project, and nothing else in the Build Path besides a valid, clean JRE (you can try defining a new one [Window -> Preferences -> Java -> Installed JREs], or just use a different one you might have installed).
You can also test it from the shell/command window. Go to your project directory. The command should be as simple as:
java -cp bin;..\org.eclipse.swt\swt.jar HelloWorldSWT
I got your code to run (Vista-32, JDK 6_15), but the window opened really small, and would not close. I don't know anything about the SWT-AWT bridge though, so good luck with that....
The UnsatisfiedLinkError is indicating that a native library that you are relying upon is not found when you are trying to run your app. If you are compiling this in your IDE, then the library is in your build path. If you are running this from with your IDE and getting this error, the libray is not in your Run path. Check your Run Dialog to see that the libraries you have in your build path are in your run path.
As mentioned, this indicates that the JVM cannot find a native library. Since you're mixing AWT/SWT I assume that the JVM can't find the SWT libraries (.dll for windows, .so for linux, not sure for mac). I'm partial to using an system property to tell java where to look.
-Djava.library.path=<absolute path to the .dll/.so that SWT needs>
I have had exactly the same problem, and could only get it resolved by completely removing and re-installing Java. It seems that somehow, one of the DLLs, containing the native AWT methods, had managed to get screwed up.
I have had solved this problem,
I search this information for a long time,but i can't find one to solve my problem,
after i check my java version
i found that jdk and jre version is different,
for example
i found that one extra document on my file system
jdk 1.4 jre 1.4 jre 1.5(extra)
you should delete the new version of the jre(jre1.5)
then ok,my english is poor,i hope my message will do a favour,
if you have some question ,you can connect to me,email:fish2-2#163.com