Downloading and Installing Java on Windows 11

As most programmers will know, Microsoft are ending their support for Windows 10 as of October 17 2025.  This has meant for me, that since my PC which runs Windows 10, cannot be upgraded to 11, that I have had to buy a new one which can,,!

Having done this, I now want to continue to use and program in Java on the new PC, but have conveniently forgotten what I need to download and how to configure it! (after all the last time that I did this was about 10 years ago, when setting up Java on the Windows 10 PC...)

At the moment, I have downloaded the Java Runtime Environment - jre1.8.0_461, but would value any help as to how to download the most up to date Java Development Kit and how to change environment variables so that simple Java commands such as Javac and Java actually work when attempting to compile and run a Java class.

I am running Windows 11 Pro

You can't use a JRE; you have to use a JDK. In fact the JRE ceased to be available separately about ten years ago. I wouldn't use Java8; use Java25, which (I think) is the most recent LTS (=long term support) version.
Start here. Remember you will have to update your system PATH, or (maybe better) include %JAVA_PATH% in your system PATH and have a separate environment variable called JAVA_PATH. You upgrade JAVA_PATH, and that upgrades the PATH as a side‑effect. If you have several different Java® versions installed, it's probably best to have the most recent first in the PATH.

The open JDK works but it is a Zip not an installer. You can download a JDK-25 windows installer from Oracle as long as it's for private use. The installer puts everything in its proper place.

Then edit your SYSTEM environment variables:

Add a JAVA_HOME variable and set it to "C:\Program Files\Java\jdk-25" (assuming you are using Oracle)

Edit your "Path" variable and add to the BEGINNING:
%JAVA_HOME%

Do you use an IDE? Which one?

Carey Brown wrote:. . . JAVA_HOME . . .

Yes, that't the correct name for the variable; I was mistaken saying JAVA_PATH. Sorry.

Java itself is wholly contained in a ZIP file. As was mentioned, JRE's are no longer separate installs. In any event, the difference between an JDK and a JRE is that a JRE was embedded within a JDK. Which would have been smaller, since JRE's didn't include the development apps like javac. Saving disk space is no longer a concern though, and the main argument against a JRE-only distro these days would be to keep possibly-dangerous developer resources out of the hands of people who might misuse them.

Again, a JDR/JRE comes as a ZIP file. The Windows Installer distros do affect the Windows Registry and I'm unclear how, but since the Windows Registry is not a "run anywhere" resource (no such animal exists in Linux, MacOS or IBM's z/OS), it's not an essential part of Java.

Just for info, JAVA_HOME is not actually part of official Java, but it is a very common convention used by many Java apps, such as the Tomcat webapp server. Setting %JAVA_HOME%\bin* in the PATH is popular and convenient, but not essential. And yes, the "bin" part is important, since PATH points to executables, and while Java can find its other resources relative to the programs such as java and javac, it does need an anchor executable, since you can have multiple Java distros installed and running on the same machine.

---
*The Linux/MacOS/Unix version of this would be $JAVA_HOME/bin.

Speaking of OS oddities, Linux has a standard for what kinds of files go where (LSB). For example, executables go in /bin, /usr/bin or something of that stripe (there's a movement to reduce the number of such locations). Libraries go in /var/lib, and so forth.

The vendor-supplied OS package installers for some linux JDK distros resolve the difference between this splattered-everywhere architecture and the all-under-one unzipped-directory by making aliases from one to the other. There's also this horrible thing called "alternatives" that's intended to allow making a specific JDK be the one referenced in the LSB locations. I prefer $JAVA_HOME/bin, myself.

Sun established a convention of installing JDK's and JRE's for Red Hat-style Linux distros under /usr/java. I think that this has shifted for OpenJDK and/or Oracle package installers. but I forget details.

---
Java 25 has just been released. While Java is generally more reliable than many software products, I would still be more inclined to begin with Java 17 or Java 21, both of which, like Java 25 are Long-Terum Support (LTS) products.

Under no circumstances would I start with Java 8. The transition from Java 8 to any more recent release can be painful. Some critical things changed at that point.

Many thanks to all those who have replied so speedily to my post.  

Having downloaded and installed the Java 25 JDK, I am now able to compile and run Java classes again and look forward to trying out more complex aspects of the Java language.

In order to get the environment variables set up correctly I created a new environment variable named  java_home and the path variable now begins with a reference to java_home that reads %java_home%\bin;

Finally,  I have also been able to locate and checkout the latest edition of the Java API, which is a vast improvement on earlier versions

The convention is that JAVA_HOME be written in all upper case. Yours seems to work though.

Carey Brown  Thanks for your observation.  I suspected that variable names should be written in CAPS, but it works the way it is, and the next time I come to change it, it will be corrected.

Windows is often case-insensitive, especially when it comes to file names.

Java, however, is modeled after Unix, which is always case-sensitive.

Stuff that is written using the wrong case MAY work under Windows, but not always, so failure to observe proper capitalization can lead to unexpected results.

For JAVA_HOME, that's an environment variable. Environment variables were a concept originally developed in Unix, so again, case sensitive. By convention, Unix (and thus Linux) environment variable names are ALL_CAPS.

While Windows itself is generally case-insensitive, code written in Java is definitely not, and the boundaries between the two are where much of the trouble can occur. An extreme case can be seen when you name a class "Foo" but put it in a file named "foo.java". Even better, under Unix, you can have both a "foo.java" file AND a "Foo.java" file in the same directory and such things have been known to happen if the developer doesn't pay attention.

Finally, it should be noted that a universal file naming convention exists as part of Java's "run anywhere" concept. While you can give a file name in the form "C:\home\tim\data.txt", the universal (portable) form of this is "/C:/home/tim/data.txt". This form is easier to work with when creating/modifying filename paths not only because it is more portable, but because backslashes are "magic" characters in Java and if you forget to double up on them, you can get into real trouble!

Carey Brown wrote:. . . JAVA_HOME be written in all upper case. . . .

Some IDEs use JAVA_HOME a lot; they might require it in UPPER‑CASE.

Campbell Ritchie wrote:

Carey Brown wrote:. . . JAVA_HOME be written in all upper case. . . .

Some IDEs use JAVA_HOME a lot; they might require it in UPPER‑CASE.

Eclipse is not one of them, and I do not think IntelliJ is either.

IDEs are funny because they are often Java apps themselves, so they may run under one JVM but the powerful ones allow different projects to be run under different JVMs (JDKs). At the same time.

Rather than using JAVA_HOME, the location of the JVM that runs the IDE itself is typically defined in a config file for the IDE. Which causes a lot of people to get frustrated when they set JAVA_HOME and it doesn't run the IDE.

Tim Holloway wrote:. . . Eclipse is not one of them, and I do not think IntelliJ is either. . . .

I think it's NetBeans.

Carey Brown asked "Do you use an IDE? Which one?", so to continue the discussion about IDEs, I had installed on my Windows 10 PC, Eclipse Java Mars.

However this would not open after a Java Update had run and having checked the error message that Eclipse generated, I ended up having to document the steps needed to fix the issue.    Java Update would install a new version of the jre, but the configuration setting file for Eclipse Java Mars was not "told about" it .

I ended up installing on my Windows 10 PC and now on the Windows 11 PC,  Eclipse IDE for Java Developers.  It would of course be nice if this version could either detect the presence of a new version of the jre (and make changes accordingly) or even better have its own jre.

I'm not familiar with Eclipse "Java Mars". I use Eclipse version "Java 2025-09", which is the latest. This version doesn't directly support JDK-25 though, it  requires a plugin which you can get by going to Help > Eclipse Market Place and searching for "java 25".

Eclipse Mars comes from the time that Eclipse used codenames for their releases, see Releases. Mars (Eclipse 4.5) was released in 2015.

They ran out of familiar solar object names and switched to a release-date naming format, as Rob has noted. If I'm not mistaken, the general schedule is to release every 3 months, so the next version (presumably supporting Java 25) would be the 2025-12 release. And I am very grateful that upgrading Eclipse releases has been made more automatic and less traumatic than it used to be. Relatively. When they made the minimum JVM that Eclipse would run under be Java 17 (21?) I had a jolly time telling Eclipse where I had it installed. I'd forgotten where the master Eclipse config file was.

I doubt that Eclipse Mars supported anything higher than about Java 8, if that. It's way too old to use for Java 25 development.

If you're going to upgrade to the latest JDK, which I think you should, then absolutely update to the latest Eclipse.

Tim Holloway wrote:They ran out of . . . names . . .

If they will use names in alphabetical order, they are going to run out sooner or later.

Tim Holloway wrote:. . . I doubt that Eclipse Mars supported anything higher than about Java 8 . . .

It came out before Java9; the link Rob posted says it required a Java7 runtime.