Mike Milinkovich, executive director at the Eclipse Foundation, introduced a new Eclipse governance model and roadmap for Jakarta EE at this year's JAX conference. Based on a recent worldwide survey of over 1800 Java developers, the new governance model will focus on support for microservices, cloud native application development, and faster release cycles.
During his session entitled The Future of Java Innovation, Milinkovich also unveiled the anticipated new Jakarta EE logo that will be featured on the new Jakarta EE website:
The Jakarta EE developer survey defined three critical areas:
- Better support for microservices
- Native integration with Kubernetes, Docker, etc.
- Faster pace of innovation
Milinkovich recently spoke to InfoQ on the future of Jakarta EE. Reflecting on the results of the survey, Milinkovich stated:
In order to realize those objectives that have been set out for us by the community and which, by the way, resonated really well with us, this is one of those great situations where we had suspected that was what developers wanted us to do. We heard back loud and clear that we were in-sync on that.
Milinkovich continued:
The first thing to remember is that we're moving all of Java EE to the Eclipse Foundation and renaming that under the Jakarta EE brand. Java EE will continue to exist and be supported at its current version level, but going forward, all future work is going to be under the Jakarta EE brand.
The Fortune 1000 all use Java EE somewhere in their infrastructure, and there's millions of Java EE developers around the world, so this is a very important technology platform and drives a huge percentage of enterprised systems.
Milinkovich recalled his experience after Oracle transferred ownership of Java EE to the Eclipse Foundation last fall and discussed the path forward:
This has been a real voyage and, in the end, we expect there to be something on the order of forty new projects and, say, roughly three hundred new committers on Eclipse projects. This is a very significant amount of work to on-board all of Java EE and rename it under Jakarta EE.
To move forward with this, we have set up the Jakarta EE working group, which is going to establish the governance for this initiative. We are in the process of establishing a whole new specification process that is going to take over the role of the JCP in this area, so that's going to be a significant undertaking as well. There will be work to be done in order to figure out the brand compliance programs for Jakarta EE, but we're off to a really good start.
InfoQ: As stated in the press release, "The Eclipse top-level project managing the Jakarta EE codebase has already committed to two releases in 2018." Is there a proposed schedule for these releases?
Milinkovich: It's a little more subtle than that. We're committing to two releases of the technology projects that are moving into Eclipse this year. So they're going to be dubbed Eclipse GlassFish 5.1 and 5.2. Eclipse GlassFish 5.1, which is going to be the first time we actually ship all these projects from the Eclipse Foundation, and is going to be a major milestone in terms of on-boarding all of these projects. This is going to be certified as Java EE 8 compatible using the original Java EE TCKs. Then as soon as we can after that, we're going to spin a 5.2 release which will be Jakarta EE 8 compatible.
So the first version of the Jakarta EE specs are going to be at the same level as the Java EE specs and, as of this moment, they're going to be identical or as close to identical. This is just part of a porting exercise and we want to keep as few degrees of freedom as possible.
The importance of shipping a release that is branded as Jakarta EE 8 compatible means that we are going to have all of the specification processes up and running and the certification programs and legal agreements in place to run the certification program.
InfoQ: Is there a specific time table?
Milinkovich: Eclipse GlassFish 5.1 by the end of the third quarter and Eclipse GlassFish 5.2, certified as Jakarta EE 8, by the end of the year.
InfoQ: We noticed the most recent round of project proposals included GlassFish.
Milinkovich: Yes, the most recent batch proposals included GlassFish and we're getting pretty close. Actually, the important one that people haven't commented on too much is the project proposal for open sourcing all of TCKs. It's going to be, I think, pretty important when all those TCKs become open source.
InfoQ: Jakarta EE is based on Java EE 8, right?
Milinkovich: You have to think carefully about what the open source stuff is versus the branding and specification-based things. Jakarta EE, just like Java EE, is a brand which is attached to a certification program. So before you can claim that WebSphere is Java EE 8 certified, you have to pass the Java EE 8 tests.
A similar thing is going to be established under the Jakarta EE name, but the important thing to understand is - this is not just about shipping open source code from the Eclipse Foundation. This is also about enabling independent implementations both proprietary and open source which are also under the Jakarta EE brand.
There's no formal announcements from any of the vendors, but as of this moment, I would hope and expect that some day there will be a release of WebLogic which is branded as Jakarta EE and certified as Jakarta EE 8 compatible. And similarly for WebSphere, JBoss, TomEE, and the like.
InfoQ: There seems to be confusion between the names Java EE, Jakarta EE, and EE4J. Can you the explain the differences to our readers?
Milinkovich: Java EE is the set of specifications that defines Java EE today. That's done under the JCP process and will continue in the marketplace for many years to come at the current version level, so it's basically being put into maintenance-only mode. If you are a Java EE customer today, your vendor is going to continue to support that platform for you for years to come.
Jakarta EE is going to be the name of this technology platform moving forward, so future versions of this technology, and its specifications will be released under the Jakarta EE name and brand. And we're going to be setting up a similar process where to certify your product as Jakarta EE compatible, you will have to pass a set of tests. The starting point for those tests are the same set as Java EE because they're being contributed to the Eclipse Foundation by Oracle as part of this process.
EE4J is simply the name of the top level projects at the Eclipse Foundation where most of these projects are being run. As a general rule, it's highly unlikely that you would ever use EE4J as a name referring to anything. People in the future will identify themselves as Jakarta EE developers. EE4J is simply an organizational artifact of how we run projects at the Eclipse Foundation.
All of the reference implementations for this technology like Glassfish, Jersey, Grizzly, JAX-RS, and so forth, are all under the EE4J top level project, but it is not a brand, it is just simply the name of the top level project. The confusion comes because we hadn't picked the brand name yet. So people started calling it EE4J because that's the only name they had.
It's unfortunate that this confusion exists, but it was unavoidable and hopefully over time you will just stop hearing about EE4J altogether.
InfoQ: So Oracle will still maintain the Java EE brand?
Milinkovich: Java EE and Java remain a trademark owned by Oracle. If you're going to call something Java EE, then you have to talk to Oracle about being able to use that name. You may have read some articles that tried to make a controversy out of this and painting Oracle in a bad light because they they didn't give the name, Java EE, to the Eclipse Foundation.
There are two things I would point out. One, it was never going to happen. They were absolutely clear from the very beginning that Java is an important brand to Oracle and they are going to continue to own that brand. And if you know anything about big companies and trademark law, you would understand that is the way it was always going to be.
The second point is that we actually look at this renaming as a very positive thing and a great opportunity for this technology. In the minds of many developers, Java EE is always going to mean the on-premise application servers of ten years ago. By calling it Jakarta EE, we have an opportunity to change in the minds of developers what this technology is capable of. So I'm actually excited about this renaming. I think this is a great opportunity for us to rebrand this technology, reposition it in the minds of developers, and have a more positive story going forward.
InfoQ: So the new focus on cloud native is definitely a good start.
Milinkovich: Exactly, with a focus on cloud native and microservices, and I expect reactive is going to be in there pretty soon as well. These are very important technology trends coming into Jakarta as fast as we can get them. What I'm hoping, and I'm fairly confident that this is going to come to pass, is that a year from now, there will be developers who are willing to try Jakarta EE because it's something new and interesting.
Perhaps they would never have considered trying a new release of Java EE because they have this mental picture that it's something that's not going to help them solve their problems. So I think this renaming is a great opportunity for this community and technology.
InfoQ: With Java EE 8 in maintenance-only mode, Oracle won't develop Java EE any further?
Milinkovich: Right, there's never going to be a Java EE 9.
InfoQ: A lot of applications such as Payara, GlassFish, OpenLiberty, etc. won't execute on Java SE 9. But, there has been a some movement in this area. For example, the supporting projects of Data Geekery's jOOQ have already been modularized and Speedment started the process of migrating to Java 9 last year. Will Jakarta EE ultimately support Java 9?
Milinkovich: I think it's safe to say that at some point - absolutely. It is very clear that the overall Java EE ecosystem has not yet modularized their code to take advantage of Jigsaw, so it's still very much a work in process.
The Java ecosystem, as a whole, is going to have to stay current on new developments in the platform and language. I'm confident that it will eventually happen. Do I know when it will happen and which release it will wind up with? No, I don't. It's going to have to find its way into the queue and of many important things that need to be done.
InfoQ: Of course, the current activity has a higher priority than supporting Java 9.
Milinkovich: Part of that has to do with adoption. If you look at the survey results, you'll see that adoption of Java 9, and now the newly released Java 10, is miniscule compared to Java 8. So I think what's going to happen in a couple of years, when support for Java 8 expires, you're going to see more movement.
At the moment, people have code that works to the point where you can embrace Jigsaw and modularity entirely. That's an enormous amount of work, so they're just putting it off until they're forced to.
In the meantime, I think the pressure is on the tools and frameworks that are built on top of Java to get themselves ported over so when customers and enterprises start moving all of the various bits of infrastructure, everything from IDEs to logging, migrating the entire Java ecosystem over to modularity is an enormous task.
InfoQ: Does the removal of the Java EE and CORBA modules (JEP-320) in JDK 11 affect Jakarta EE in any way?
Milinkovich: Because Java EE is moving to the Eclipse Foundation, they want to make sure there's an absolutely crystal clear separation between between SE and EE. There are some pieces of the JTA spec that had leaked into SE and they're being pulled out as well. So that's just background cleanup work that's happening in parallel with everything else.
InfoQ: With the new six-month release cycle of JDK, is there a need to do the same with Jakarta EE?
Milinkovich: We don't know yet. My personal opinion, and this is not meant to reflect the opinion of any of the technical leaders in the community, is that I don't see any particular reason why Jakarta EE needs to ship every six months just because Java SE is doing so.
The rate and pace of innovation, I think, is going to be determined by what we need to do to embrace cloud native and microservices, to implement reactive, and I think relatively few of those innovations are specifically tied to brand new features in the Java SE platform. We will come up with a release cadence that makes sense for us and, in particular, since the rate at which enterprises are moving forward on to new versions of Java is definitely slower than the rate at which they're shipping them.
At this moment, I don't see any particular value in tying ourselves to a six-month release cadence just because SE is doing it. But we will see. I can imagine a scenario, for example, where we do ship every six months, but that doesn't necessarily mean that we move to a new version of Java every six months.
If the enterprises and the cloud frameworks are not moving to the latest-and-greatest Java every six months, then I don't see any particular reason why Jakarta EE needs to. Like I said, that was my personal opinion. The smart technical people running these projects might have a completely different viewpoint so, we'll see.
InfoQ: Does the Eclipse Foundation have a working relationship with the Cloud Native Computing Foundation?
Milinkovich: I think it's fair to say that we hope to have a working relationship with them. We are already in the process of building a working relationship with the CNCF for some of the technology that we're building in IoT. We have a goal of making sure that the Jakarta EE platform form is as absolutely strong as possible on the Kubernetes and Docker ecosystem to the degree that we can work with them collaboratively to talk about requirements from both sides.
I think this is a great opportunity for both of us because obviously Kubernetes has enormous momentum in the industry. It does so because it provides the ability for people to move workloads from cloud-to-cloud provider but also from on-premise cloud infrastructure to public cloud infrastructure. So it just provides them with a great deal of deployment flexibility.
But at the same time, Java is very much the number one language platform in the enterprise. So the degree to which we can closely couple these two technologies, I think it's going to help both sides in terms of enabling enterprises to embrace the cloud, but also taking the skills of literally millions of developers and helping them bring those skills forward into this new technology domain.
InfoQ: Does that mean the Eclipse Foundation and the CNCF need to be members on each other's organizations?
Milinkovich: So we might do that, but neither us nor the CNCF is a pay-to-play kind of foundation. That's not what we do, but it would be a nice gesture, I think, on both parts to say publicly that we're collaborating and we have good things to build together.
Resources
- The Relationship Between Jakarta EE, EE4J, and Java EE by Ivar Grimstad (March 26, 2018)
- Background on Oracle's Contribution to Jakarta EE by Will Lyons (April 24, 2018)
- The Road to Jakarta EE by David Delabassee (April 24, 2018)
- The Eclipse Foundation Has Established Jakarta EE Working Group by Fujitsu (April 24, 2018)
- In Support of Jakarta EE's Quest to Accelerate Cloud Native Java by Mark Brewer (April 24, 2018)
- Jakarta EE - The New Home for Enterprise Java by Ian Robinson (April 24, 2018)
- Jakarta EE is Officially Out by Mark Little (April 24, 2018)
- The Future of Cloud-Native, Open Source Java with Jakarta EE by Debbie Hoffman (April 24, 2018)