Java in 2020, Part 2: Anne Thomas on Java Subscription, Jakarta and MicroProfile

Talking with Gartner VP and distinguished analyst Anne Thomas about Java at the start of a new year is becoming a habit. (Let's call it a tradition.) Thomas is a longtime industry watcher with deep industry knowledge, she understands the tech and she doesn't mind stirring the pot, so to speak, if that's what her observations demand.  

We started with Oracle's Java SE subscription service, which Big Red launched in June 2018. As virtually all Java users know, starting in January 2019, public updates for Java SE 8 were no longer available for business, commercial or production use without a commercial license. I heard mostly upbeat reports when I asked about how Oracle's customers were adapting to the new model in earlier what's-next-in-2020 interviews. The reactions Thomas tracked last year were mixed.

"For the companies that purchased the commercial versions of Java -- Java SE Advanced and Java SE Suite -- it gave them a nice reduction in cost," she said. "But the vast majority of organizations did not purchase those commercial licenses, and they've been using Java for free for the last decade-and-a-half. Those folks all of a sudden have these bills -- sometimes enormous bills… sometimes in the millions -- that they didn't have before."

When Oracle unveiled its Java SE subscription service, it was positioned as a complement to Oracle's existing free releases and OpenJDK ecosystem. It would "remove enterprise boardroom concerns around mission critical, timely, software performance, stability and security updates," the company said at the time. The advanced groundwork notwithstanding, most organizations were simply not prepared for it, Thomas said.

"It hit their budgets pretty hard," she said. "I've taken about 250 calls on this topic in the last year. Paying Oracle for a commercial license is clearly the easiest way to deal with this situation, and you might find the support agreements in the apps you're using actually stipulate that you use Oracle Java. But for some organizations, an alternate distribution, such as AdoptOpenJDK, Amazon, Azul, IBM or Red Hat, is pretty much their only option. The good news is, they have those options."

Another reason the pay-Oracle option might be worth the expense, even with so many alternative distributions to choose from: Third-party distros can be challenging.

"It's a huge amount of work to identify which programs are using Java, which versions they're using, and then test and verify that all those applications will run on an alternative distribution," Thomas said. "And OpenJDK does not include support for the Java plug-in, which you need if you're running applets or Java Web Start. There's an open source project called IcedTea-Web that supposedly supports it, but I've heard conflicting reports from people about their success."

Some vendors have licensed Java from Oracle and taken on the cost. Thomas cited Adobe as an example. Other vendors, such as Atlassian, have moved to support alternatives, such as AdoptOpenJDK, in their offerings.

But the core issue for organizations struggling with all this change is that the vast majority of Java applications -- certainly more than 80 percent -- still have a dependency on Java 8 or earlier, Thomas said.

"If you want free Java from Oracle with updates on the new six-month cadence, you have to upgrade to the latest version," she said. "At this point, you need to be on Java 13. But hundreds -- probably thousands -- of vendors have Java 8 dependencies, and you have all these third-party applications you run within your organization that don't run on Java 13."

Oracle says it will end regular support for Java 8 in 2022 and cease extended support in 2025.

Why are so many sticking with Java 8? "At some point, organizations are going to have to think about moving off Java 8," Thomas said, "but so far, none of the features in Java 8, 9, 10, 11, 12 or 13 have been compelling enough to get them moving. But my advice if you're building new Java applications: They should not be based on Java 8, but Java 11."

Thomas speculated that the subscription model could influence decisions in the enterprise about future commitments to Java.

"Java is a really nice, mature programming language," she said, "and it continues to be enormously popular for good reason. But Oracle's licensing is an issue for many of the organizations I talk to. Some of them are definitely reconsidering their Java commitments."

Thomas saw the writing on the wall for Java EE, now Eclipse Jakarta EE, at least a year before that startling standards-body hand-off. During a 2017 interview with ADTmag, she described Java EE as "overgrown and not right for cloud-native app development." And she advised those responsible for modernizing an enterprise's application infrastructure to "develop a strategy to deal with the obsolescence of Java EE and other three-tier application frameworks." She doesn't have higher hopes for Jakarta EE, even under the more involved stewardship of the Eclipse Foundation.

The Foundation released the Jakarta EE 8 specification last August with the primary goal of providing a version that is 100 percent compatible with Java EE 8. The plan for Jakarta 9, which was just announced, is to deliver a set of specifications that are functionally similar to Jakarta EE 8, but in the new jakarta.* namespace.

"It took three years to deal with the namespace issue," Thomas said. "Eclipse needed to do it, but they're now at parity with where we were five years ago."

"You should be building your back end as a set of restful services," she added, "and your front end using your favorite JavaScript framework. And the front end should be talking to the back end using APIs, because you want that back end to support your mobile clients, your voice clients, your immersive clients, your kiosks, your watches and things we haven't thought of yet. You need to be designing your applications to be multi-experience, and 90 percent of what is in Java EE right now is focused on providing server-side generation of HTML. The applications you build today should be microservices or miniservices with deployment in your favorite platform-as-a-service-type environment or Kubernetes-type environment. And you should be using the MicroProfile, not Jakarta."

Thomas pointed to a lack of innovation in such Java EE-based offerings as WebSphere, WebLogic and JBoss. "That's old technology and not where you should be targeting your applications anymore," she said.

Thomas does have high hopes for Quarkus, the Kubernetes-native Java framework Red Hat released last year, which is now compatible with the latest version of the Eclipse MicroProfile.

"MicroProfile is where it's at," she said.

Posted by John K. Waters on January 28, 2020