My development team recently was forced over to a remote development environment where we do not have full access to the servers. Before the change over we had a JAR that was running fine on Java 1.7 x64 along with JRE 7. When we moved over to the new server our JAR was running alright, but then one of the server admins "updated" our Java to an older version and uninstalled the one we were using. Don't ask me why, I don't know. I re-installed Java 1.7 and uninstalled 1.6 along with the JREs.
The following problem occurs at runtime, there are no build errors:
Registry key 'Software\JavaSoft\Java Runtime Environment\CurrentVersion'
has value '1.7', but '1.6' is required.
Error: could not find java.dll
Error: could not find Java SE Runtime Environment.
I've run the same JAR on my laptop with no issues. Both the server and my laptop have JDK 1.7 and JRE 7 in the respective %HOME% variables and system PATH. I've even reinstalled JRE 6 and placed it later in the system environment PATH variables with the same result.
I have also changed the registry back to look at 1.6 and it results in the following, which I looked up and it appears to be from having multiple Javas installed (leading back to my original problem):
Exception in thread "main" java.lang.UnsupportedClassVersionError: ... :
Unsupported major.minor version 51.0
I would appreciate any insight you all have as I have been looking over various forums but nothing seems to have exactly my problem. Also, this has happen on another server we are using as well. Thanks!
Update: No luck with recompiling the JAR to either 1.6 or 1.7 and matching the JDK. Also, why in the world would a newer version of Java break an older compiled version?
This happens when you somehow confused java itself. You are trying to run a java 6 VM where it found a JRE 7. It might show this problem even if you type in the command line just java or java -version in a misconfigured environment. The JAR is not the problem, except in the very unlikely case where the code in JAR is looking in the Windows Registry for that (which probably is not your case).
In my case, I had the java.exe, javaw.exe and javaws.exe from Java 6 in the Windows/System32 folder (don't know how it got to be there). The rest of the JDK and JRE where found in the PATH inside C:\Java\jdk_1.7.0\bin. Oops!
Just had the similar error when installing java 8 (jdk & jre) on a system already running Java 7.
Error: Registry key 'Software\JavaSoft\Java Runtime
Environment'\CurrentVersion' has value '1.8', but '1.7' is required.
Error: could not find java.dll Error: Could not find Java SE Runtime Environment.
My environment was set up correctly (Path & java_home correctly defined), but the problem arises from the way pre-8 Java installers worked, which is that they used to copy the three executables (java.exe, javaw.exe & javaws.exe) to the Windows system directory. These remain unless overwritten by a new pre-8 installation.
However the Java 8 installer instead creates symbolic links in a new directory, C:\ProgramData\Oracle\Java\javapath, pointing to the actual JRE 8 location.
This means that you'll actually run the old 7 exes but use the new 8 DLLs.
So, the solution is simply to delete the 3 Java exes, as above, from the windows system directory.
If you are running 32-bit Java on a 64-bit Windows, the exes would be in Windows\SysWOW64, otherwise in Windows\System32.
I've deleted java files at windows/system32 and I also have removed c:\ProgramData\Oracle\Java\javapath from the PATH variable, because there was 3 symlinks to java 1.8 files.
I had JDK 1.7 in the %JAVA_HOME% variable and java1.7/bin in the PATH.
PS1: My problem was between Java 1.7 and Java 1.8.
PS2: I can't add this as a comment to Victor's answer because I haven't enough points.
In the START menu type "regedit" to open the Registry editor
Go to "HKEY_LOCAL_MACHINE" on the left-hand side registry explorer/tree menu
Click "SOFTWARE" within the "HKEY_LOCAL_MACHINE" registries
Click "JavaSoft" within the "SOFTWARE" registries
Click "Java Runtime Environment" within the "JavaSoft" list of registries here you can see different versions of installed java
Click "Java Runtime Environment"- On right hand side you will get 4-5 rows . Please select "CurrentVersion" and right Click( select modify option) Change version to "1.7"
Now the magic has been completed
I don't know if anyone is still following this thread, but I recently had this issue when I tried to launch ActiveMQ 5.10 as a Windows service.
I didn't have a JAVA_HOME path set.
I had Java 6 and Java 7 installed, but the default version was v7. (ie if I opened a command window and types "java -version").
This is where the clue was - "java -version" returned "Java HotSpot(TM) 64-Bit Server VM (build 23.1-b03, mixed mode)" but I was had installed the Win32 service...
It turns out that if you use the Win32 wrapper on a 64-bit machine it somehow decides to use a different version of Java...
So my fix was to uninstall the 32-bit version of the wrapper and install the 64-bit version.
aversion on my machine; just habit I guess... But luckily I resolved the issue eventually...
For my Win7
Paradox was in being java.exe and javaw.exe in System32 folder.
Opening that folder I couldn't see them but using search in Start menu I get links to those files, removed them. Next searsh gave me links to files from JAVA_HOME
magic )
Change to directory with correct java.exe i.e. go to the required JDK version java.exe
cd C:/Program Files/Java/jdk1.7.0_25/bin
Run the java.exe from this directory, it has precedence over registry and $PATH settings.
java -jar C:/installed/selenium-server-standalone-2.53.0.jar
I solved this problem by uninstalling Java 1.8
The jar was compiled to be 1.6 compliant. That is why you get this error. Two resolutions:
1) Use Java 1.6
OR
2) Recompile the jar to be compliant for your environment 1.7
Using regedit, remove the entries corresponding to java 7. It will work.
Related
I am running XUbuntu x64 14.04.4 LTS on my PC, with eclipse Mars.2 Release (4.5.2) and JDK 8 properly linked up to my eclipse (via ini file).
So basically, I "upgradet" to e(fx)clipse. Then I crated a new "JavaFX project". When I tried to run it, I got the error The import javafx.application cannot be resolved.
A quick google search brought up, that I need to add the jfxwt.jar from my java 1.8 directory (in my case /opt/Oracle_Java/jdk1.8.0_91/jre/lib/).
But the error didn't went away. I also tried the build options but nothing seemed to change anything.
First of all, I included the wrong jar. whoops. thanks to #DVarga for the tip.
But that wasn't the problem. So here are all the steps I took, to create a working e(fx)clipse environment:
Download the latest eclipse version and add the e(fx)clipse package.
Update to the latest JDK and reference that in the eclipse.ini file (1)
Tell ecplipse the path for the latest JDK. Although this tutorial is for MACs, it works pretty much the same in linux. There are a few differences tho:
The preferences menu is in window > preferences
The JRE type is not MacOS X VM but rather Standard VM
The JRE home path is the jdk1.8.0_VERSION folder (in my case /opt/Oracle_Java/jdk1.8.0_91)
I didn't need to add any other jar for javaFX to work properly.
(1) How to add the Java 1.8 path to eclipse
if you get the error "JavaFX was disabled because your java version is to old" (or something like this) you need to update to at least Java 1.8 and edit the eclipse.ini file in the eclipse folder.
There you have to look for the line -vm. In the next line is a path to an old Java version. Change that to the new path. It should look like this: /path/to/jdk1.8.0_VERSION/jre/bin/ in my case it is /opt/Oracle_Java/jdk1.8.0_91/jre/bin/
This should be easy, but I can't figure out how.
Is there any way to find out which JavaFX version is installed. And I DON'T mean programmatically via System.getProperty("javafx.runtime.version") , which returns an empty string on my computer, although JavaFX is installed.
I would rather like to have something like java -version on console, but in order to get the JavaFX version.
Alternatively it would be sufficient to know if JavaFX is installed at all. I just have some customers who can't run my swing/javaFX app and would like to tell them to check whether JavaFX is installed.
You can't really do this the same way you do with the Java runtime. The difference is that java is a machine executable that launches the JVM. JavaFX is just a set of library classes; it's not really an executable in the same sense.
It looks like the System property that you can read at runtime is kept in jre/lib/javafx.properties, so you can do something like
cat $JAVA_HOME/jre/lib/javafx.properties
or whatever the Windows equivalent is, if you're running on Windows. However, if the System property you get at runtime is blank, then I suspect this file doesn't exist. As dfeuer commented, it would help to know your JRE version.
Update:
The relationship between JDK/JRE version and JavaFX version is as follows.
Beginning with JRE 1.7.0 update 6, JavaFX was included with the JRE, but was not on the classpath. So for JRE 1.7.0, update 6 and later, the jfxrt.jar file is included in JAVA_HOME/jre/lib. The javafx.properties file which contains the JavaFX version information is in the same directory, though in theory at least the JRE version will determine the JavaFX version (since they were shipped together).
Just inspecting the JDK 1.7.0 versions I have installed on my machine, the mapping from JDK version to JavaFX version is:
/Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk javafx.runtime.version=2.2.0
/Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk javafx.runtime.version=2.2.4
/Library/Java/JavaVirtualMachines/jdk1.7.0_11.jdk javafx.runtime.version=2.2.4
/Library/Java/JavaVirtualMachines/jdk1.7.0_13.jdk javafx.runtime.version=2.2.5
/Library/Java/JavaVirtualMachines/jdk1.7.0_17.jdk javafx.runtime.version=2.2.7
/Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk javafx.runtime.version=2.2.21
/Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk javafx.runtime.version=2.2.25
/Library/Java/JavaVirtualMachines/jdk1.7.0_40.jdk javafx.runtime.version=2.2.40
/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk javafx.runtime.version=2.2.45
Beginning with JRE 1.8.0, JavaFX was included with the JRE and was placed on the classpath; so it's effectively a full part of the core libraries. In version 1.8.0, the jfxrt.jar file is in JAVA_HOME/jre/lib/ext (which automatically makes it part of the classpath). The javafx.properties file which contains the JavaFX version information is still in JAVA_HOME/jre/lib. The version numbering for JavaFX in version 1.8.0 (appears to) simply mimic the JRE version:
/Library/Java/JavaVirtualMachines/jdk1.8.0.jdk javafx.runtime.version=8.0.0
/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk javafx.runtime.version=8.0.5
/Library/Java/JavaVirtualMachines/jdk1.8.0_20.jdk javafx.runtime.version=8.0.20
So with your customers, you can simply ask them to do java -version and for the most part, you'll be able to deduce the JavaFX version. On some rare occasions you may need to dig a little deeper.
A sort-of-related note: if you are shipping an application to customers and you need to determine a specific version, consider using a self contained application, in which you include a JRE (and JavaFX runtime) with the application.
For Ubuntu 18.04 the JavaFX version can be found in /usr/share/openjfx/lib/javafx.properties. A simple command should show you the version you have.
$ cat /usr/share/openjfx/lib/javafx.properties
javafx.version=11.0.2-internal
javafx.runtime.version=11.0.2-internal+0-2019-02-19-093139
javafx.runtime.build=0
Perhaps your installation has something similar?
If you are using Netbeans 15 on Windows 10, look in the file:
C:\Program Files\NetBeans-15\netbeans\javafx\VERSION.txt
On my machine, it contains 11
How can I set my java jar application to use jre 6 instead of jre 7?
I'm doing this because there are some compatibility issue with the libraries I'm using if the application use jre 7.
Edit:
The application will come with its own installers (using advanced installer) that have a jre6 installer. But I don't know how to trace the installation folder of the jre6.
How can I trace it and make the jar file use the jre6?
You can do this from Advanced Installer much simpler. You have two options:
Force the package to use the JRE 1.6 found on the machine by going to "Virtual Machine" tab from Java Products page and setting the minimum and maximum JRE versions to 1.6
Add as bundle in the project from the same page the JRE for version 1.6. This means that Advanced Installer will automatically import in your package the JRE resources required for your application, thus increases the package size, and will install them in the application's install folder. This JRE bundle will be used only by your application and removed along with it.
When running your application using java.exe, you could provide the absolute path to a Java 1.6 installation. Something like:
absolute_path_to_java6_dir/bin/java -jar yourRunnableJar.jar
or
absolute_path_to_java6_dir/bin/java -cp .;yourJar.jar;otherJarFiles className
You could check the running JVM version when starting your application.
System.getProperty("java.version");
This way you could provide a meaningful explanation to end-user.
I have a system running 64bit windows 7. I'm doing a project using JMF, which I found works best (or only) with 32 bit jdk. I'm using a 32bit eclipse. I also have a 64bit JDK installed. right now I have set classpath (JAVA_HOME and Path) for the 32bit JDK.
The problem is it becomes hectic to switch between the 64bit and 32 bit JDK(i have to change classpaths everytime). Is there any easier way to do that?
You can have multiple JREs registered with Eclipse, and associate a project or run configuration with a specific JRE. These are different from the JRE you use to run Eclipse in.
Eclipse doesn't need to depend on JAVA_HOME or PATH. You can specify the JVM to be used to run Eclipse in the eclipse.ini file, and specify the path(s) to the target JVM(s) via the Eclipse preferences.
If you have to run both 32 and 64 bit Java from the command line, you should invest some time in writing shell scripts, aliases, etc.
You could write a script (to be executed using ".") that will switch the settings of PATH and JAVA_HOME.
I prefer the approach of writing simple wrapper scripts or aliases to automate the build or run steps for the software you are developing. You can embed local overrides of PATH and JAVA_HOME in these scripts.
I would suggest just keep one JDK installed on your machine.
If you are working with JMF and Eclipse 32 bit then uninstall 64bit JDK
As per Oracle.
To run 64 bit eclipse without change environment variable
Simply copy 64bit jre to your eclipse(64 bit) root folder and rename it as jre.
We have a project that compiles to a 32-bit COM DLL and to a 64-bit COM DLL (the same one from my earlier question). When I register both on my Windows 7 machine, both register successfully. When I register both on a Windows Server 2003 machine, both register successfully.
But when I try to register the DLLs on a Windows Server 2008 R2 standard SP1 machine, the 64-bit DLL registers successfully, but the 32-bit DLL fails with the message (sic):
The module ""%1"" may not compatible with the version of Windows that you're running.
Check if the module is compatible with an x86 (32-bit) or x64 (64-bit) version of regsvr32.exe.
I don't think a 32-bit DLL can be compatible with WS2003 and Win7 but not WS2008. That makes no sense.
What might be happening?
The version of Regsvr32.exe must match the 32-/64-bitness of the dll you're trying to register. The 64-bit regsvr32 cannot load a 32-bit dll, and vice versa.
You may need explicitly call the 32-bit version of regsrv32 located in %systemroot%\SysWoW64\regsvr32.exe.
From http://support.microsoft.com/kb/249873
Regsvr32.exe is included with Microsoft Internet Explorer 3.0 or later versions, Windows 95 OEM Service Release 2 (OSR2) or later versions, and Windows NT 4.0 Service Pack 5 (SP5) or later versions. Regsvr32.exe is installed in the System (Windows Me/Windows 98/Windows 95) or System32 (Windows NT/Windows XP/Windows Vista/Windows 7) folder.
Note On a 64-bit version of a Windows operating system, there are two versions of the Regsv32.exe file:
The 64-bit version is %systemroot%\System32\regsvr32.exe.
The 32-bit version is %systemroot%\SysWoW64\regsvr32.exe.
Regsvr32.exe usage
RegSvr32.exe has the following command-line options:
Regsvr32 [/u] [/n] [/i[:cmdline]] dllname
/u - Unregister server
/i - Call DllInstall passing it an optional [cmdline]; when used with /u calls dll uninstall
/n - do not call DllRegisterServer; this option must be used with /i
/s – Silent; display no message boxes (added with Windows XP and Windows Vista)
When you use Regsvr32.exe, it attempts to load the component and call its DLLSelfRegister function. If this attempt is successful, Regsvr32.exe displays a dialog box that indicates success. If the attempt is unsuccessful, Regsvr32.exe returns an error message. This may include a Win32 error code. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
193625 WinInet error codes (12001 through 12156)
This isn't likely to be the problem in your case, but might be useful for others who find this question by searching on the same error message:
I had a similar problem: a DLL that wouldn't register with either the 32-bit or 64-bit version of RegSvr32. I loaded the DLL the Dependency Walker (depends.exe, http://www.dependencywalker.com/) and got a much more useful message:
Error: At least one file was not a 32-bit or 64-bit Windows module.
Scanning the CPU column in the Module List identified the offending module. (In my case, it said "No DOS or PE signature found. This file is not a valid 32-bit or 64-bit Windows module.")
Moral: The Dependency Walker might give you a more useful error message than RegSvr32.exe.
I got it registered by moving the dll to the c:\windows\syswow64\ directory (it wouldn't work in the system32 directory) and then explicitly calling syswow64\regsvr32, eg
c:\windows\syswow64\regsvr32 yourdll.dll
btw it wouldn't work when calling c:\windows\syswow64\regsvr32 c:\windows\syswow64\yourdll.dll
Use Process Monitor from SysInternals.
1. Filter by "Process Name" = regsvr32.exe.
2. Try to register your DLL file from the correct version of regsvr32.exe (the 32-bit version is in the SysWow64 folder)
3. Process Monitor will trace EVERYTHING that is happening on your computer.
4. First start your analysis by eliminating the registry events (for now):
5. You may be able to see which DLL file is found and not found.
Here a (very) partial screenshot of regsvr32.exe of Threed32.ocx where we can see some of the required DLL files:
6. Your work is just starting. From now.
I have the same problem, but I resolve it with commands
CD \windows\syswow64
regsvr32 c:\filename. dll
Running the command prompt as administrator fixed my issue.