I use Eclipse with ant scripts, and Eclipse works well with the default JRE installation on Windows XP.
The annoyance comes when I want to run ant scripts compiling with the javac-tag, where it fails because there is no tools.jar in the classpath.
I've gotten the idea that if I could make the JDK become the default Java on Windows, then I would have what I have today, plus ant working out of the box.
Can this be done? What have I missed in the installation process?
Edit: I know of JAVA_HOME, but that is tedious and error prone (manually updating environment variables when a fresher JDK is available is not always something I remember).
Edit: I ended up figuring out how to make the javac task use the Eclipse compiler (ecj.jar), which works very nicely.
Edit: Maven also supports using the Eclipse compiler, but this appears to be very rarely used and with an old version of ecj.jar. I intend to look in to this at a later time.
Edit: Using ecj with maven-compiler-plugin 3.0 works very well, and allows for building with a JRE.
Edit: I had problems with the javadoc tool crashing when parsing bytecode generated by ecj.
The answer is "no," there is no way to get the JDK to be the default JVM upon install.
As the other answers point out, you can adjust your path and your JAVA_HOME to point to the JDK, or a different JVM entirely. This is in fact what the Java installation does in the first place.
However, your problem is that you want tools.jar to be found. To do this you can copy it to the ext directory under your default JVM. Check the JDK file structure here. This will probably work.
On the other hand, if modifying the JAVA_HOME and PATH variables for Java seems annoying, remember that it's just one of a series of things we do to keep us sharp
Download JDK from the website
Once everything is finished, go to Control Panel
Open JAVA
Click on the Java tab and select View
There will be one item present in the list. Change the Java Path from JRE to the JDK you downloaded, like so:
C:\Program Files\Java\<your_jdk_version>\bin\java.exe.
For example, mine looks like this:
C:\Program Files\Java\jdk1.7.0_07\bin\java.exe
Copying the tools.jar file to a location where Eclipse is looking for it may work, but is messy and fragile since that's a step you may not remember the next time you upgrade your JDK. Better is to convince Eclipse to look for it in the proper location.
Setting JAVA_HOME to the correct location works for some tools, but Eclipse does not honor it.
A couple of things to try:
Make sure your JDK is identified and
selected under
Preferences->Java->Installed JREs.
Make sure Ant is being invoked by the
JDK. One clue is that at the top of
the Console output you should see the
path of the javaw.exe which is being
used. If that path is in the JRE,
more convincing is needed. Check
Run->External Tools->External Tools
Configurations->[your Ant build]->JRE
and make sure the settings there
point to the JDK.
Try changing the JAVA_HOME environment variable to point to the JDK instead of the JRE.
Alternatively or possibly additionally, add a PATH entry to the JDK bin directory before any of the Windows system directories.
I suspect JAVA_HOME is enough to get Ant working, but it's sometimes nice to get the JDK version of java etc on the path too, so that when you just run java from the command line, you'll get exactly the same version as when you run javac.
You could probably write a WSH script to reconfigure your path automatically.
This JScript script just prints some info:
//file: jdk.js usage: cscript /Nologo jdk.js
var objShell = WScript.CreateObject("WScript.Shell");
function setJdk(version) {
try {
var jdk = objShell.RegRead("HKEY_LOCAL_MACHINE\\SOFTWARE\\" +
"JavaSoft\\Java Development Kit\\" + version + "\\JavaHome");
if(jdk != null && jdk != "") {
jdk += "\\bin";
var path = objShell.RegRead("HKEY_CURRENT_USER\\Environment\\Path");
path = jdk + ";" + path;
WScript.Echo("Could set PATH to " + path + "\n");
}
} catch(err) { /*probably key does not exist*/ }
}
setJdk("1.7");
setJdk("1.6");
setJdk("1.5");
There is a RegWrite method that can be used to write to the registry. There is a bit of work involved determining the latest version and rejigging the path, removing obsolete entries and sorting out system versus user paths. No doubt it could be used to set JAVA_HOME too. The JDK entry would need to appear before the system32 directory, as the JRE installer puts a java.exe in there.
(I'm not 100% sure if the shell would pick up on such changes or whether a reboot/env variable reload of some kind would be required.)
This is normally done by setting your JAVA_HOME environment variable to the root JDK directory that you want to use.
For example from a command line or batch file you simply do something like:
set JAVA_HOME=C:\Program Files\Java\jdk1.6.0_14
However to set JAVA_HOME permanently add it to the environment variables on the Advanced tab in the property sheet for My Computer.
Apparently Eclipse can compile without the tools.jar. My guess it that they have a specific javac command that can work with a JRE (and not a JDK); this could be the reason why they can list their warnings.
Anyway, I would go the standard way (as suggested above) and install a JDK on your system. You can even start Eclipse with that specific JDK (without any JAVA_HOME change) by tweaking the eclipse.ini file (see these instructions).
Of cause this is doable. Not understand why people said No to this question.
Copy over the tools.jar is not a wise way, I had the issue when using eclipese,
Just add the jdk instead of jre to my build path and it works.
Here is the details:
http://www.gamefromscratch.com/post/2011/11/15/Telling-Eclipse-to-use-the-JDK-instead-of-JRE.aspx
Related
Windows 10 OS. I'm using a Cygwin BASH console to run Gradle.
I've been struggling with this for a few hours now. There are one or two questions on SO which seem to relate this but I'm still a long way from understanding the basic mechanisms and how to get Gradle to use the right JDK/JRE.
This started earlier when gradle build didn't work and complained that it couldn't find "tools.jar". This appears to be a sign that the path to the Java JRE used to run the Gradle app isn't associated with a JDK. This is indeed the case: the JRE it insists on using to start up is at "C:\Program Files\Java\jre1.8.0_73\". This is a JRE without a JDK.
The JDK I want Gradle to use is at "D:\apps\Java\jdk1.8.0_191\".
I have set JAVA_HOME to this value. I have also placed "D:\apps\Java\jdk1.8.0_191\bin\" at the very start of the PATH environment variable.
In both Cygwin and the W10 console, when I go "java -version" it prints out the 1.8.0_191 version, proving that the OS System is configured as expected.
But Gradle itself insists on using the JRE in C:.
I tried numerous experiments and rebooted numerous times.
When I went, in build.gradle:
println "java.home is ${System.properties['java.home']}"
... it always printed out the C:\ location version (1.8.0_73)
Finally I made this impossible by renaming "C:\Program Files\Java\" to "C:\Program Files\JavaXXX\". This then gives:
Chris#M15B /cygdrive/d/My Documents/software projects/EclipseWorkspace/LuceneIndexer_3
$ gradle build Error: could not open `C:\Program Files\Java\jre1.8.0_73\lib\amd64\jvm.cfg'
So it appeared, as far as I could surmise, that something inside Gradle has got its heart stubbornly set on using a particular JRE location... which disregards the JAVA_HOME variable, the PATH entries and the OS's own understanding of which JDK/JRE should be used... and even sets System setting java.home to a "spurious" setting (or one I don't want to use).
Finally... I put this line in gradle.properties:
org.gradle.java.home=D:\\apps\\Java\\jdk1.8.0_191
When I then changed "C:\Program Files\JavaXXX\" back to "C:\Program Files\Java\", finally the thing built properly. And finally java.home was printed out as "D:\apps\Java\jdk1.8.0_191". But when I again renamed to "C:\Program Files\JavaXXX\" the "could not open" error returned. In other words, even if you can configure java.home in Gradle, Gradle itself appears to be reliant on a version of Java that you don't want it to use, and which is not the version for which the OS is configured!
How on earth does the Gradle application find the JRE it is going to use to do its business? Surely there must be a way to get it to use another one?
later
I also tried adding some ECHO statements to the gradle startup script... in which there is a specific section devoted to determining the JVM to use. These experiments showed clearly that this script is correctly using the desired JDK (under D:). Nor can it be a Cygwin-related problem, as other Cygwin commands work fine when Java\ is renamed to Java_XXX. I also examined the registry: no clues found.
By going "gradle" at the Cygwin command prompt, something somewhere in the works insists on using a baked-in JRE location, even before the gradle startup script is run...
I was able to resolve this by upgrading my system's Java and Gradle. I changed to Java 9 (although apparently we're on Java 11 at the time of writing). I also changed to Gradle 5.2.1 (from 3.5). I think I concluded that Gradle 3.5 was incompatible with Java 9...
I was quite confused: for a moment it appeared that Cygwin was out of date and that I needed a newer version of its Gradle. But in fact Cygwin was inheriting PATH from W10, and one of those PATH entries was "%GRADLE_HOME%\bin". Cygwin was using the W10 Gradle. What fun to be using a Windoze OS!
GRADLE_HOME (different from GRADLE_USER_HOME, where dependencies are downloaded!) thus had to be changed to the location of the new version of Gradle.
All sorts of funny consequences followed for Eclipse: the dreaded red exclamation marks... caused by the fact that under "Project and External Dependencies" for several projects the dependencies revealed themselves to be located in the old 3.5 GRADLE_USER_HOME location, which I had renamed deliberately to make it inaccessible. I found no way to "rebuild" these dependencies in Eclipse (i.e. to force use of GRADLE_USER_HOME, now pointing to a location under ...5.2.1), and instead opted to recreate the Eclipse projects.
Quite trying. There must of course be a better way.
Incidentally, it does indeed appear that when you run a Gradle command in Cygwin the JVM as configured for your OS in the "Java Control Panel" gets invoked before the gradle startup script is run (... I think). Even if your JAVA_HOME setting and first PATH entry are pointing to a different JRE (which they probably shouldn't be).
Previously I am using Java 1.8 in my machine. But now i need to use Java 1.6. So I changed the below values in system environment variables.
JAVA_HOME
U:\POC\jdk1.6.0_31
PATH
U:\POC\jdk1.6.0_31\bin\ or %JAVA_HOME%/bin
Also I restarted my system
Even after that it is displaying java version as 1.8 in my command prompt.
Can anyone advice on how to resolve this issue?
when latest version is installed in system it automatically set javapath in environment variable like "C:\ProgramData\Oracle\java\javapath".
Remove this from environment variables.
This suggestion may seem obvious, but I urge you to carefully consider this advice.
I have encountered this issue before, and frequently, it has been due to an overlooked entry within the long list of items making up the Windows Path. It is often an path entry where it is not immediately obvious that any of the java executables (javaw.exe, javaw.exe or javaws.exe) may reside. A common culprit is C:\ProgramData\Oracle\Java\javapath
You will therefore need to push upwards, your desired java/bin path above these. If in doubt, push it right to the top!
In the unlikely event that this does not work, then try making changes from within the java admin console (Control Panel --> Java --> Java tab --> View Button).
I've not used Windows in a long time but I remember that there are 2 sections of environment variables. One system scope, and the other user scope.
Check that nothing in the system scope is defining a JAVA_HOME.
Like #Stephen C said, post the output of echo %PATH% and echo %JAVA_HOME%.
Check that nothing comes before %JAVA_HOME%/bin in the path that may contain the java executable. Things like Oracle client come with Java. You can always put %JAVA_HOME%/bin in front of the path instead of at the end.
#David Santiago's answer is a bad idea. If you let the IDE do your job, you won't be able to troubleshoot when there is a problem.
I recently ran into this as I have added in JAVA 9, 11, and 17 along with my previous JAVA 6, and 8 versions.
I incorrectly assumed that env variables hadn't changed with the newer releases, but I was obviously wrong.
When I ran java -version it returned JAVA 9 and javac -version returned JAVA 17.
So, I incorrectly tried to add a %JAVA_HOME% variable, as I had always done in pre-JAVA 8 versions under the Windows Environment Settings. However, despite moving that addition to the front of the PATH, it didn't change anything!
This article explains the issue: Java SE 8 Update 171 Uses Different Windows Path (Doc ID 2412304.1), however it doesn't give any solutions.
The path to this Windows folder is:
C:\ProgramData\Oracle\Java\javapath
Notice it is under a ProgramData folder, not Program Files. Moreover, it has been prepended to PATH under the Windows env settings. This folder is where java has 3 symbolic links set that will override the PATH changes you make and sure enough it was pointing to the JAVA versions I returned from -version on java and javac. Even if I tried to set a JAVA_HOME as the first entry in path, it still didn't work!
I found two solutions here at: JDK 8 and C:\ProgramData\Oracle\Java\javapath
How to switch JDK version in cmd more flexibly You can either prepend
your own directory to the PATH to overwrite the Oracle one, or follow
the convention to append to the end of PATH variable like always did.
I prefer the second one, here is how to do it.
The second solution uses two batch files with a env variable JAVA_HOME setting similar to what I had always used.
The system displays the latest version installed on the system.
That's informative only, that should not worry you.
If you are going to use version 6.0_31 of the Java JDK you only have to configure that in your IDE (Eclipse, Netbeans, IntelliJ IDEA, whatever) to compile using that version.
Example
On command prompt use these commands to set envirnment variables
JAVA_HOME=C:\Program Files\Java\jdk-11.0.17
set PATH=%JAVA_HOME%\bin;%PATH%
I am trying to change between Java7 and Java 8 environments. I created the following new environment variables:
JAVA7_HOME - java 7 location
JAVA8_HOME - java 8 location
JAVA_HOME
I then set JAVA_HOME to be %JAVA8_HOME% or %JAVA7_HOME%. In path I have
%JAVA_HOME%\bin;REST OF PATH
It seems no matter what I set JAVA_HOME to it will not change the outcome of java -version, even for new sessions.
How can we have two separate java environments while easily changing between them? I've tried setting everything to the correct paths, that includes:
HKEY_CURRENT_USER\Environment JAVA_HOME
HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment CurrentVersion
and even changing symlinks to point to the version we want. We've create batch scripts to do it all, we've create powershell/,net to do it and then broadcast, tried setting it all and restarting explorer.. It seems impossible to switch between 7 and 8.
Does anyone have an idea how to resolve this?
The basic problem is that changing environment variables via commandline is not permanent for some reason. You'll have to set the new value via the UI.
I used to do the following:
Put both the jdk8 and the jdk7 in your path (put the one you want as "default" first).
Look up java.exe and javac.exe in the jdk8 bin/ directory. Copy the executables under the name java8.exe and javac8.exe.
Do the same in the jdk7 bin/ directory, and copy the binaries to java7.exe and javac7.exe.
Now you can call java/javac, java7/javac7 and java8/javac8.
(I am not sure why anybody would need JAVA_HOME, I never set it.)
The other excutables like jar.exe and so on will be taken from the default jdk (the one first in the path), this is ok, since your JAR files will be the same no matter which jar.exe made them.
Then go on to configure the applications you need, like eclipse.
Hopefully, also your build tool can be told which executables to use. If not, it will use the default.
This way, you can also realize crazy configurations. For example, suppose you want jdk7 as default, but want to always use the java8 javadoc. Then simply rename the javadoc.exe from jdk7, for example to javadoc-dontuse.exe. This way, when you type javadoc.exe or some application calls it, it will not find it in the (default) jdk7 and continue to search in the jdk8 bin.
I am trying to run a compiled java class and getting errors but when I checked my java environments it points to different version.
Javac –version gives me 1.8.0
And
Java –version gives me 1.6.2
The Java_home and path is pointing to the 1.8 version.
Please help.
Java installation under Windows is sometimes a really severe source of pain. The following assumes that you have Windows:
Check your path variable
Check JAVA_HOME variable
Newer versions of Java (1.6 ?, but 1.7 and 1.8) copy some Java executables into the System32 directory of the windows installation. Simply delete this files (or move them somewhere else for easy recovery)
running java applications by using .bat files a specific JDK / JRE can be provided.
There may be more sources of your problem. For example with Maven you depend on JAVA_HOME, with Eclipse you have the project settings, ...
Please check the following :
1) Check your path variable
2) Check JAVA_HOME variable
3)Delete the java,javaw and javaws .exe file from the system32 folder
java.exe while java installation gets copied under System32 directory. Also we tend to append java path in the end of the path variable. This causes running java command pointing to the one in System32 (it takes the first path value that is encountered and ignores rest, in this case java of system32 folder). And when it cannot find javac it looks to other values of path and finds it towards the end for the java JDK (this is the one you want to use).To overcome this problem give path to your JDK for example C:\ProgramData\Oracle\Java\bin as the first entry in the windows path variables. Even before your system32 entry. This ensures you point to only one java. My path entry looks something like this:-
%JAVA_HOME%\bin;%SystemRoot%\system32;
If you are running Windows, you could perhaps check the path environment variable. It might point to an older JRE installation.
One possibility is that your Java link is inconsistent. Go to this location (Windows):
C:\ProgramData\Oracle\Java\javapath and check where to does java.exe point.
In case it is not up-to-date consider fixing it with:
mklink /d C:\ProgramData\Oracle\Java\javapath "C:\Program Files\Java\<your JDK>\bin\"
(you may need to remove javapath old link before you create a new one)
I'm currently trying to tune my Eclipse installation and bumped into the "-vm" option. Other posts on SO mentioned that it's good to always use the latest JVM available because they keep getting better in terms of performance, so I'm likely to do that. I was wondering though how you could find out what JVM Eclipse runs on if you are not specifying the "-vm" parameter.
I found the following in the docs but that doesn't clarify how it will look for a JVM:
when passed to the Eclipse executable, this option is used to locate the Java VM to use to run Eclipse. It must be the full file system path to an appropriate Java executable. If not specified, the Eclipse executable uses a search algorithm to locate a suitable VM. In any event, the executable then passes the path to the actual VM used to Java Main using the -vm argument. Java Main then stores this value in eclipse.vm.
Actually, Windows->Preferences->Java->installed doesn't show you the one Eclipse runs under, but only the default JRE that it runs things under.
To see the one Eclipse is runing under, go to Help->About Eclipse Platform->Configuration Details, and look for the property eclipse.vm.
For example:
eclipse.vm=C:\Program Files\Java\jre6\bin\client\jvm.dll
According to this thread and this one:
eclipse will try to locate your JVM used for launching itself by examining your path.
So, you can:
Create a JAVA_HOME environment variable, that points to your actually preferred JDK.
This way you can easily choose between JDKs installed.
Put %JAVA_HOME%\bin in the path, anywhere preceeding <windowsroot>\system32, which also
contains java, javaw & co binaries.
This way the java* in the JDK bin directory is invoked whenever it is invoked from the path.
I believe the other posts tell you how to find what JVM eclipse is using.
However, I interpreted your question as: "what JVM will eclipse will use when launching itself ?" when no -vm args is used.
After further research, it appears that eclipse will look for a JRE:
either directly under its installation directory (<eclipse>\jre): if you copy the content of any installed JRE in that sub-directory, it will be selected
in C:\Program Files\Java\JRE....
in the %PATH% (see above)
Also read this SO answer to see why eclipse will by default select jvm.dll instead of javaw.exe
If you go to Help->'About Eclipse Platform' and click on the 'Configuration Details' button it will take a moment to display, but you get a dump of everything eclipse is configured for...
I found these 2 lines to be what you're looking for:
-vm
C:\Program Files\Java\jdk1.6.0_10\bin..\jre\bin\client\jvm.dll
I think if you do:
Window->Preferences->Java->Installed JREs you'll see a list of JREs on your machine.
The one that's checked is the one that eclipse is using.
Alternatively, if you go into the "run configurations" dialog, and look at the JRE tab, you can pick a JRE to run on there.