The jawt.lib necessray to link for using of JAWT_GetAWT API.
I createded native "C" dll through this way
http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/8b04ee324a1a/test/java/awt/JAWT/myfile.cpp
My java code is
http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/8b04ee324a1a/test/java/awt/JAWT/MyCanvas.java
It is working fine in Window 7/8 64-bit OS with below code only.
For 32-bit OS, It gives below error.
java.lang.UnsatisfiedLinkError: C:\Users\Rovet.Sen\Des
ktop\POC\U\MyCanvas-32.dll: Can't find dependent libraries
It works fines in window7 32-bit os.
Now it is not working in window8 32-bit OS.
So due to the random behavior of this dll, I am try to find out the alternative for of JAWT_GetAWT API.
Is there any way to write own code for this API?
Thanks
As you don't tell which installation steps you did and where you get a problem. Find below the steps extracted from the link I already mentioned in the comment.
download the Java Access Bridge
as stated in the documentation, you don't need to for Java SE 7 Update 6 and later
install the files following the steps Installing Java Access Bridge for Windows 32-Bit
install means here
unzip the file accessbridge-2_0_2-fcs-bin-b06.zip
copy the extracted files to the given directories
run your example code
If step 3. fails, please provide us a MVCE - Minimal, Complete, and Verifiable Example
I've been using Java on OS X for many, many years and recently when Apple stopped including Java by default I let the OS go and install it for me (Apple's variety, of course).
So now I'm using OS X 10.8 and I need to install Java 7 so I just got Oracle's Update 15 in DMG form and ran the installer. It updated my /usr/bin/java (and related files) to point here:
/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands/java
Tracing this back to '/System/Library/Frameworks/JavaVM.framework/Versions' everything either points to 'Current' or 'CurrentJDK', the former being a link to 'A' (which is Oracle's Java 7, from what I can tell, not sure why it is 'A') and the latter being a link to Apple's Java 6 in '/System/Library/Java/JavaVirtualMachines/1.6.0.jdk'.
Now this is all really confusing but this isn't even my question yet. It appears there is a Java 7 installed here:
/System/Library/Frameworks/JavaVM.framework/Versions/A
But there is also a Java 7 installed here:
/Library/Java/JavaVirtualMachines/jdk1.7.0_15.jdk
Finding 'java' in both and printing out the version yields the same version and build (java version "1.7.0_15"), however, when hashing the files they are different.
So does this mean Oracle installed Java 7 in two different places? If so, why? Which am I supposed to use? And why do some things still point to Java 6 (CurrentJDK).
I've looked on Oracle's website but nothing there clears anything up.
Oracle's JVM is only installed in one location. You've been misled!
As you've noted, the Java commands in /usr/bin are symlinks to binaries in /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands. The binaries within that directory are stub applications that determine which Java VM to use*, and then exec the corresponding real binary within that VM version. This is why all of the binaries within /System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands are almost identical in size, despite the fact that you'd expect them to be implementing quite different functionality.
You can see this in action by using dtrace:
mrowe#angara:~$ sudo dtrace -n 'syscall::posix_spawn:entry { trace(copyinstr(arg1)); }' -c "/usr/bin/java -version"
dtrace: description 'syscall::posix_spawn:entry ' matched 1 probe
dtrace: pid 44727 has exited
CPU ID FUNCTION:NAME
8 619 posix_spawn:entry /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/bin/java
The given dtrace invocation prints out the path argument to posix_spawn when it is called by java -version. In my case the stub application has found Apple's Java 1.6 runtime in /System/Library/Java/JavaVirtualMachines/1.6.0.jdk and is invoking that version of the java command.
The stub binaries also have another benefit: when they detect that no Java VM is installed they will prompt the user to install one.
As for the CurrentJDK symlink, as best as I can tell this for sake of backwards-compatibility with the past when Apple was the only source of the JVM on OS X.
* A combination of factors are considered when determining which Java VM should be used. JAVA_HOME is used if set (try JAVA_HOME=/tmp java). If JAVA_HOME is not set then the list of all virtual machines on the system is discovered. The JAVA_VERSION and JAVA_ARCH environment variables are used, if set, to filter the list of virtual machines to a particular version and supported architecture. The resulting list is then sorted by architecture (preferring 64-bit over 32-bit) and version (newer is better), and the best match is returned.
The Oracle Java 7 JRE (i.e. the one that is used by the web browser plugin to run applets and Java Web Start) installs itself in /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home, and it is this one that any automatic updates will affect. The JDK (the one you download from http://www.oracle.com/technetwork/java/javase/downloads/index.html) installs by creating a directory under /Library/Java/JavaVirtualMachines, and it's up to you to update this yourself. You can have multiple JDK versions installed side by side but only one "public" JRE under JavaAppletPlugin.plugin (which will correspond to the latest installed JDK or a later version if it has been auto-updated since).
As explained by bdash, the commands under /usr/bin are stubs that delegate to whichever JDK/JRE is pointed to by the JAVA_HOME environment variable, or if that is not set then they will pick the most appropriate Java to run. You can use /usr/libexec/java_home to see which one the stubs would pick. If no Java is installed the stubs will offer to install the latest Apple Java 6 (as far as I know they will not offer to install Java 7).
I find this post:
https://developer.apple.com/library/mac/qa/qa1170/_index.html
The /usr/libexec/java_home tool dynamically finds the top Java version specified in Java Preferences for the current user.
I am trying to launch an application (not Eclipse) that was written in Java. When I do, I get an error that says "Failed to Load the JNI shared Library (JDK)" along with a path that points to the location of the file.
From searching Google and StackOverflow, all I can find are people saying that the Java version installed needs to match my machine. My machine is 64 bit and so is my java installation, so I don't think that is my issue.
I have also verified that C:\Program Files\Java\jre7\bin is in my path variable. Also, just for the record, I do not use Eclipse. I have also tried uninstalling and reinstalling Java an the application that was written in Java. Lastly, the file it is complaining about exists on the machine.
Does anyone know what else could be the cause of this problem?
Update:
Thanks for your responses. I got it resolved, but the resolution seems like more of a hack and goes against what I was reading earlier. I installed the 32 bit version of Java 7 along side of my 64 bit version of Java 7. I then added the path the 32 bit version to the system path variable.
After I did this, the application was able to launch. Is there an issue with having both 64 bit and 32 bit versions of Java 7 installed simultaneously?
This is an error from your application. The application uses JNI. It is complaining that it cannot load it. Why it says (JDK) only its author knows. You will have to ask the author.
There is no problem having both versions of Java installed. However, the application you were using probably shipped with a 32-bit version of the JNI library. So, it needed to be used with a 32-bit Java JRE.
I know JMF is pretty much dead and whatnot, but I do know that it can still be used.
I intend to use it for personal uses and don't expect that much from it.
I have managed to install the 32bit JMF and when I run JMStudio it somehow magically works even though all of my java jres and sdks are 64-bit.
I personally believe that this proves that it CAN work.
When creating a program importing the jmf.jar as a library, my code compiles perfectly.
Only at runtime do i get any form of error with the common:
Exception in thread "VFW Request Thread"
java.lang.UnsatisfiedLinkError: JMFSecurityManager:
java.lang.UnsatisfiedLinkError: C:\Program Files
(x86)\JMF2.1.1e\lib\jmvfw.dll: Can't load IA 32-bit .dll on a AMD
64-bit platform
Obviously there is a problem with using a 32bit dll on a 64bit system.
My question is if its not compatible:
how does JMStudio work perfectly fine (it definitely uses java)
how can I fix it so that my program can run without depending on this dll
or other workarounds
Thanks a ton to anyone who has ever tried this before.
Java is definitely lacking in native specific tools such as webcams.
I think the main issue is the 64bit Java JRE/JDK trying to use the 32bit JMF, and/or JMF having a problem with the path that Windows 7 chooses as a default to install it to.
I have had success following the instructions posted here:
Oracle Forums: Install JMF on Windows 7 64bit
It basically boils down to:
Install a 32bit JRE/JDK, and ensure that this is what your code uses.
Install JMF to simple directory in the root of C: (i.e. c:\JMF2.1.1e)
Good luck!
JMFStudio is 32 bit supporting software so we must install 32bit support JDK and also Eclipse then we not get any exceptions as you mentioned in above and errors.
For my case it works fine.
and also
Try to remove unused jdk path in environment variable, if duplicate path present then also it not works fine
other wise you should re-install OS.
We have a couple of applications running on Java 5 and would like now to bring in an application based on Java 6. Can both java versions live together under Windows?
Is there any control panel to set the appropriate Java version for different applications, or any other way to set up, what version of Java will be used to run that particular application?
Of course you can use multiple versions of Java under Windows. And different applications can use different Java versions. How is your application started? Usually you will have a batch file where there is something like
java ...
This will search the Java executable using the PATH variable. So if Java 5 is first on the PATH, you will have problems running a Java 6 application. You should then modify the batch file to use a certain Java version e.g. by defining a environment variable JAVA6HOME with the value C:\java\java6 (if Java 6 is installed in this directory) and change the batch file calling
%JAVA6HOME%\bin\java ...
I was appalled at the clumsiness of the CLASSPATH, JAVA_HOME, and PATH ideas, in Windows, to keep track of Java files. I got here, because of multiple JREs, and how to content with it. Without regurgitating information, from a guy much more clever than me, I would rather point to to his article on this issue, which for me, resolves it perfectly.
Article by: Ted Neward: Multiple Java Homes: Giving Java Apps Their Own JRE
With the exponential growth of Java as a server-side development language has come an equivablent
exponential growth in Java development tools, environments, frameworks, and extensions.
Unfortunately, not all of these tools play nicely together under the same Java VM installation. Some
require a Servlet 2.1-compliant environment, some require 2.2. Some only run under JDK 1.2 or above,
some under JDK 1.1 (and no higher). Some require the "com.sun.swing" packages from pre-Swing 1.0
days, others require the "javax.swing" package names.
Worse yet, this problem can be found even within the corporate enterprise, as systems developed using
Java from just six months ago may suddenly "not work" due to the installation of some Java Extension
required by a new (seemingly unrelated) application release. This can complicate deployment of Java
applications across the corporation, and lead customers to wonder precisely why, five years after the
start of the infamous "Installing-this-app-breaks-my-system" woes began with Microsoft's DLL schemes,
we still haven't progressed much beyond that. (In fact, the new .NET initiative actually seeks to solve the
infamous "DLL-Hell" problem just described.)
This paper describes how to configure a Java installation such that a given application receives its own,
private, JRE, allowing multiple Java environments to coexist without driving customers (or system
administrators) insane...
It is absolutely possible to install side-by-side several JRE/JDK versions. Moreover, you don't have to do anything special for that to happen, as Sun is creating a different folder for each (under Program Files).
There is no control panel to check which JRE works for each application. Basically, the JRE that will work would be the first in your PATH environment variable. You can change that, or the JAVA_HOME variable, or create specific cmd/bat files to launch the applications you desire, each with a different JRE in path.
We can install multiple versions of Java Development kits on the same machine using SDKMan.
Some points about SDKMan are as following:
SDKMan is free to use and it is developed by the open source community.
SDKMan is written in bash and it only requires curl and zip/unzip programs to be present on your system.
SDKMan can install around 29 Software Development Kits for the JVM such as Java, Groovy, Scala, Kotlin and Ceylon. Ant, Gradle, Grails, Maven, SBT, Spark, Spring Boot, Vert.x.
We do not need to worry about setting the _HOME and PATH environment variables because SDKMan handles it automatically.
SDKMan can run on any UNIX based platforms such as Mac OSX, Linux, Cygwin, Solaris and FreeBSD and we can install it using following commands:
$ curl -s "https://get.sdkman.io" | bash
$ source "$HOME/.sdkman/bin/sdkman-init.sh"
Because SDKMan is written in bash and only requires curl and zip/unzip to be present on your system. You can install SDKMan on windows as well either by first installing Cygwin or Git Bash for Windows environment and then running above commands.
Command sdk list java will give us a list of java versions which we can install using SDKMan.
Installing Java 8
$ sdk install java 8.0.201-oracle
Installing Java 9
$ sdk install java 9.0.4-open
Installing Java 11
$ sdk install java 11.0.2-open
Uninstalling a Java version
In case you want to uninstall any JDK version e.g., 11.0.2-open you can do that as follows:
$ sdk uninstall java 11.0.2-open
Switching current Java version
If you want to activate one version of JDK for all terminals and applications, you can use the command
sdk default java <your-java_version>
Above commands will also update the PATH and JAVA_HOME variables automatically. You can read more on my article How to Install Multiple Versions of Java on the Same Machine.
It should be possible changing setting the JAVA_HOME environment variable differently for specific applications.
When starting from the command line or from a batch script you can use set JAVA_HOME=C:\...\j2dskXXX to change the JAVA_HOME environment.
It is possible that you also need to change the PATH environment variable to use the correct java binary. To do this you can use set PATH=%JAVA_HOME%\bin;%PATH%.
I use a simple script when starting JMeter with my own java version
setlocal
set JAVA_HOME="c:\java8"
set PATH=%JAVA_HOME%\bin;%PATH%;
java -version
To have a java "portable"
you can use this method here:
https://www.whitebyte.info/programming/java/how-to-install-a-portable-jdk-in-windows-without-admin-rights
Or use links. While it is rather unpleasant to update the PATH in a running environment, it's easy to recreate a link to a new version of JRE/JDK. So:
install different versions of JDK you want to use
create a link to that folder either by junction or by built-in mklink command
set the PATH to the link
If other version of java is to be used, delete the link, create a new one, PATH/JAVA_HOME/hardcoded scripts remain untouched
Invoking Java with "java -version:1.5", etc. should run with the correct version of Java. (Obviously replace 1.5 with the version you want.)
If Java is properly installed on Windows there are paths to the vm for each version stored in the registry which it uses so you don't need to mess about with environment versions on Windows.
If you use Java Web Start (you can start applications from any URL, even the local file system) it will take care of finding the right version for your application.
Using Java Web Start, you can install multiple JRE, then call what you need.
On win, you can make a .bat file:
1- online version:
<your_JRE_version\bin\javaws.exe> -localfile -J-Djnlp.application.href=<the url of .jnlp file.jnlp> -localfile -J "<path_temp_jnlp_file_.jnlp>"
2- launch from cache:
<your_JRE_version\bin\javaws.exe> -localfile -J "<path_of_your_local_jnlp_file.jnlp>"