Q&A: Mike Milinkovich on Java in 2018 and 2019

2018 was a year of big changes for the Java community, among which none were bigger than the transition of the stewardship of enterprise Java from Oracle and the Java Community Process (JCP) to the Eclipse Foundation. But that Herculean task wasn't the only Java-related challenge faced by that organization last year. I talked with Mike Milinkovich, who has served as executive director of the foundation for all its 14+ years, about these and other changes, and what he sees coming for the Java community in 2019.

It would be hard to overstate the importance of moving enterprise Java, which is now Jakarta EE under the Eclipse Foundation's stewardship. Was it the greatest challenge you faced last year?
Oh, without a doubt. This has been an enormous undertaking, and the teams here have been working very hard, as have all the developers involved. I also want to give a shout-out to the Oracle development teams we have been working with. They have been fantastic. There has been participation by the other vendors, of course, but Oracle gets the credit for the heavy lifting, of getting Glassfish and the TCKs migrated to the Eclipse Foundation.

Accepting the stewardship of enterprise Java has also required some fundamental changes for the Foundation itself, hasn't it?
You could say that. We have created an entirely new specification process for Jakarta, which has been an enormous amount of work. Remember, the Eclipse Foundation didn't do specifications before we started this; we've essentially created a specification process from a blank sheet of paper.

Obviously, there are some parts in there that were inspired by the JCP, but there were a lot of things we knew we wanted to change. And there's also the fact that this is a vendor-neutral organization, rather than single-vendor organization, which is a big change, as well.

What do you see as the long-term impact of and Eclipse stewardship of enterprise Java?
It's important to keep in mind that the Eclipse Foundation is an open community process that doesn't have a single vendor in charge of it, which means there's an opportunity here for enterprises. Historically, they have bought black-box products from vendors, and the idea that they can engage with and help to shape the technologies they're running their businesses on through their direct contribution and involvement is still new to many. But they're starting to get it, and we're hoping that Jakarta EE will lead to them to get more engaged going forward.

Of course, enterprises are still going to want vendors, but by participating directly in the Jakarta EE specification process, they can help to shape what becomes the products they get from their vendors.

I'm a little confused about the status of Jakarta under Eclipse. Is it "Eclipse Jakarta" or "Jakarta EE?" And what's the difference?
It's Jakarta EE, under the stewardship of the Eclipse Foundation. But as a brand, it is a peer of Eclipse. Eclipse projects are supposed to call themselves "Eclipse" something: Eclipse Glassfish Eclipse Vert.x, Eclipse Jetty, etc., because they are subordinate brands. But when it comes to the specifications that are coming out of Jakarta EE, they're the "Jakarta" specs.

Did you ever consider not accepting the stewardship of enterprise Java?
We definitely wanted Java EE to come to the Eclipse Foundation. Yes, this has been a ton of work, but the Eclipse Foundation has deep roots in the Java community, and with enterprises. We felt this was a natural fit, and great opportunity for us. Among other things, I think Jakarta EE was the trigger to make a lot of developers finally recognize that the Eclipse Foundation has projects other than our Java IDE.

Our goal is to help drive a whole new generation of innovation in the Java ecosystem. It's going to be a lot of fun!

Any other accomplishments around Jakarta you'd like to mention?
We were able to onboard all of Glassfish last year, which has a huge, very mature code base. And we open-sourced the Java EE TCKs [Technology Compatibility Kits], which was an enormous change for the Java EE ecosystem. Historically, the TCKs have been confidential and proprietary. People could not get access to them, which means they had no chance of finding out exactly what was being tested. All of this is now open source. And we are actually running these TCKs on Eclipse Foundation hardware, and doing testing for Glassfish using them, and moving all that forward.

The fact that the TCKs are now open source and have become an integral part of migrating this code base forward -- that ability to do this open, public testing all the time is really going to help us innovate. And the community now has the ability to inspect tests and give feedback, and to give us more, better tests, which means we can expand the test coverage over time.

If Jakarta EE represents the biggest change for the Java community and challenge for the Foundation last year, was there a close second?
Nothing comes close, really, but we did make some pretty big changes to adapt to the new rapid release cadence for Java, which Oracle began implementing last year. We think it's a good thing, and we support it, but it did cause us to shift from our annual release train model, where we shipped a major release every June with a couple of maintenance releases though the year, to a rolling release model, where we ship the Eclipse Java IDE every quarter.

So, no more release train after last June's Oxygen?
That was the last one. We've been doing this release train for a dozen years, and I think it provided a good example of the advantages of regular, predictable releases, which I don't think they were lost on Oracle.

Will you be lining up your releases with Oracle's releases?
When Oracle did that, they upped the game for us, but we don't want to line up our releases exactly with Oracle's, but we do want to make sure we're always current. The approach that we came up with is to ship a couple of weeks after Oracle's releases. As they demonstrate over time that they're going to be able to do this on a regular and predictable basis, that'll only help us.

Any other accomplishments in 2018 you'd like to mention?
I wouldn't call it an accomplishment, but it's very exciting that Oracle joined the Eclipse MicroProfile effort, and their Helidon project is shipping MicroProfile and MicroProfile-compatible implementations.

Helidon is the open-source Java microservices framework designed to run on a fast Netty core. It supports MicroProfile 1.1. Why is that exciting?
MicroProfile is a set of specifications for doing Java microservices, and that community has done a great job in really bringing forward a lot of new specifications and doing it quickly. We're now seeing real multivendor engagement around MicroProfile, and we're seeing lots of people showing up in conferences in talks about it, so there's clearly a lot of interest out there around this technology. MicroProfile is setting us up for having more success for Java in the microservices area. The migration of critical Java applications into the cloud is only going to accelerate, and we think MicroProfile could be a big part of that.

Anything that didn't go as planned in 2018?
Everything took longer than we thought it would, which I guess shouldn't surprise anyone. And I'm a bit disappointed that we didn't get to where we wanted to be with Jakarta at this point. In particular, we're about three months late shipping the first release of Eclipse Glassfish.

The other thing is, we're still not quite where we want to be in terms of being able to evolve the specifications going forward. We still have some work to do with Oracle to make sure we have all the rights in place. It's just taken longer with the lawyers than we ever anticipated. I know your readers will be shocked to learn that the lawyers are taking a long time.

Although we've done a lot of work with Jakarta, what developers want to see from us is innovation, and we're not quite there yet. We've done yeoman's work in migrating Glassfish and the TCKs and the API jar files and all those bits and pieces to the Eclipse Foundation, and we have functioning open source projects that are doing nightly builds, and all that great stuff, but we're still not quite at the spot where we can start moving forward and have a new release of the spec. And that's the whole promise of Jakarta, and that's what we must focus on.

You're not there, but you're getting there?
Right.

Looking forward to 2019, what's on your Java radar?
AI and machine learning. One of the challenges for Java in the AI/ML space is the perception that, if you're doing AI or ML, you're doing it in Python. The major frameworks out there, like Tensor Flow and PyTorch, are written in Python, so there's this perception that Python is the technology of choice for AI/ML. The Eclipse Deeplearning4J Project, which is mostly implemented in Scala, is a deep learning framework that runs on the JVM. Among its many capabilities: you can take a machine learning model that has been taught using something like Tensor Flow, and run it on your JVM-based infrastructure. And that makes machine learning a lot more approachable for enterprises.

Most infrastructure people are more familiar with a JVM-based approach, so having a solid Java -- or at least a JVM -- story is going to help adoption of machine learning in the enterprise. Eclipse Deeplearning4J is providing a real opportunity for the Java ecosystem to start tying in to ML.

I also expect to see Java becoming even more relevant than it already is in the microservices and cloud-native space. We did a survey last year, and we had very large numbers of developers saying they already were now or were planning to soon run their applications in the cloud. About 30 percent said within the next two years they expect to be running 60 percent of their Java apps in the cloud. Nearly half said they're already using Java to build microservices. 21 percent said they'd be doing that in a year. So, there's a lot of activity already happening around Java and microservices, and we think that's only going to accelerate.

There's a lot of work that needs to go into making that better -- better stories around Kubernetes and Docker containers in particular. Kubernetes and Docker is where all the cool kids are hanging out, but there are enormous investments in enterprise code bases that have been built in Java and Java EE. Enterprises want to figure out a way to migrate as much of those code bases and they can into this cloud-native world.

Just as important, they have a lot of developers with Java skills and knowledge about their businesses. They want to make sure that those skills are still applicable as they're migrating to the cloud.

People should keep in mind that Java is still one of the most popular programming languages out there. Reports of Java's demise make great click bate, but they are grossly exaggerated.

Part of our mission, as we see it, is protecting the that franchise. Java developers are passionate about the Java platform, but they also need to believe that that platform is evolving to meet the requirements of the businesses they work for, and that the applications they're building are going to be relevant in the future. They want to see that great multivendor ecosystem that has made Java EE so successful, they want to see those vendors lining up behind Jakarta EE and Eclipse MicroProfile and pushing these technologies forward so that they can get excited about being a Java developer for the next 20 years.

Posted by John K. Waters on January 14, 2019