Switching from Java 8 to Java 11 is more complicated than most updates. Here are some of my notes on the process.
Modules
Java 9 introduced one of the biggest changes in the history of Java modules. Much has been said on the subject, by other people. A key point is sometimes forgotten:
You do not need to modulate your code to update to Java 11.
In most cases, the code that runs in the class path will continue to run in Java 9 and later, where the modules will be completely ignored. This is terrible for library authors, but optimal for application developers.
So, my advice is to ignore the modules as much as you can when upgrading to Java 11. Transforming your application into Java modules can be a useful thing to consider in a few years when the free software dependencies really start adopting the modules. At the moment, trying to modularize is only painful, since few dependencies are modules.
(The main reason I found to modularize your application is to be able to use jlink to reduce the size of JDK.) But, in my opinion, you do not need to fully modulate to do this - just create a single jar - with dependencies with a simple no- requires no-exports module-info.)
Parties excluded from the JDK
Some parts of the JDK were removed. These were parts of Java EE and Corba that no longer fit the JDK or could be maintained elsewhere.If you use Corba, then there is little that someone can do to help you. However, if you use the Java EE modules, the correction of the deleted code should be simple in most cases. You just have to add the appropriate Maven jars.On the Java client side, things are more complicated with the removal of Java WebStart. Consider using Getdown or Update4Jinstead.
Unsafe and friends
Sun and Oracle have come to developers for years that do not use the sun.misc.Unsafe and other leading edge JDK APIs. For a long time, Java 9 was the launch where those classes disappeared. But that never really happened.
What you can get with Java 11, however, is a warning. This warning will only be printed once, on the first access to the restricted API. It is a useful reminder that your code, or a dependency, is doing something "impertinent" and will have to be corrected at some point.
What you will also discover is that Java 11 has several new APIs designed specifically to avoid the need to use Unsafe the friends. Make a priority to investigate these new APIs if you are using an "illegal" API. For example, Base64, MethodHandles.privateLookupIn, MethodHandles.Lookup.defineClass, StackWalker and Handles Variables.
Tools and Libraries
The modules and the new biannual launch cycle conspired to cause a real impact on the use of tools and libraries that developers use. Some projects were able to accompany. Some have fought. Some failed.
When updating to Java 11, an important task is to update all its dependencies to the latest version. If there is not a posting since Java 9 was released, then this dependency may need additional attention or testing. Make sure you have updated your IDE as well.
But it's not just the dependencies of the applications that need to be updated, as well as Maven (and the Gradle too, but I do not know much about the Gradle). Most Maven plugins have changed major versions to v3.x, and upgrading Maven itself to v3.5.4 is also beneficial.
Unfortunately, the maven's main equipment is very small, so there are still some errors / problems to solve. However, if your Maven construction is sensible and simple enough, it should usually be fine. But note that updating a plug-in from a v2.x to a v3.x can involve changes to the configuration in addition to those associated with the modules. For example, the Maven Javadoc plugin has changed the name of the argLine property.
An important point to be observed is the way in which Maven operates with the modules. When the Maven compiler or surefire plugin finds a jar file that is modular (that is, with a module-info.class), you can place that jar in the module path instead of the class path. In this way, even if you want to run the application completely on the classpath, Maven can compile and test the code partially on the classpath and partly on the module path. At the moment, there is nothing that can be done about it.
Sometimes, your compilation will need some larger changes. For example, you will have to change the Findbugs for SpotBugs. And change the Coverage to JaCoCo.
These compilation changes may take some time - they did it for me. But the information available for a simple investigation on the web is increasing all the time.
Summary
I have updated several Joda / ThreeTen projects to support Java 9 or later now. It was very painful. But that's because, as the author of a library, I have to produce a jar file with module information that is built and executed in Java 8, 9, 10 and 11. (In fact, some of my jar files run in Java 6 and 7 too!)
Having made these migrations, my conclusion is that the pain is mainly in maintaining compatibility with Java 8. Moving an application to Java 11 should be simpler, because there is no need to get stuck in Java 8.
To getting expert-level training for Java Training in your location – java training in chennai | java training in bangalore | java training in pune | java training in chennai | java training in bangalore | java training in tambaram | java training in omr | java training in velachery | java training in annanagar | java training in chennai | java interview questions and answers | core java interview questions and answers | java training in marathahalli | java training in btm layout | java training in jayanagar | java training in chennai | java training in usa | For getting java online training | java online training
No comments:
Post a Comment