Develop Reference

What JDK should I compile with to support most desktop users? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 months ago.
Improve this question
I write a few small, free, desktop command-line applications in Java. I package those as JAR files in releases on GitHub. About a year ago in light of Oracle licensing changes, I switched from the Oracle JDK to Open JDK. Developing on Windows, this is what I currently have installed:
C:\Users\admin>java -version
openjdk version "17.0.1" 2021-10-19
OpenJDK Runtime Environment (build 17.0.1+12-39)
OpenJDK 64-Bit Server VM (build 17.0.1+12-39, mixed mode, sharing)
Now, about a week ago I was visiting a friend (also a software developer) and a reason came up where we wanted to run my application on his Windows box. He didn't have Java installed. So, watching over his shoulder, he went to the java.com "Download Java for Windows" page (currently listing Java Version 8 Update 341), downloaded, and installed it.
Then when he went to run my application, it failed to run, giving back an error along the lines of (paraphrasing from memory), "This version of the JRE does not support a later version of Java". This surprised both of us; he didn't know there was a later version of Java, and I didn't know compiling with the current OpenJDK would make a non-supported binary.
What's the best practice to fix this release problem?

Your user most likely ran into the issue that Java classes compiled with a newer class file version number do not run on older JVMs. If that is the only issue it can be addressed by recompiling ...
But there is a deeper issue. Older Java class libraries don't support all of the APIs provided by newer versions of Java. Also there have been some important architectural changes starting in Java 9 (e.g. addition of modules, removal of applets and closing off access to JDK internal classes) that "break" applications that run on older Java versions
What this means is that if you develop and test your code on Java 17 (say) there is a significant chance that it won't work on (say) Java 8 ... even if you compiled it for Java 8. And vice versa, because some APIs have been removed, or made inaccessible or ... work differently.
So my advice would be:
Decide on a specific range of Java versions you will support for your application; e.g. Java 8 LTS1 through Java 17 LTS.
Develop targeting the oldest Java version and its APIs.
Build and test on the Java oldest version.
Also test on (at least) all of the other LTS Java versions ... within the range you are supporting.
This will mean that you are limited to using the APIs and Java language features of your oldest supported version. This could hold you back, so you have to choose between that and supporting users with old (out of date) versions of Java.
The issue of users trying to install / use old versions of Java can be addressed in three ways:
Provide clear installation instructions to the user that say what kind / version(s) of Java they need to install, and where to get them from. (And how to set or configure JAVA_HOME if your application relies on that.)
Of course, some users won't read the instructions properly, but that is their lookout ...
Use jlink to turn your application into a custom JVM, and distribute your code that way.
Use jpackage to create platform specific binaries.
If you take the jlink or jpackage routes, the onus will be on you to push out new distributables whenever there are Java security patches that are relevant to your application. Your users won't be able to "just install the latest Java patches" anymore.
Note that jlink is available for Java 9 onwards, and jpackage from Java 16 onwards.
What JDK should I compile with to support most desktop users?
I don't think there is a good answer to that. We can't tell you what proportion of "desktop" users have each version of Java installed. (Or what they are permitted to install; e.g. by corporate policy.) But you can't support old Java versions indefinitely.
I did find this though:
Java 8 still dominates, but Java 17 wave is coming – survey - dated March 2022.
1 - Java 7 and earlier are all well beyond "end of life". You are not helping anyone by trying to support them.

Well, you have a few options...
First of all you can TARGET the version 8 runtime, but you can compile code from later revisions of the language. This may or may not work in all cases, as Java 9 and up do some things rather differently! Still, fairly vanilla Java that isn't doing weird ClassLoader stuff is LIKELY to work, and you can certainly avoid problematic constructs.
Secondly, you can simply stick to Java 8! It is ANCIENT but it is a virtually immortal LTS, due to the reason above that things in Java 9 are different. However, you will miss out on new things.
You COULD go whole hog and move on from Java 17 to GraalVM, which can be had in versions compatible with Java11, Java17, etc. It has the ability to compile code down to a completely stand-alone binary, using native-image, and again unless you do some fairly esoteric stuff, your code will work. The end result will be similar to using something like C++. You can even build shareable libraries.
I guess your other option is to just make sure people are not using Java8. Ideally they're using Java11, but I guess now java17 is the newest LTS, though few people seem to install it.

It looks like you are using Java 17. Developers of apps targeting Java version after 8 are expected to supply the runtime for running the application. This means there is no more 'downloading and installing Java' separately on the user side. This is also why the download page you refer to only offers Java 8.
In practice, this means that you should use jlink to create a runtime image (i.e. the thing that you would previously download and install) that can run your application.
jpackage can also be used to create application images and installers (it calls jlink under the hood). Both of those are tools that come with the JDK.
For your purposes I recommend using jpackage with something like this:
jpackage `
--win-console `
--main-jar app.jar `
--main-class Main `
--name myapp `
--type app-image `
--input input
In this command, input is a folder that has the main app.jar in it (Note: the input folder should not be the current directory, since that will lead to infinite recursion).
--win-console is also needed for console applications on Windows, since otherwise no console is created when running the app.
This command will create a myapp folder that you can zip/tar up and distribute.
This myapp folder has a myapp.exe launcher that can be used to run the application.
Also, note that this will create a runtime image with a default set of modules. If your jar is modular (i.e. it has a module-info file), I suggest using --module instead of --main-jar/--main-class, since that will use the module descriptor to determine the set of modules in the runtime image. (See jpackage --help)
Note that on Windows you will also need to install the wix toolkit. It can be installed easily through e.g. scoop:
scoop install wixtoolset

Java 7 and JavaVM.framework on mac

I played with Java 7 update 9 on mac a little bit and found an interesting thing.
I just ran a simple Java program with a JFrame, and attach to it with lldb. Then I checked libraries loaded by this Java program and I saw:
"/System/Library/Frameworks/JavaVM.framework/JavaVM" in it.
So i have 2 questions:
what does this JavaVM do for Java 7? I thought Java 7 on mac is self-consistent like its corresponding versions on Windows and Linux. By using "nm", I can see this JavaVM defined many functions like JNI_CreateJavaVM, which is also defined in libjvm.dylib.
what should I link to for JNI libraries with Java 7? still JavaVM.framework? Can I link to libraries located under
/Library/Java/JavaVirualMachine/jdk.1.7.0 directly.
Any help will be much appreciated.

For the first part, that JavaVM points to the Mac JavaVM (1.6). Taking a closer look at the Info.plist files, it looks like the Mac Java supports JNI (amongst other things), while the Oracle Java supports only CommandLine. It does not look like you can link to 1.7 on Mac OS X. There's plenty of related questions, too.
To find your JVMs that support JNI, do this:
/usr/libexec/java_home -t JNI
This should probably return the 1.6.0 JDK. You can run it with the -V argument to get a full listing of what JVMs are available.

The Oracle JDK on Mac is advertised to be just like the Oracle JDK everywhere else. It's got commands, headers, and libs. You should be able to use the contents of the JDK just you would elsewhere. We commonly create and use JNI libs that get loaded with LoadLibrary; I can't report personal experience with the invocation interface.

What are the pitfalls when upgrading to Java 7

I am switching an enterprise application built on Spring 3.1.0, Hibernate 3.6.0 from Java 6 32bit to Java 7 64 bit.
Has anybody done that? Any problems? Are there any resources on the subject?

Here are the pitfalls I know about:
You might have to upgrade your IDE to be able to enable Java 7 features.
Make sure that command line tools and your IDE use the same Java version. If you're using Maven, for example, look into $HOME/.mavenrc and/or check the environment variable JAVA_HOME
Check the source/target options of the Java compiler.
Java 7 supports generics better than Java 6 so some code will now compile that failed with Java 6
The 64bit version of Java uses a lot more memory than the 32bit version
The first release of Java 7 had a severe bug in the JIT compiler which broke Lucene. Use at least b2 or better.

Java 7 uses the newer JAXB 2.2 instead of 2.1 (the full change on the XML stack is described here). These versions are not compatible on generated code for Boolean getters and setters!

Regarding Java Version

presently there are many application programs developed using recent versions of java.how an end user in a network having old version of Java can be able to see the output? (perspective: different classes includes in new version of Java)

For applications that have been developed using recent versions of Java, there's no solution other than having users upgrade their Java runtime to the minimum version required to run the applications.
Note that it is not only the classes in the standard Java library, but also the .class file format has changed in ways that are not backwards compatible with old Java runtimes.
If you develop an application that targets a specific JVM version / Java specification, then you will need to ensure that all future application updates remain backwards compatible with this JVM version / Java specification.

If you want are asking how to find out the version of Java you are currently running, you can execute the following on the command line:
$java -version

OK fine.. but is that the user should have java runtime environment in which it should support should all objects that were created with new versions which were not in old version.

java jre confusion

Could anyone please tell how jre directory help in the running java programs? I'm calling java interpretor by using java command, and that is in JDK directory, then how could jre directory help in running java programs and jdk for compiling?

When you install the JDK (development kit, compiler and so on), you get the JRE (runtime environment) as part of that (under my install, there's actually a jre subdirectory in the jdk folder) - this is because you will probably want to run code that you develop if only to test it a little bit before inflicting it on the rest of the planet :-).
But it's by no means necessary to install the JDK to run Java programs. All you need is the JRE and that is, by far, the normal situation for most people out there.

The JRE is just the interpreter (java.exe or whatever) - it's a smaller install that is typically used by people who just need to run Java applications and aren't Java developers. The JRE handles the conversion and execution of java bytecode for the target platform.
The JDK is meant for developers. Along with the runtime it provides the compiler and all the Java libraries that are used to build Java programs. The compiler is responsible for converting Java source code to bytecode.
So - when you are delivering your Java application to customers, all they need to install is the JRE.

The Java Runtime Environment (JRE) interprets byte code to platform specific machine code. JRE is minimal set of programmes which executes the java class files.
The JDK (Java Developmental Toolkit) comes along with java libraries and JRE embedded in it. Apart from these it comes along with the utility tools for byte code compilation "javac".