Q&A: Eclipse Foundation's Milinkovich on the Road to Jakarta EE 8

The Eclipse Foundation today announced the released the first Jakarta EE specification, almost exactly two years after Oracle declared its intention to transfer the responsibility for enterprise Java to that open source standards organization.

Two years seems like a long time, but the Foundation's executive director, Mike Milinkovich, says that's just how long it took to get the specs right. I talked with Milinkovich last week about the road to the Eclipse Jakarta EE 8 release.

I've been calling the Foundation's adoption of enterprise Java and the development of a standards process for it "the road to Jakarta EE 8." I'm just assuming it was a bumpy one, but how was it really?
When we started down this road, we always said that our first order of business would be to ship a set of specs that were exactly the same as Java EE 8, so we had that baseline. When we first started saying that, it just seemed like a good, solid, conservative thing to do to make sure that we got it done. It turns out that we were really darned lucky we did it that way. It would have been borderline crazy to do anything else.

How do you mean?
The first time you run through a very large and complex process you inevitably run into unforeseen circumstances. In this release cycle, we took exactly the same specs and ran them through a new process, but we changed a few things -- the TCKs are now open source, the specifications are under a new license, there's no more reference implementation, there are multiple compatible implementations -- but those are all process changes. We're not delivering new technology to developers yet. But every one of those process changes, introduced somewhere along the way, had its own little bit of complexity that you just couldn't foresee.

Seems like it was a ton of work.
We rewrote our IP policy -- twice -- we developed a spec process from scratch, and we updated all of our contribution agreements and got tens of thousands of people to resign them. So, yeah, you could say that.

And, as you've often said, you weren't doing this alone.
I can't stress enough how many good people pitched in and worked hard to make this possible. Oracle, Red Hat, IBM, Tomitribe, Payara, Fujitsu, to name a few. It was a community effort to get this thing out the door.

There are a lot of people with skin in this game.
Well, Java is old technology -- more than 20 years old -- but it's a multi-billion-dollar ecosystem, and there are millions of developers who have skills with this platform. Basically, everything we're doing right now is about establishing a baseline that's going to allow us to re-invigorate this platform for the next 20 years.

Why is re-invigorating the enterprise Java platform so important?
Enterprises want to see that there's a way to modernize their applications, in many cases, to take what they have now inside the corporate firewall to the cloud. They want to leverage this new infrastructure model with existing applications that are known to solve their business problems. Also, enterprises have thousands of developers with skills on this platform -- people who understand the businesses they work for. We need to demonstrate to those people that the technology platform they have skills in is still relevant and will keep them gainfully employed for the next 20 years. And then there's the need to attract young talent to a platform by making it exciting again.

So, all the work you've done on this release is essentially about setting the stage, so to speak, for innovations to come?
We had to get this part right. Large companies are making big bets on their product plans and this technology, so we focused on doing something concrete that would reassure the market and the community.

And no small part of your challenge was the fact that the Eclipse Foundation was not a specification organization when you accepted the stewardship of enterprise Java.
That's right! We were creating a brand-new specification process from a blank piece of paper, rewriting our IP policy to handle patents correctly, which is very different from how you do things in open source. Luckily, we were doing all this with smart engineers, experienced standards people, and lots of opinionated lawyers from software companies around the world.

Talk about "Incremental versus Big Bang."
What we ended up with in our negotiations with Oracle, remember, is that every time we add a new API, or we make a change to an existing API, that has to happen in the Jakarta namespace. The javax package names cannot be evolved by the Jakarta EE community. So, do we switch everything from javax.* to jakarta.* all at once -- that's the Big Bang -- or do we make the change a little bit at a time, as needed -- in other words, incrementally? In other words, do we rip the band aid off, or do we deal with these compatibility issues with every single release for the next 20 years?

Sound like you favor the Big Bang.
That's my personal preference. Let's just get it over with. But there are valid arguments for an incremental approach. Ultimately, this is about what's best for the customers, what's best for the ecosystem. The vendors have varying opinions on this, based on what they think their customers perspective would be. But what a lot of it really boils down to is, to what degree can we offer a reasonable set of technical solutions to the backwards compatibility problem? This is a really big decision that has to be made over the next couple of months.

The decision to move enterprise Java to the Foundation elicited a largely positively reaction from the community. Did you get any significant pushback?
Java developers are not shy, and they always let us know what they think. But they were onboard for this.

Were you surprised at how long it took to get here?
I was a little bit. I'm an optimist by nature, and I had a very clear idea from the beginning of where I wanted this end up. And we got very close to what I hoped for. But it takes a long time to pull a thing like this together. I remember someone saying, "There's no way you're going to get this done in less than a year." And they were right, of course. You can't change legal documents willy-nilly, and you have to take the time to explain to the community -- thousands of people around the world -- what the changes are and why we're making them. But I believe it was time well spent.

Posted by John K. Waters on September 10, 2019