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.
Related
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
I'm going to develop a complex Java application which should run on a machine with Debian 8.6 and JRE 8u71 installed. Furthermore, the application makes use of some Java classes, developed and compiled in Matlab.
By now, Matlab (Version R2015b - R2017a) supports Java version 7u61.
So I would like to know if anyone has some experience with using Matlab and a JDK 8 installation. I know about following article:
http://de.mathworks.com/matlabcentral/answers/130359-how-do-i-change-the-java-virtual-machine-jvm-that-matlab-is-using-on-windows
but I'm not sure if this is quite a good idea. Furthermore, will this change the Java version of the Matlab Compiler Runtime as well?
For testing it is also necessary for me to integrate some Java classes (version 8u71) in Matlab.
Any help is highly appreciated.
Thanks in advance!
I've been using Matlab 2015b with Java 8 on both Windows and Linux for a while now (through setting MATLAB_JAVA environmental variable), and never experienced any issues (unlike when I tried using some older Matlab versions with Java 7). This lets you use java classes compiled with Java 8, i.e. all the fancy language features like lambdas etc.
I have a Play 2.2 app I'm using with Java 8 that I'm having trouble getting to work. The code compiles locally for me using OpenJDK 1.8, but when I try and push the code to Heroku, I get the following error, which was the error I was getting earlier locally when I was running on OpenJDK 1.7 with lambdas by accident.
java.lang.RuntimeException: Unknown constant: 18
I set system.properties to use Java 1.8 and I know that's working because it's starting up with the following text:
Play 2.x - Java app detected
-----> Installing OpenJDK 1.8...done
Is there something I'm forgetting to do to update to Java 8?
I tried updating the PATH as well as specified here but that didn't do anything.
Unknown constant: 18 most probably refers to CONSTANT_InvokeDynamic tag in the class file’s constant pool which has the value 18. This can’t be a JDK issue as even Java 7 understands that tag.
So it is an indicator for a byte code manipulation tool running in your runtime not understanding newer class files (but trying to process them despite the unknown version number). That worked with Java 7 as the invokedynamic feature exists but is not used with ordinary Java 7 class files (i.e. produced by javac).
Since you knew if you used bytecode manipulation by yourself, it must be part of a framework, i.e. you named heroku and the playframework. So you problem is not about updating the JDK but updating the frameworks to Java-8-aware versions, if such versions already exist.
As an add-on to Holger's response, here's what Heroku support had to say:
Hi,
Java 8 is still on an old pre-release due to delays on a linux distribution of OpenJDK. You can track the status of JDK 8 here:
https://github.com/heroku/heroku-buildpack-jvm-common/issues/10#issuecomment-38006175
My Java applet only supports 1.4 java run time(1). I am having one machine on which both Java 1.4 and 1.6 environment is installed. Is there some setting available by which I can make sure my applet will always use Java 1.4 run time when it runs?
We are using key event class private data array bData with the help of Java reflection. The data which is there in this array JDK 1.4 and 1.6 is different in both the version.
A Java application compiled with JDK 1.4 will run on JDK 1.6.
You can compile a Java application with JDK 1.6, but compatible with JDK 1.4 by configuring the 'source level'.
Although you can choose your default JDK to be safe, but it depends on your operating system. If you are on Linux, you can choose between available Java versions using pdate-alternatives --config java command (which will modify some symlinks in the hindsight).
On Windows 7:
Control Panel -> Programs -> Java
Select 'Java' tab, and View the Java Runtime Environment settings.
Ensure that your Java 1.4 entry is selected.
There's a way to force a specific installed version to run, but if one Java plugin replaces the other there might be an issue with this. See linked question for further details.
Force Internet Explorer to use a specific Java Runtime Environment install?
Are there any issues with running the 1.4 code on 1.6? If not, you should be fine. Just avoid using anything in the classpath that changed significantly between these versions. Otherwise, look [here][1]. The codebase download thing is interesting, since it lets you download a different classpath. So, regardless of the JRE version, you could force the download of a 1.4 JRE classpath, which should ensure full compatability.
Edit: found an updated guide to using previous classpaths with newer Java versions in applets, which actually seems to work:
http://download.oracle.com/javase/tutorial/deployment/applet/deployingApplet.html
Edit 2: I actually have it working, but it appears to need to download JRE 1.4 and install it, but then it will run the applet with it automatically. However, this might be suitable for your needs.
http://www.2shared.com/file/bl3Rua2e/applet.html -- extract the archive, and then run index.html inside this. All source code is included.
is it true that the java -version command returns the java version for the java that I use to browse the web, but the java version that I use in netbeans / eclipse can be a totally different version?
In fact can the version of java i use in netbeans and eclipse be different?
Or is it that a system only has 1 version of java that works throughout all applications?
is it true that the java -version command returns the java version for the java that I use to browse the web,
No, it returns the version that's first in the system path. The browser may use a different version.
but the java version that I use in netbeans / eclipse can be a totally different version?
Yes
In fact can the version of java i use in netbeans and eclipse be different?
Yes
Or is it that a system only has 1 version of java that works throughout all applications?
No
The version of Java that is used in the browser is defined in the control panel. This defaults to the version that is returned by java -version. IE uses a JRE.
When NetBeans is installed, it asks which version of Java to use, so this is not necessarily the same as IE, alkthough it may default to the same version JDK.
NetBeans and Eclipse can be configured to use a different version of the JDK than the standard one, so you can't guarantee that IE and NetBeans/Eclipse use the same version of Java.
On Windows, you can have as many versions of Java on a machine as you want.
You van have several versions of java installed. In eclipse.ini you can specify what VM it will use.
No, It can have multiple. You can set the specific java version to be used for your application by setting classpath for your application.