Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Podcasts Mike Milinkovich, Director of the Eclipse Foundation, Discusses the Journey to Jakarta EE 8

Mike Milinkovich, Director of the Eclipse Foundation, Discusses the Journey to Jakarta EE 8

Today on the podcast, Wes talks with Mike Milinkovich. Mike is the executive director for the Eclipse Foundation. The Eclipse Foundation was chosen to govern the evolution of Oracle’s Java EE to Jakarta EE. The two discuss the project, the recent news about issues with the javax namespace, the challenges around bundling a Java Runtime with Eclipse, and the path forward for Jakarta EE 9 and beyond.

Key Takeaways

  • Java EE, unlikely Java SE, has always been a multi-vendor ecosystem. It made sense for everyone for Oracle to invite their partners to be involved in the governance of the specification for Java EE for it to continue moving forward. This is the reason for moving Java EE into the Eclipse Foundation as Jakarta EE.
  • The current plan is for the Eclipse Foundation to get a copyright license to evolve the text of the specification and not a license to the trademarks of Java EE itself.
  • The javax namespace must remain as is. For it to be evolved, a different namespace must be used.
  • The javax namespace is a trademark of Oracle. Because of this, there are quality controls that Oracle required for its evolution. Ultimately because of those controls, the Eclipse Foundation felt it was better to branch javax into a different namespace and evolve it separately solely under Jakarta EE governance.
  • Jakarta EE 8 is targeted to be released around Oracle Code ONE. Jakarta EE 8 will be exactly the same as Java EE 8. * The only difference is it will be licensed from Jakarta, not Oracle and only requires membership in the Working Group.
  • Beyond EE 8, the release cycle, the plan for moving the javax namespace (and keeping compatibility with both the old javax namespace and the new namespace), and new specifications for inclusion into Jakarta EE are still active areas of discussion.
  • Unrelated to the discussion of Jakarta EE (but discussed in the same board meeting), an attempt to bundle OpenJ9 with the Eclipse IDE failed because of licensing restrictions around a certified Java Runtime. OpenJ9 is certified when acquired through an IBM channel, but not when downloaded directly for us.

Show Notes

What has happened since you stood on stage in 2017 announcing the move of JavaEE to Eclipse foundation?

  • 01:45 There’s two parts of the story – the first, what happened before the announcement on the stage, and the second is what’s happened since.
  • 01:55 Part of the reason why the move happened in the first place is that JavaEE has always been a multi-vendor ecosystem.
  • 02:00 WebSphere, and JBoss are just a big a name as WebLogic for example.
  • 02:05 There’s always been multiple implementations, and it’s always been a pretty vibrant ecosystem in terms of products making pretty big bucks in this space.
  • 02:15 Oracle realised with the move to cloud and the other things in their organisation, that inviting their partners to participate in the future direction was better for them.
  • 02:35 Since the move was announced, a lot of really good things have happened.
  • 02:40 GlassFish is now Eclipse GlassFish – millions of lines of code have been moved over.
  • 02:50 Another piece of big news is that Oracle, for the first time in its history, open-sourced the JavaEE Testing Compatibility Kit (TCK).
  • 03:00 GlassFish has been open-sourced for a while, but the TCKs were never open-sourced until they were transferred over to the Eclipse Foundation.
  • 03:10 A lot of good engineering work has happened in order to move them over to the Eclipse Foundation.
  • 03:20 In parallel with doing that, over about a year, negotiations happened between Oracle and the Eclipse Foundation about the legal issues over moving the specifications developed under the JCP to the Eclipse Foundation.
  • 03:45 One of the aspects of trademark law is that when you license a trademark, it’s completely normal to have quality requirements to go with that trademark license.
  • 03:50 If you’re going to license Kleenex, it’s got to be “this” good.
  • 04:05 When we got into the details of what that would mean for JavaEE, it got very complicated, and we got into a corner where we couldn’t find an agreement that worked for both of us.
  • 04:15 Then we tried Plan B, which is when we don’t get a license for the trademarks, but just get the copyright license for the specifications.
  • 04:30 That’s where we are today.

There was also a good 18 months where there wasn’t much movement, right?

  • 04:40 One of those things where there was no visible movement, but there was a lot of internal discussions on what was going to happen.
  • 04:50 There was also getting those companies up on stage in 2017 – there was a lot of planning about making that happen as well.

So with the specs, you can make your own implementations, right?

  • 05:10 It’s not about the implementations - it’s about the specs themselves.
  • 05:15 We have to go out to IBM and RedHat and SAP and Pivotal that have contributed over the years to license their contributions.
  • 05:25 It’s a license to evolve the text of those specifications over time.
  • 05:30 The goal is that Servlet needs to live and breathe, we need a license to be able to do that.

What kind of license?

  • 05:40 It’s a copyright license - it says that you have the right to copy, distributed, sub-license, create derivatives works - all of those appears in this document.

JavaEE is Servlets, JSF, EL, JaxRS, XML, DI, JPA, JMS …

  • 06:15 One of the key points is that it’s easy to say “I don’t use JavaEE any more” – however, these specifications are fundamental to many cloud infrastructure and applications.
  • 06:45 It’s trite to say JavaEE is dead – the APIs are still very much used, and there are also going to be legacy applications running in JavaEE servers for 20 years.
  • 07:10 It might not be your first choice for building a new application, but if you like getting paid, or your bank not loosing your money, you’re probably using JavaEE every day.
  • 07:40 Our goal is to take all of these specs and adding additional specs.
  • 07:50 There are millions of developers that know Java, thousands of corporations that have deep Java skills in their organisations.
  • 08:00 We want to leverage those skills and institutional knowledge in those corporations to create the right platform for the next generation of applications written in Java.
  • 08:10 This is about the future of the platform, not the past.

What was being asked that couldn’t be met for reusing the javax namespace?

  • 08:30 Fundamentally the issue was that Oracle considers the javax namespace to be a trademark of Oracle.
  • 08:35 They wanted elements of control over the evolution of things inside the javax namespace that we did not want to give up.
  • 08:55 The Eclipse Foundation is a not-for-profit 501(c)6 organisation, so we have legal requirements to be vendor neutral, and to act in the best interests industry of the industry, and in particular not for any one vendor or technology.
  • 09:10 There were some things that despite good intentions on both sides, we could not come to an agreement on.

What does it actually mean?

  • 09:30 We can actually use the javax namespace, we just can’t change it.
  • 09:35 There are some additional requirements; for as long as we are using the javax namespace, there are conditions that it can only use a certified JavaSE runtime.
  • 09:40 This is a good segue into how we see this evolving in the future.
  • 09:45 The first thing we need to do is to create a Jakarta-branded specification that replaces JavaEE 8.
  • 09:55 JakartaEE 8 is going to be exactly the same as JavaEE 8, including the javax namespace.
  • 10:10 The first release of the specifications that come from the JakartaEE namespace are going to be exactly the same as JavaEE.
  • 10:15 If you’re a developer and listening to this, you might be wondering why bother if you’re doing the same thing?
  • 10:25 The answer is that the IP rules are completely different under Jakarta than under Java.
  • 10:30 Under the JavaEE process, if you want to put the coffee cup logo on your project, you have to sign a license with Oracle.
  • 10:40 Typically those JavaEE licenses are in the millions of dollars per year.
  • 10:55 Under the Jakarta case, the requirement is that you have to be a member of the JakartaEE working group.
  • 11:00 The TCK and specification licenses are far more liberal than the licenses that were provided under the JCP.
  • 11:10 From a technical point of view, it’s exactly the same – but from a legal and business perspective, there are huge advantages for JakartaEE 8 to exist for the sake of the ecosystem.
  • 11:25 What I predict will happen is that the JakartaEE 8 platform is going to be used by many companies for many years, like a long term support.
  • 11:35 We’re seeing the same thing in the JavaSE world, where many companies are sticking with JavaSE 8, which is the one before the module system was put in.
  • 11:45 It’s what they know, it’s the Java they know, so they are planning on running on JavaSE 8 for many years – I think it’s possible that the same thing will happen for JakartaEE 8.
  • 11:55 One of the good things is that all of the companies involved are economically motivated to switch to this new brand the day that it’s available.
  • 12:10 I think you’re going to see a very rapid switch of the whole ecosystem over to the JakartaEE branding.

The other problem was that the Eclipse IDE be running on a JVM certified by Oracle rather than other runtimes?

  • 13:00 We are a vendor-neutral open-source foundation.
  • 13:05 Our goal is that the only restrictions we want to apply to our projects is those that arise from OSI-approved open-source licenses.
  • 13:15 Obviously the GPL has a different set of constraints than the BSD license.
  • 13:20 Strictly speaking this is unrelated since we’re talking about Jakarta, since we’re talking about the Eclipse IDE, but it was in the same board meeting so it appeared in the same minutes.
  • 13:30 Oracle wanted to insist that if we shipped a Java runtime from Eclipse that it had to be from Oracle or one of its licensees.
  • 13:40 Obviously we had problems with that and couldn’t agree to it.

Why were Jakarta EE and Eclipse IDE mentioned together?

  • 13:50 They weren’t – it just so happened that these two topics both appeared in the same board meeting.
  • 13:55 They got conflated in people’s minds, but if you read the meeting minutes, they were separate conversations.

So why was Oracle in a position to say that they wanted the Eclipse IDE to run with an Oracle JDK?

  • 14:10 The first thing to understand is that the Eclipse IDE has been around for 18 years, and it’s never shipped with a runtime.
  • 14:25 So we had an idea to make it easier for our users and adopters to be able to ship a Java runtime with the IDE.
  • 14:35 Originally they were suggesting a runtime based on Eclipse OpenJ9, which is the open-source project at Eclipse that builds a Java virtual machine.
  • 14:45 IBM certify and use that JVM for their products, but it’s not certified if you just download it and use it from Eclipse.
  • 14:55 That dilemma was what caught Oracle’s attention, and they said if you want to call it Java then it has to be certified.
  • 15:10 It’s not preventing us from doing anything that we’ve been doing for many years.
  • 15:15 It is preventing us from doing something that we thing would make the lives of our Eclipse IDE users easier.
  • 15:25 We have a lot of IDE users that use Eclipse for C++ or for PHP, and those folks don’t necessarily have a JRE installed on their laptop - those were the kind of users we were targeting.

When are we going to see JakartaEE 8?

  • 15:50 JakartaEE 8 is going to be exactly the same as JavaEE 8, so from a binary compatibility and API point of view, its going to be using the javax namespace.
  • 16:00 You’ll be able to take your existing applications and move them over really quickly, and we expect all of the vendors to jump on the JakartaEE branding right away.
  • 16:10 That’s the first release; the timetable for getting that out is before Oracle CodeOne in September 2019.
  • 16:30 There’s a surprising amount of work that needs to happen to allow us to ship exactly the same specs.
  • 16:35 We have to run each one of the specs through the new JakartaEE spec process.
  • 16:40 Every one of those we have to create the projects, get the scope statements right, get the documents and copyright holders to allow us to change the documents, run it through approval process.

What is the JakartaEE spec process?

  • 17:05 Part of this journey included creating a spec process for the Eclipse Foundation from scratch.
  • 17:15 If you go back a year and a half ago, the Eclipse Foundation did not do specs.
  • 17:20 We created a spec process that is an overlay on top of our development process.
  • 17:25 The Eclipse Foundation is similar to the Apache Software Foundation, in that we have a particular governance model that governs how projects operate.
  • 17:35 They have a lifecycle, they go through incubation, there’s meritocracy rules about how committers are added, that sort of stuff.
  • 17:40 We have an Eclipse Way (which is somewhat similar to the Apache Way).
  • 17:45 The idea for the spec process was to create a well-grounded professional specification process that is an overlay on top of how we run open-source projects.
  • 18:00 We know how to run open-source projects: we’re good at those, so what are the additional things we need to add in order to create specifications?
  • 18:10 One of the things that most developers might not realise is that spec processes are significantly different to open-source processes.
  • 18:20 For example, we know that if you contribute to an open-source project, you are making contributions under the license that’s being used by the open-source project.
  • 18:25 Most modern open-sources licences have a royalty-free patent grant on them.
  • 18:40 The patent grants on specifications are far broader, in the sense that our entire patent portfolio, whether it reads contributions we made to the spec or not, is licensed to all independent implementations of the final specification.
  • 18:55 That’s a much bigger and broader patent license than you typically get on open-source projects.
  • 19:00 As a result, companies that join spec processes want to see a little bit more formality, because they’re contributing potentially great swathes of their patent portfolio to the specification.
  • 19:20 That’s why we think of spec processes as being slow and cumbersome; it’s because they’re designed to be somewhat slow and cumbersome.
  • 19:25 To the people who live in this world, that’s a feature, not a bug.
  • 19:30 That’s what we did in the spec process: when do those licenses vest; how does someone join a spec project; how do we get companies to sign up agreements; how might their patents be used.
  • 19:50 It’s basically building this toolkit of formality on top of our development process.
  • 20:00 That said: our spec processes are run as close to an Eclipse Foundation open-source project as we possibly can.
  • 20:05 Compared to the JCP, which is the predecessor, it’s going to be a much more open and agile process that was happening with the JCP.

What does the JakartaEE release process look forward after 8?

  • 20:30 There’s a medium-term topic and a longer-term topic.
  • 20:35 The medium-term topic is: what do we do for the first release after JakartaEE 8 done?
  • 20:40 The content of JakartaEE 9 is a vigorous debate on the (jakarta-dev-)platform mailing list right now. []
  • 20:50 There are two schools of thought: one is the big-bang, let’s take the namespace of javax and switch it to jakarta all at once.
  • 21:00 There are some technical things that become possible, such as using class loaders that will automatically map javax namespace to jakarta namespace so you can get binary compatibility.
  • 21:15 The incremental approach is to replace the namespace on an incremental basis when we want to update the spec for a package.
  • 21:25 We haven’t even decided the content of the next release at that level of granularity, let alone talking about new specs or anything like that.
  • 21:35 We purposefully and explicitly said that we are going to let this debate go until sometime in mid-June, and we’re going to make a decision and go forward.
  • 21:45 Until we make that decision, we don’t have a date for JakartaEE 9.
  • 21:55 Let’s say that we do a release for JakartaEE 9 and the only thing that we do is this mechanical translation of the namespace - we could probably crank that out in 8 weeks.
  • 22:05 If we decide to add new specs or if we do an incremental approach, that would take longer.
  • 22:10 Looking further down the line, once we get the JakartaEE 9 release out the door, what are we going to do about a standard release train cadence, whether we’re going to follow a release train - these are questions we aren’t going to answer until sometime in 2020.
  • 23:05 The one thing we haven’t talked about yet, which is important: in parallel with these activities, MicroProfile continues to move quickly.
  • 23:15 MicroProfile has a release cadence of 3 spec releases per year.
  • 23:20 They just released MicroProfile 3.0, so they are going to move their specs forward quickly: innovation continues to happen while we are sorting out the Jakarta topics.

what is the distinction between MicroProfile and JakartaEE?

  • 23:40 Think of MicroProfile as being a distinct overlay on top of pieces of JavaEE.
  • 23:50 MicroProfile [] has a whole set of specifications - 16 - and they are related to the kinds of APIs and technologies needed to deliver micro-service based applications written in Java.
  • 24:10 It uses a couple of specs from JavaEE: CDI, JaxRS and a few others.
  • 24:20 They pulled a couple of specs from JavaEE, added a bunch of stuff on top that’s useful for micro-services, and that’s what MicroProfile is - so it’s distinct from JavaEE.

What’s the long term goal for the Eclipse Foundation?

  • 24:45 The Eclipse Foundation is not a company: we don’t have a particular agenda here.
  • 24:50 What we’re good at is getting companies - often direct competitors - to collaborate on building technology platforms.
  • 25:00 We have IBM, Oracle, RedHat, Fujitsu, Tomitribe, Payara - all of the existing incumbents in the JavaEE space involved in this.
  • 25:10 Our goal with both JakartaEE and MicroProfile is to help those companies define a multi-vendor platform for cloud-native Java.
  • 25:25 There are millions of developers who know this technology, and thousands of companies who have deep institutional memory, knowledge and skills on building Java applications - they want to modernise and move it forward into the cloud.
  • 25:40 We feel that the technologies that are being developed at the Eclipse Foundation are going to define the future for Java development in the cloud.
  • 25:50 I would strongly encourage developers to learn more about the specs and the projects that are implementing them and to engage and participate - the more developers we have, the better the end result is going to be for everyone involved.

From time to time InfoQ publishes trend reports on the key topics we’re following, including a recent one on DevOps and Cloud.  So if you are curious about how we see that state of adoption for topics like Kubernetes, Chaos Engineering, or AIOps point a browser to

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article