Java On IBM i: A Developing Situation
October 16, 2017 Dan Burger
IBM i developers in the Java camp have some changes in store as Java 9 replaces Java 8. First of all, there will be no IBM i support for Java 9. This break in tradition may come as a surprise for many IBM i developers, but not for those Java-holics who have been closely watching the Java 9 news. There are a couple of reasons IBM has decided not to support Java 9 on IBM i, even though IBM currently supports Java 7 and Java 8 and it has supported every Java release seemingly since Moby Dick was a minnow.
The cadence of Java releases supported by IBM i has been predictable. Oracle releases a new version of Java. Then IBM releases its support a short time afterward followed by IBM i support. IBM i users eager to move to Java 9 would have expected support before the curtain falls on 2017. Not going to happen.
“The truth is that a Java 9 delivery for IBM i is not very practical,” Jesse Gorzinski said during a telephone interview with IT Jungle last week. Gorzinski is the IBM i architect for open source and Java on IBM i. “Part of that is the new release strategy with a short support cycle. Oracle plans a feature release every six months. That allows users to access the latest and greatest features, but there’s not much there for a support roadmap when the next release is just six months later. Java 9 is one of the feature releases, so we are not delivering Java 9 for IBM i. We are going to deliver the next long-term-support release because that’s what makes sense to our customers.”
Jesse Gorzinski
A long-term release, Gorzinski says, would resemble Java 8, which GA’ed in 2015 and will be supported by IBM until April 2022. The Oracle Java SE Support Roadmap shows the next long-term support release scheduled for late 2018. In the meantime, the Java release schedule is changing to a pattern of intermittent enhancements similar to other large projects that favor version releases. Not all the version releases will include long-term support. Don’t expect to see IBM i support for the version releases.
Will this rock the world of IBM i Java programmers? Gorzinski doesn’t think it will. Moving Java solutions to another language is an option, but this unlikely to motivate developers or businesses to move to another technology.
“Java remains a very solid language with a promising future, especially now with all the extra investment in open sourcing the technology from IBM and other companies.” he says. “Look at what enterprise applications need: performance, reliability, and a good support roadmap. We’ve seen that with Java and will continue to see that with Java.”
For IBM i shops with a Java point of view, there’s more than release schedules and support to think about. With new releases comes the potential for application changes. That’s always a consideration, but Gorzinski says the changes in Java 9 could be significant for some depending on the nature of the application.
“For the most part, if you had a Java 5 application it would work on Java 6 and Java 7 and so on. This is a little different than previous Java version upgrades,” he says. “For instance, if you are writing Java code that drives a Web technology, I expect a lot of the changes will impact the application server rather than the application code.”
Foremost among factors affecting change is the move toward a modular system that replaces the traditional .jar files and class settings familiar to Java development.
The purpose of a module system is to simplify the construction, maintenance, and distribution of large applications and provide developers with an escape from the “JAR hell” of error-prone class-path development. It also allows configurations which scale from large servers down to small embedded devices.
Eventually class tabs will be replaced with module tabs. Gorzinski advices Java developers to start learning this new technology. The core concepts of building simple Java application are changing. Class tab-based applications will continue to work for a while, but at some point, the tab-based apps will no longer function.
“The modularity is being pushed down into the runtime and distribution of the code itself. Previously modularity was accomplished through middleware layers. The OSGI architecture provided modularity for web applications. Now even simple, small applications are being packaged differently,” he says. “Java 9 may ‘break’ existing applications, requiring a significant refactor to conform to the new model.”
For its part, IBM has been sharing its Java technology with the open source community and the OpenJDK project since 2010. It’s J9 line of Java technology, which has been shipping with IBM i since V5R4, was recently open sourced along with the IBM Java Virtual Machine (JVM). Nearly all the IBM i Java community runs J9.
The OpenJDK project has benefited from a variety of contributors. Oracle, for instance, has committed to continue code contributions and make OpenJDK builds available. For more on OpenJDK and the changes designed to make it more reliable and maintainable, see this link which leads to documents, presentations and other resources.
Although it’s difficult to take a census, the IBM i Java community seems to be holding steady. Java remains one of the preferred languages, ranking well behind RPG but ahead of .NET, PHP, C++ and COBOL. There are numerous Java-based solutions available on the platform and new solutions continue to be introduced. Its reputation as a resource hog has pretty much disappeared, although some critics will point to the noticeable overhead of starting up a Java Virtual Machine.
Gorzinski, who began his IBM career working on the J9 project in 2006, believes the negative perceptions of Java have largely faded.
“Most people have very acceptable performance with Java enterprise applications – plus you factor in the tune-ability, debuggability and available cross-platform analysis tools for things like memory usage and garbage collection cycles – and over time people have learned the technology enough to understand the myths and work their way around them,” he says.
Java on IBM i is mostly understood as runnning in enterprise environments (e. g. under WebSphere application server). But there is also another area where Java can be exploited for IBM i.
IBM i Toolbox for Java or its open version JTOpen is very capable framework, that enables creating applications running in the PC (platform independent) and communicating with IBM i. A programmer knowledgeable in Java GUI programming can create nice applications.
I think that namely the Access Client Solutions package is being programmed just in that framework.
Another example is in http://www.github.com/vzupka.
What in the world is a “tab-based app”? All I can find on Google tells it it may be something about converting tabs to spaces or using different tabs in the Eclipse deployment dialog but nothing makes sense in regards to there being a tabs feature in Java 9.
FYI, I think the migration to microservices solved the classpath hell problem for anyone that cared to take advantage of it. In retrospect, the few times I encountered classpath hell were caused by the monolithic deployment of unrelated assets. Had we thought to separate the functions into separately deployable services, the problem would have disappeared.
IBM delayed Power9 on IBM i by a year and now they omitted support for Java 9.
Java 9 is not a long term release or a feature release. It is a performance release. We’re supposed to believe that performance enhancements are unimportant on IBM i? They certainly are unimportant to IBM.