I have to update my legacy project from JVM 1.6 to 1.8. Obviously, I'll need to make some changes like install JVM 1.8 on the server that the code will run.
My project is Java based.
What tasks do I need to do to accomplish this?
What risks or complications should I be aware of and plan for?
I'm using Maven. Do I have to make changes to my pom files?
do I have to make changes to my startup bash scripts?
what do I need to do to ensure that the code is compiled under 1.8?
links:
Upgrading existing Java Project from Java 1.6 to 1.8
Just compile using jdk 1.8 and check for any warnings about
deprecated methods.
Java 8 introduces lots of features like lambda streams..etc, try to enhance your code wherever required. (its not mandatory though)
Always good to use latest dependencies
No changes are required to start bash scripts
Since youare migrating from java 6 to java , you could use try with resource feature which is introduced in java 7.
Try to enhance your code wherever it is applicable. Good luck
Related
I have java EE artifacts like .jar , .war, .ear files compiled and running in java 1.6 version. i wanted to run them (.ear file [.jar + .war]) in latest java versions like java 1.8.
Which Option would be the best considering moving to new java version.
1) Recompile Code in 1.8 and deploy to Application server
- to be at a little safer.
2) Just deploy to java 1.8
- No Code Compilation required (means .ear file generated using java 1.6). .ear file can be safely deployed to latest java 1.8 version
- probably we wont end-up having runtime issues ?
As this this is a production code base and no developer. Hence No Code changes in either cases, the only change is java version. I prefer going with Option-1, as compilation in higher version of exiting java classes to avoid any runtime issues.
Any thoughts ! or other useful options in this regard.
Thanks
As #Stultuske mentioned you only telling no code changes possible in either cases then your first case not valid one only.
But anyway as per java(Oracle) compatibility specification Java 8 is backward compatible with previous versions for sure no doubt about this except some very rare cases where binary incompatibilities happened.
For more information about this you can refer below stack overflow link --
Can newer JRE versions run Java programs compiled with older JDK versions?
Recently I did a similar thing but we updated the code/dependencies if needed.
I will suggest recompiling the code base first because this will tell you quickly if it or any dependencies don't support the newer Java version. If compilation is successful, then deploy to test environment and do sanity, regression, etc.
I hope you aren't talking about deploying to Production environment directly :)
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 am currently working on java 1.7 standard version, and I am really fun of the new features:
Nio(new input out put)
non redundant code with collections
...
I want to know if there is a way to switch the class I want to execute depending on the version of (JRE)java runtime environment it will be deployed.
You first need to create some sort of launcher app in order to check the JRE version of the environment, then you can lauch the JAR compiled for those version of the JRE. Your code cannot be compiled to newer versions of the JRE and be executed in an older one. That's why you need to complie the launcher app targeting a very old JRE.
As a side note, you can obtain the JRE version in which your program is running using:
System.getProperty("java.version")
The Java class file(s) are almost always binary compatible with new versions of the language (and the few exceptions, like using enum before the keyword was added, are fairly rare). If you restrict your usage of features to the "lowest common denominator" it is possible to compile back to an arbitrary version. That being said, Java 7 is now quite long in the tooth and I've found Java 8 to be remarkably stable. Finally, if you do choose to use new language features (like lambdas) you cannot use the earlier version of the language.
You can create two compiled build for both version to use language feature differently and have them running on jre 7, but you should just upgrade code compatibility and runtime to 1.8 (Even better)
I have developed a Java Application in Eclipse using JDK 1.7.0, the application runs and everything works as expected.
Now I would like to send the application to a colleague of mine who is using a different version of the JDK. He is using 1.6.x.
I am not interested in him opening up the application and debugging through it in Eclipse. I would only like him to run it. If I make a runnable .jar of the application and send that to him, would it work even though he has a different JDK installed on his machine?
Thank You.
You need to compile it using JDK 1.6 (or lower). Provided your code doesn't use features from Java 7, you won't have to change anything in your sources
It would work if your colleague had a newer JRE than the JDK you used to compile it. All versions of JRE are backwards-compatible with all class files built with previous versions, but the opposite can clearly not work because new versions introduce new features. Your colleague will get an UnsupportedClassVersionError.
However, it is easy to set up in Eclipse the target class version for your project: go to Project Properties, Java Compiler, and under JDK Compliance choose the version 1.6.
Needless to say, this will fail if your source code uses any features or library calls which the version 6 does not support.
I've recently moved to Java 7 in one of my projects. I claim that it can run on Java 1.5 simply because there's nothing I depend on that is in Java 6 or 7. However when compiling today I noticed this:
bootstrap class path not set in conjunction with -source 1.5
Google has found little information on this warning. Does this mean that you can't compile to Java 1.5 from Java 1.7?
This Oracle blog explains the warning:
http://blogs.oracle.com/darcy/entry/bootclasspath_older_source
The reason is, that if you fail to set rt.jar for the older platform, then:
If the second step is not taken, javac will dutifully use the old
language rules combined with new libraries, which can result in class
files that do not work on the older platform since references to
non-existent methods can get included.
Does this mean that you can't compile to Java 1.5 from Java 1.7?
No it doesn't. It means that there is a right way and a wrong way to do this ... and you are doing it the wrong way.
The right way to compile for the Java 1.5 on a Java 1.7 JDK is:
Get hold of a copy of the "rt.jar" from Java 1.5 and put it on the compilation bootclasspath.
Compile with -source 1.5 and -target 1.5.
The warning message is telling you that you haven't done the first of these.
The way that you are building right now is implicitly using the 1.7 version of "rt.jar" for the Java runtime APIs. This may work! (Indeed, it should work assuming that you've made no changes to the code since it last built on 1.5.) However, there is a risk that you may accidentally introduce dependencies on classes or methods added in Java 1.6 or 1.7. That would result in runtime errors when you try to run your application on Java 1.5.
You better be setting -source and -target 1.5.
To be really sure that you aren't accidentally incorporating dependencies on newer classes, methods, or fields, use the maven-animal-sniffer plugin or something like it.
--source 1.5 will make sure the source files comply with Java 5 conventions. --target 1.5 will make sure the generated class files comply with Java 5 conventions. Neither of these will protect you from using Java 6 or 7 library methods. You must either compile against the appropriate rt.jar using --bootclasspath, or use something like the animal-sniffer-plugin (if you are using maven) which will inspect everything's type signature, and compare with published profiles.
With the animal-sniffer-plugin, you may be in for a treat, because you can bump into 3rd party libraries that use Java 6 APIs, which may cause your build process to fail given you are pursing Java 5.