Java On IBM i 7.1 Brings JVM Migrations

April 21, 2014 Dan Burger

As the announcement of IBM i 7.2 dawns, the introduction of IBM i 7.1 has its four-year anniversary. Although IBM guards its estimates of companies that have moved to 7.1, it is an optimistic guess that half of the IBM i installed base has made that move. How many of the 7.1 shops are housing Javaheads is also unspoken. But 7.1 was a milestone for Java developers because the Classic Java Virtual Machine was no longer supported.

That was not a big deal then. But time flies and here we are four years down the road. Java shops have moved forward. But as we know, old habits die hard in legacy shops. It really doesn’t matter if those shops favor RPG, Java, or any other language that is older than a Little Leaguer. But in IBM i shops specifically, it shows that Java developers are not that much different from RPG developers.

The reason I say that is because Java developers–with careers chiseled out on the IBM midrange platforms that predated IBM i–liked their Classic JVM tools and environments. And even though a replacement JVM, the J9, was introduced in 2005, Java developers stayed with what they knew best. Time is catching up with them now.

Yes, the Classic JVM remains popular after all these years, but the migration to J9 has picked up. You had to figure it would.

Jesse Gorzinski is a software engineer for IBM. He has worked for Big Blue since 2006 and has contributed to several key IBM i deliverables, including the J9 Java virtual machine. I noticed him while keeping an eye on local user group activities. He was the guest speaker at the Gateway400 user group in St. Louis earlier this month. He is also on the speakers’ list at the COMMON Annual Meeting and Exposition coming up in a few weeks in Orlando, Florida, and for the OCEAN Tech Conference in Orange County, California, in July.

He was on the development team that brought J9 to IBM i and he helped companies migrate from the old Classic Java Virtual Machine to J9.

“Migrations have to deal with integration pieces. There are kinks that need to be worked out and usability issues. But now, in 2014, if you want to migrate from the Classic JVM to J9, it is very easy. It is almost always a smooth transition,” Gorzinski says.

Meanwhile I’m thinking, “What else is he going to tell me? The words ‘seamless transition’ leap from the mouths of product evangelists. All migrations become easier as lessons are learned and best practices become road maps.”

So for those who are not completely soothed by seamless transition talk, Gorzinski provided some insights into a few of the places where he has seen companies stub their toes on the migration pathway.

Let’s begin with application developers are sometimes prevented from working on the latest JVM. That occurs when the application they are working with has API requirements on an older JDK where portions of the class library were phased out over time. Getting around that roadblock is an issue of testing, support statements, and build requirements. It will work, Gorzinski says, as long as there are not API dependencies.

There can also be incompatibility issues with the JDKs and APIs. Gorzinski has seen code written to specific behaviors from the class libraries in Classic JVMs and those behaviors changed when they moved to J9. That will take some remediation because the behaviors were not written to be driven by the spec.

Another potential trip wire is commonly experienced by customers who try to migrate to a 32-bit machine only to later discover it is not sufficient. Because of the way memory allocation works in a 32-bit environment, they run out of memory. It’s not the Java heap memory, but what most people refer to as native memory. The typical result is unexpected crashes.

“When you talk about a timeline that takes into account compatibility, skills, and the tools a developer needs, there are three conversations you can have,” the software engineer says. “One is about the APIs and, in my opinion, that is what the stumbling block is for moving forward. The second conversation is the language itself. Java is backward compatible with older versions. It hasn’t been changed for the most part; they just keep adding new stuff. The third point is the VM itself. It is partially a vendor specific comment, but when you move up you want to have the skills to make the most of the move.”

As you would expect, there are tools with J9 that did not exist with the Classic JVM. However, J9 also includes a lot of the old familiar tools that developers used for years. So which tools do you suppose are most popular? Right, the familiar tools. This makes the transition easier, but not understanding the efficiencies of the newer generation of tools, Gorzinski says, prevents J9 from functioning to its capabilities.

Is it just me or does this sound like RPG developers who can’t break the old tools habit and, therefore, resist the move to Rational Developer for i?

“Most customers are not using a really powerful setup tool called IBM Support Assistant (ISA),” Gorzinski says. “It’s a delivery mechanism for a lot of sophisticated IBM Java tools. These are not IBM i-specific tools. They are cross-platform tools with capabilities such as problem determination and performance analysis.”

One topic that can’t be left untouched in a discussion about Java apps on IBM i is less than satisfactory application performance. I’ve heard it from dozens of sources. None of them work for IBM. I’ve also heard Java runs much better on Power7 architecture and IBM i 7.1 operating system than any of the earlier systems and far better than when Java on OS/400 got a black eye.

Much of the credit for improved Java performance on IBM i goes to the muscle provided by the Power Systems iron. Gorzinski says there’s a lot more to it than that. He points to the just in time (JIT) compiler that optimizes the code for the hardware and allows the system to take advantage of the processing power. The compiler was enhanced in J9 when Java 7 was introduced in mid-2011, and that provided a noticeable performance boost. As the Power7 boxes moved to Power7+, the compiler was enhanced to incorporate the hardware advances.

IBM last recorded SPEC numbers with J9 on IBM i in 2010. They can still be found here.

More current SPEC numbers–from 2010–with WebSphere 8.5 running on J9 on Linux can be found here. Those numbers were recorded using Java 7 and can be compared to these numbers using Java 6 and WebSphere 8.

Making an inference that IBM dropped SPEC benchmarks on IBM i in favor of benchmarks on Linux is a signal that more Java/WebSphere customers would go that direction draws a debate from Gorzinski.

“Just because unfortunately we don’t have IBM i SPEC numbers published does not indicate negative performance or that i isn’t a viable solution for those workloads,” he says while staking a claim that Java and WebSphere both run very well on IBM i.

“The switch from the Classic JVM to J9 brought forth a huge benefit to the IBM i platform,” he contends. “Many users who made the switch reported visible and notable performance gains without the need for benchmarks. If there were performance complaints, they may have been from users not exploiting the J9 technology. Plenty of customers are very happy to run their large Java workloads with J9 on IBM i.”

Typically, the migration to J9 from the Classic JVM comes with an operating system upgrade to IBM i 7.1.

Correction: The original text of this article incorrectly noted the just in time compiler was introduced in J9 with the introduction of Java 7. It has been corrected to say that compiler was enhanced with the introduction of Java 7. The article also incorrectly noted the last time IBM recorded SPEC numbers with J9 on IBM i was almost ten years ago. It was actually in 2010.