Sergey Nivens - Fotolia
While the Java SE 9 release has everyone talking about new features and syntax enhancements, JNBridge's Wayne Citrin insists legacy Java developers need not feel left behind.
When the talk of the town is all about the latest Java platform release, it's easy to feel sorry for the legacy Java developer, who must now learn new language features and syntax enhancements that software architects always get excited about. Integrating new features into old software tends to create a great deal of anxiety. The potential that a software engineer might break something that isn't broken always looms, like the sword of Damocles. But things are a bit different when it comes to Java 9, and legacy Java developers should be equally excited about many of the latest language enhancements.
"When a major new release comes out, there's really no room for legacy Java developers to actually take advantage of this stuff because of the fear that programming against new APIs and new language constructs will break support for the old stuff," JNBridge CTO Wayne Citrin said.
Or at least, that's been one of the safe strategies organizations have employed in the past. But enterprises shouldn't be so hasty when it comes to applying the brakes on Java 9.
Due diligence is understandable when it comes to maintaining legacy Java code, but completely eschewing new language features borders on indolence. When the production environment migrates to a newer version of the Java virtual machine (JVM), there's really no reason not to start modernizing the code base of legacy Java applications. "With Java 9, legacy Java developers don't have to tune out the new stuff," Citrin said.
Legacy Java and multirelease JARs
Wayne CitrinCTO, JNBridge
One of the most empowering attributes of the Java Platform, Standard Edition (SE) 9 release is the multirelease JAR file feature. With multirelease JAR files, legacy Java code can actually be rewritten using new APIs and features. If an application hasn't been migrated onto the latest version of the JVM, though, a release that only uses older code environments can be generated and deployed. Then, a separate JAR file will simultaneously be created that will work on the latest JVM. So, a single code base can kick out multiple JAR files, with each file targeting a different runtime version.
"If it's multirelease, it will still work with your legacy stuff," Citrin said. "I think it's a great innovation in Java 9, and we're looking forward to using it."
Future legacy Java code
Of course, the applications written for the latest JVM release will eventually become legacy Java code. And while they weren't created exclusively with legacy Java developers in mind, the new modularity features that come with Java 9's inclusion of Project Jigsaw will make application maintenance easier and less riddled with anxiety. With modules, Java 9 code can be both separated and isolated from other parts of the system. These modules can be independently tested, independently updated and independently deployed. So, when old modular code needs to be updated, there's no risk of impacting elements outside of the updated module.
Maintaining legacy Java code isn't nearly as fun as working on brand new projects that use all of the latest and greatest tools and technologies. But so long as we port those old applications to a newer version of the JVM, there is no reason to hold back from using new Java platform features.
Legacy Java users users can still introduce modules, use multirelease JAR files and take advantage of the many new APIs and security features that come with Java 9. The new code will run just fine on the latest JVM, and the code itself may even become easier to manage.