DEV Community

Sylvie Fiquet
Sylvie Fiquet

Posted on

Which Java version?

I got into a rabbit hole when I needed to purge secret data from a repo and I learned about BFG repo-cleaner.

The thing is, it's written in Java and it requires a Java Runtime Environment (JRE) to run. Having been bitten a few times by not keeping stuff up to date (looking at you, Ruby), I checked my current version, which is 9. I think I installed it a few years ago when I was helping my son set up Eclipse for a uni project. I think I also have a version 8 JRE downloaded from somewhere in my system as well.

Because I haven't touched Java for years, I set out to find out which version of Java I should have, both to run programs and to develop (since apparently Java is so great for back-end), and I'm utterly confused.

What I found out:

  • Java 8 is free for users and developers. However it's super old and apparently only supported until Dec 2020 (according to Oracle's FAQ).
  • There is an open source version of the JDK available for developers on The current version is 15.
  • Oracle keeps a tight grip on the JRE. As a user, if you run a java app for your business, you have to pay a subscription. If it's for private use, you don't. But they point you to where the latest JRE is version 8. So I have no idea how you'd run a program made with JDK 15.

So my question is: If you write programs with the latest open source JDK, say JDK 15, which JRE are your (non-business) users running? Do they have to install the JDK? Or do you distribute the JRE that comes with the JDK? Or do you bundle the java program into some sort of executable, like you can do with python? Or... what?

I couldn't find an answer so maybe I'm asking the wrong questions. I'd be grateful if someone could shed light on this.

Top comments (4)

jennrmillerdev profile image
Jen Miller • Edited

I work with Java and there are tons of discussion over Oracle's licensing changes - enough to drive a person insane!

In terms of Java distribution, at one time, it was Oracle, but with the Oracle's license changes, I know many places that have switched over to one of the Open JDK versions. Right now, the financial institution I'm at is switching to AdoptOpenJDK.

So, we always stick with a long term support version (Java 8 and 11). We are bound by our upgrade policy to keep up and by sticking with a LTS version, you get updates with reduced risk of breaking changes from upgrading a major number version.

If you are building a desktop application, a common practice is to wrap your Java program in a executable that starts up the JVM. Our software (for business users) come with a installer and users run it as a normal program. Under the hood, it is invoking a Java program. We ship with a JRE, it is AdoptOpenJDK (version 8 or 11). This means users do not have to install a JRE (or JDK) of their own.

Hope that helps!

sfiquet profile image
Sylvie Fiquet

It does! AdoptOpenJDK looks like a great solution. Thanks a lot!

nestedsoftware profile image
Nested Software • Edited

I think that a lot of the time these days, Java is used for server-side applications. In that case you only need to deploy to your own server environment and make sure you provision that environment accordingly. The users would then use a client application written for the web or mobile to access the server via rest or graphql...

If you've written some kind of open source tool in Java that people would include in their own software, I think you'd want to make it available in something like a maven repository. Then people can include your tool as a dependency as part of their gradle or maven build...

The case where you'd write a client-side application in Java is much more rare these days - not like in the early days of Java with Java applets and Swing applications. If you are developing a client-side app, I think you'd probably bundle Java along with your application. For example, I think the Jetbrains IDEs like IntelliJ, PyCharm, etc, are written in Java and they bundle a jre with the product.

sfiquet profile image
Sylvie Fiquet

That's very helpful, thank you.