I have an application which I would like to deploy, compiled for java 1.8.0_151. However, the user has only 1.8.0_25. User cannot launch the app because LocalDateStringConverter is missing.
As written here (https://docs.oracle.com/javase/8/javafx/api/javafx/util/converter/LocalDateStringConverter.html) this class has been added only in 8u40
How can I compile (is it possible?) a jar with dependencies for the specific java version of the user?
Or maybe I misunderstood something, new to java here
EDIT I tried specify the pricise version with update number in my pom.xml but it didn't help
There are a two ways to approach this:
You have to set your environment to use the JDK that is expected by the user. In this case 1.8.0_25 - you need to develop all logic using this JDK and the classes available in it. If LocalDateStringConverter is your only dependency missing, you can easily find out the source code and duplicate the logic inside your project as utility class and use that instead.
You can ask/help/advise your user to upgrade their environment to more recent JDK version (security reasons and such). As you are aware most software has minimum requirements to run and it's expected from the end user to meet those requirements in order to run the software.
As already mentioned you can use the Maven Enforcer Plugin to enforce specific java version, but this will not make the functionality from 1.8.0_151 available in 1.8.0_25.
Compiling your code with 1.8.0_25 and hoping that the newer versions are backward compatible is probably the easiest solution. Assuming you have automated tests this will catch problems like a missing class.
The other option would be to build an executable bundle containing both your application and the entire JRE 1.8.0_40 or newer. This is going to result in your software bundle growing by dozens of MBs so I would not recommend it. However one way to do it would be to use Launch4j as advised here.
You can try implementing your own LocalDateStringConverter but how many other classes are you missing? What if there are other subtleties in behaviour between versions? Based on java.com 1.8.0_25 was released on October 14, 2014 while 1.8.0_151 on October 17, 2017. That's 3 years of Java development that your user is missing.
Related
We have a standalone application built using Java 1.8 and when I test running that application using Java 9, I get a NoClassDefError exception on the javax.xml.soap.SoapException class. I have read enough to know that Java 9 now has the module concept... and that if I add the "--add-modules java.se.ee" option on my 'java' call in the startup script for the application, it then runs correctly.
My question is... how do I still support this application running against a 1.8 JRE? I can't just put the --add-modules option in the startup script since that causes an error when attempting to run against the 1.8 JRE. I really don't want to have to put logic in the startup script to try to determine which version of JRE the user is running and optionally put the new --add-modules option in there.
Any suggestions? Thanks in advance!
You should include java9 specific information 'module-info.java' into your application, so it will not require the command line option. See e.g. here: How to add a Java 9 module via manifest.mf?
The web services module (java.xml.ws, which includes SAAJ) has been deprecated in Java SE 9 with a view to removing it from Java SE and the JDK in the future. The first step on that road to removing it is to not resolve it by default. It is "as if" the module does not exist and this is why you get a CNFE when you run it on JDK 9.
Yes, you can workaround around it temporarily with --add-modules=java.xml.ws (more precise than --add-modules=java.se.ee) and you should be able to get your script to pick this up using the JDK_JAVA_OPTIONS env variable (see http://jdk.java.net/9/release-notes#JDK-8170832) which is new in JDK 9 and so will be ignored in JDK 8.
The alternatives (and the JDK 9 Migration Guide will have more on this) is to move to the standalone version of JAX-WS and SAAJ. These APIs have standalone versions that update at a different pace to Java SE and the JDK. You should find the latest (2.3.0) in Maven for example. The standard versions can be deployed on the class path, and in the future as modules in the event that you migrate your application to modules in the future.
Please take a look at this article. This gives the ways to solve the compatibility concern that you have raised.
https://dzone.com/articles/the-legacy-developers-guide-to-java-9
Please include module-info.java file in your application. Java 9 will consider the same and will be ignored by Java 8.
My existing server is running on Java 1.6 and I cant upgrade it.
I need to use some third party jar/api that is compatible with Java 1.8, when I write some code to access its API, eclipse throws
Exception in thread "main" java.lang.UnsupportedClassVersionError: JVMCFRE003 bad major version
How I can proceed now? Not sure if this is duplicate question, if yes please provide some link on this.
The point is: Java virtual machines are not forward compatible.
A .class file that was generated by an "n+1" compiler can't be used on a "n" JVM. (unless you specifically instruct the compiler to compile for older versions of java)
Your choices:
see if you can acquire a version of that library compiled for Java 6
see if you can run your application on a Java 8 JRE (there is no problem running java6 classes on a newer JVM!)
Option 1 can get pretty ugly - as that library might have dependencies on system classes that Java6 doesn't have.
This is not possible to use multiples Java version or even multiples JVMs in the same project
If you really need this API, then you have just few choices, the best one is to upgrade all the project to use Java 1.8
No, you can't use jars compiled under java 1.8 in an environment running at java 1.6
As others have pointed out, you can't do this. However, you may be able to find older versions of the libraries you wish to use, and those libraries may support your particular version of Java. This potentially means that you will be adopting bugs into your software, but that's just how software evolves over time.
If you must use this 3rd party jar,
then you must compile the 3rd party jar using -target 1.6 (to target java 1.6).
Maybe you will get the source and compile it yourself or maybe you will get somebody else (the vendor, perhaps) to compile it.
All other options are:
Upgrade your JVM to Java 8.
Don't use that 3rd party jar. Either write or find one that is compatible with java 6.
Recently I was assigned to a task wherein I have to upgrade the existing standalone java application from Java 1.6 to Java 1.8.
I'm yet to go through the code and I have no idea about this project.
They were using
ANT 1.6.1,
AXIS 1.5.1,
ABINITIO 2.15,
ORACLE 11.1.0.7,
AUTOSYS R11,
Java 1.6.
I got to know that first I need to identify whether the above mentioned Tools/Frameworks are compatible with Java 1.8.
Please suggest what are the other challenges I might encounter while compiling and building the application?
Although Java is supposed to be backward compatible between versions, it's also known that backward compatibility in any language isn't aways as straight forward as the name suggests. Some (most) projects release it's libs versions compiled specifically targeting one or another development kit, to take advantage of new features and enhancements added to the language.
That being said, I believe the smarter way to go would be: first, update the project's JDK and rebuild it targeting the new bytecode's version. There's a chance you'll have to upgrade both Ant and (if that's your IDE of choice) Eclipse (see here why).
Second, you'll have to check for compilation errors, which will most likely lead you to update libraries conditionally to get them fixed. With those solved, you MUST run your app and see if it's running as intended; remember that compilation problems are just the top of the iceberg when the subject are dependencies.
Carefully check the app's logs looking for exceptions of any kind but mainly the ones related to class loading exceptions such as ClassCastException, ClassNotFoundException, NoClassDefFoundException, UnsatisfiedLinkError and others. If any apear, you'll have to pinpoint one by one and search for the specific solution of the specific troublemaker library.
With all that covered, you should have your app running healthily again.
One last hint, if this project of yours is still being developed, it would be a very good practice to keep the tools you use updated to their very last release. Keep also the development tools updated, like build (such as Ant, Maven, Gradle and others), JDK's and IDE's. It way easier to upgrade the pieces as they are release than to handle a mass scale upgrade :)
Here is a small explanation of my problem.
I have an application which was compiled with java 1.5. This application is installed on 2000 pc (blockboxes) installed at customer premisses.
The jar of my application is often updated to add new feature and fixes, but for technical reasons, it is not very easy to update the java version, so I must keep using Java 1.5 on those existing machines.
Few months ago, I got a request for a new requirement for this application. To fulfil this task I have added the usage of Hazelcast in this application.
My problem if the following:
- Hazelacast jar file needs Java 1.6 or above, so I must compile my application with 1.6
- The new functionality using hazelcast will only be activated on demand by settings a new parameter. This means that it will not be used in the 2000 already installed blackboxes.
- All new blackboxes will be installed with Jave 1.6 or above to be able to use the Hazealcast functionality.
My problem is that I want to have a unique source code and unique version of my application for old blackboses using Java 1.5 and new blackboxes using 1.6 or above.
In the beginning, my idea was to always compile with version 1.5 and make sure that the new functionality would only be activated in blockboses using java 1.6 or above. This option is not working, because when I compile with 1.5, the compiler complains that Hazelcast jar file needs 1.6 :(
The second option would be to compile with 1.6, but then I cannot be sure that my application will still work properly on all blackboxes using 1.5. :(
I'm would like to know if someone here would know how to solve this kind of problem?
Just let me know if my explanation is not clear ;)
Thanks in advance for your help.
JVM is Backward compatible.You can run almost all code from Java 1 on Java 8.
So the best way is to use the option two. Compile it with 1.6 on some testing machines. And if it works( which most probably will) you don't have to make much change to the application .
You can compile your code to Java 1.5 bytecode using JDK 1.6, just take care of the following:
-source=1.5 and -target=1.5 compiler options
bootclasspath should point to rt.jar from JRE 1.5
See this post for more info: http://www.draconianoverlord.com/2014/04/01/jdk-compatibility.html
The post also recommends simply building your application with older JDK if possible. You need to figure out a different build process and exclude incompatible libraries from the classpath. If you use Maven, consider having two pom.xml files, with an optional parent file.
I developed a plugin using Eclipse Indigo. It depends merely on the usual suspects like org.eclipse.core.runtime etc., there is only a single unusal prerequisiste org.eclipse.imp.runtime.
I am quite sure that the latter should run with 3.5.
Now I have the problem telling potential users what Eclipse version they'd need at least to install it.
Will it even be installable on previous versions when developed with 3.7?
If so, how can I find out what the minimal required versions are (I hope that I do not need to edit version numbers etc. in the plugin.xml?)
If not, does this mean I have to install, say, Eclipse 3.5 somewhere and build it there if I want to support 3.5 and higher?
Can this help you: http://help.eclipse.org/indigo/index.jsp?topic=%2Forg.eclipse.pde.doc.user%2Fguide%2Ftools%2Feditors%2Fmanifest_editor%2Fdependencies.htm
It is said, that:
You can also specify the Minimum Version and Maximum Version of the plug-in dependency.