IBM i Slated to Support Java 11
July 25, 2018 Alex Woodie
Don’t look now, but Java is in the midst of a major upheaval that will not change not only how the programming language is used by the wider world, but also how it’s used on the IBM i platform. For those running Java on the midrange platform, the forthcoming release of Java 11 is the one to watch.
While Java has (sort of) been open source since Sun Microsystems released the object-oriented language into the world 27 years ago, it took much more solid steps toward being a true open source project last year when Oracle announced plans to release all the features of the Java Standard Edition (SE) Java Development Kit (JDK) under a GPL license. Soon thereafter, Oracle made big open source contributions with Java Enterprise Edition (EE), which is now known as Jakarta EE (as we told you about in April).
As part of that change, IBM decided to contribute the Java Virtual Machine (JVM) technology that it’s used on the IBM i (and other platforms) for the last 12 years to the open source community. Specifically, late last year IBM contributed its J9 JVM to a new Eclipse-managed project called Open J9.
Amid all these changes, the Java community decided to overhaul the release cycle and naming conventions, too. Oracle, which still wields significant control over the open source project, decided to move to a six-month release cycle, starting with Java 9 (which shipped last September) and continuing with Java 10 (which shipped this March). It also decided to start a “year-dot-month” naming scheme, starting with the next release due this September, ostensibly called Java 2018.9.
However, because the Java 9 and 10 releases would only be supported by the Java community for a maximum of six months, IBM decided to skip those Java versions, leaving Java 8, which initially shipped back in 2014, as the latest version of Java on IBM i. The next release of Java that IBM planned to support on IBM i would be the forthcoming Java 2018.9 release.
In the past month or so, the Java community has ditched the year-dot-month naming scheme, and reverted to a conventional numerical scheme. That means the next release of Java to be supported on IBM i is Java 11.
So when will Java 11 ship? That’s still up in the air. “We don’t have concrete days right now when Java 11 is coming,” says Jesse Gorzinski, the IBM i architect for open source. Part of Gorzinski’s job is shepherding new releases of Java onto the platform, and he has his work cut out for him these days.
As Gorzinski explains, Java 11, which is currently under development, brings a lot of significant changes to the language, and those changes will have a sizable impact on the IBM i platform as well.
For starters, the Java community is making “significant changes to how applications are packaged and distributed,” Gorzinski tells IT Jungle. “So they’re starting to do away with the old classpath technology that Java has been using since almost its inception.” Instead, the Java community has shifted to using Java modules.
This shift from classpath to modular technology spells big changes for any Java application, Gorzinski says. “Java applications might break when they go from Java 8 to 11, and that’s kind of scary,” he says. “With every major JDK of Java, you have that possibility. With Java 11, it’s probably a little more likely because there’s a lot of significant changes in the language itself.”
The good news is that most of the Java carnage will likely be constrained to middleware, he says. “Right now we suspect that the highly impacted applications will mostly be middleware, so things like WebSphere,” he says. “WebSphere is going to have to change significantly. Maybe they already have – but in any event WebSphere needs to change to support Java 11. But the applications using WebSphere are probably not impacted. Or at least, if they are, they’ll be impacted minimally in line with what we’ve seen with other JDKs.”
Any IBM i developers who write in Java and want to keep their apps current will obviously need to account for the changes in Java 11. The good news is that, for IBM i customers, the Java installation and support experience will not change much, according to Gorzinski.
“When the next major version of Java is available, there’s going to be a new JV1 option for it, and they can install it just like they have installed the JV1 option in the past,” he says. “So in that regard, it’s going to be business as usual for IBM i customers. But they do need to be aware of language changes and just be aware of if the versions change. They just need to know what’s going on.”
Gorzinski stressed that, even though IBM has put the JVM used by IBM i into the open source realm with the Eclipse J9 project, that doesn’t mean that IBM is no longer involved with its development.
“IBM isn’t decreasing development effort into the Java product,” he says. “We’re just open sourcing it and relying on the community [to contribute]. We’re still contributing the same amount – possibly even a little more. We’re still investing with all the same people, all the same skills, but we’re also letting the community add to that innovation that’s happening.”
Remember OSGi? No one else does either.
1. Modules address the “classpath hell” problem. No deployed legacy app suffers from classpath hell; if it did, it wouldn’t be deployed. No existing app will be updated to fix what’s not a problem.
2. The Eclipse IDE will still support app development with classpath so new apps will continue to be developed just as legacy apps have been.
3. No shop wants two deployment paradigms confusing the websphere engineers; it will be years before they have the paperwork supporting deployment using Java modules.
4. If I had a classpath problem, I would break out the smaller piece that relied on a different version of a JAR & create a separately deployed service. Problem solved.
5. Java modules is consultant ware and will be a huge waste of money for those so afflicted.