Introducing EE4J: Java EE takes first steps into Eclipse Foundation [Update]
© Shutterstock / Miroshnichenko
IBM and Red Hat have recently expressed their support for Eclipse Enterprise for Java —we’re still getting used to EE4J but the good news is that there’s now a FAQ which answers all the right questions — what, why, who and where it’s going. Let’s have a look at this new top-level Eclipse project.
Last month, software evangelist David Delabassee announced EE4J, a new top-level Eclipse project and promised that a FAQ will be published soon. Well, it’s here now and it answers the following questions:
- What is Eclipse Enterprise for Java (EE4J
- Why is this decision to move Java EE to EE4J being made?
- Who is driving this? In August of 2017, Oracle announced its intention to evaluate opening up Java EE by moving Java EE technologies to a foundation. Oracle decided to approach IBM and Red Hat to ensure a critical mass of sponsorship and support for the initiative. IBM and Red Hat were supportive. Together we approached a number of foundations and our consensus was to implement this project at the Eclipse Foundation.
Together Oracle, IBM, Red Hat and the Eclipse Foundation are creating this project and opening it up to the community. The EE4J project will have an Eclipse Project Management Committee (PMC) similar to other Eclipse projects, but membership of the PMC has not yet been determined. We intend for this to be a meritocratic, community-driven project going forward.
- What is the status of the project and what are the next steps?
- Why is this named EE4J? Why not continue to use the Java EE brand? There will be a new process for evolving the technologies that is different from the Java EE process. Oracle has also stated its preference for use of a different name. Therefore a different name is appropriate. So although EE4J is intended to provide compatibility with Java EE, we are using a different name.
The primary community feedback we have heard on naming of the overall project is that “Java” be in the name, so we have met that requirement.
- Will EE4J use javax package names?
- Will new versions of existing specifications in EE4J be able to use existing specification names, (e.g. Java Servlet)?
- Will EE4J open source TCKs?
- What licenses will be used for sources?
- Will EE4J use the JCP process In general, EE4J will define new processes for platform evolution. Most of the questions on continued use of JCP have focused on the specification process specifically. The spec process remains to be defined within EE4J. Our current expectation is that specifications are likely to evolve outside of the JCP, so that a new more nimble, flexible and open EE4J process is not coupled to the existing JCP process. But this process has not yet been designed.
Our first priority for this project is planning the transition of Java EE 8 technologies as described above. This is important for creating the basic structure and organization of the project, and project momentum, upon which community participation and process design can be built.
- Will the EE4J project remain at GitHub?
- Will existing GlassFish committers be moved to EE4J?
- Who will decide what gets included in EE4J over time.
- What is the relationship of EE4J to Eclipse MicroProfile?
- Is Oracle dumping Java EE? No, Oracle is not “dumping” Java EE. Oracle will continue to support Java EE in its WebLogic Server product and will continue to support other vendor Java EE implementations through Java EE 8.
Looking beyond Java EE 8, the Java EE process was not seen as being nimble, flexible or open enough, particularly when compared to other open source communities. We felt it was time to address this feedback in a positive manner. We are doing so by collaborating with other vendors and an established foundation to define a new path forward. The platform will have a critical mass of sponsorship from multiple vendors, including Oracle. We intend to recruit community sponsors and provide backup sponsorship as required.
Oracle will step out of the role of platform spec lead – that will help create a more open and balanced process, that is not dependent on a single vendor or lead, that encourages participation and innovation, and that serves the collective interests of the entire community.
- What does this mean for my investment in Java EE application servers? Should I migrate to another technology because of this initiative?
- Will Oracle stop delivering GlassFish as the reference implementation for Java EE?
- Where should I go to find out what happens next with EE4J?
- What can users expect of EE4J?
- How will this affect current Java EE licensees and vendors of Java EE implementations?
Read the entire FAQ here.
IBM and Red Hat have recently expressed their support for Eclipse Enterprise for Java; IBM announced their support of “Open Java EE” at the Community Keynote at JavaOne and Mark Little, Red Hat VP of Engineering and CTO of JBoss Middleware wrote in a message to the ee4j-community that “Red Hat is committed to working for the continuing success of Java EE and now EE4J.”
We intend to put forward various individuals who may be relevant to lead various JSRs if no other appropriate community members step forward as well as the JSRs we lead currently. When the time is right (note, when not if) we’ll also work to ensure EE4J and Eclipse MicroProfile collaborate in a meaningful manner and hopefully “merge” in whatever way is appropriate and determined by both communities.
Mark Little, Red Hat VP of Engineering and CTO of JBoss Middleware
September 29, 2017
Software evangelist David Delabassee announced EE4J (Eclipse Enterprise for Java), a new top-level Eclipse project.
According to the draft charter, “Eclipse Enterprise for Java (EE4J) is an open source initiative for defining and evolving API specifications, reference implementations, and technology compatibility kits for Java application server implementations. Java application servers are software platforms that application developers and administrators use to develop, deploy, and manage server-side Java applications and microservices.”
EE4J is based on, and will evolve, the Java™ Platform, Enterprise Edition (Java EE) standard, using the Java EE 8 version as the initial baseline.
A FAQ should be published soon but in the meantime, you can read the EE4J draft charter to find out more about the new top-level Eclipse project.
— Java EE Platform (@Java_EE) September 29, 2017
Easier said than done
Mike Milinkovich, the Executive Director of the Eclipse Foundation, explained in a blog post that it won’t be easy to move all of Java EE since the technology “is a very large portfolio of source code, TCKs and specifications. For instance,”
- The GlassFish open source project includes 130 GitHub repos. Moving these existing GlassFish open source projects to the Eclipse Foundation, and getting all of the various sub-projects set up and under the Eclipse development process will take some time.
- The Java EE TCKs will be moved to Eclipse open source projects and be available to the community. What this means and how the community interacts with the TCKs needs to be defined.
- Create an open build infrastructure so EE4J can be built and tested by the community.
- Establish a new specification process under the auspices of the Eclipse Foundation.
Despite the magnitude of the move, the project is moving forward quickly. It’s safe to say that teamwork (Eclipse Foundation receives help from Oracle, IBM and Red Hat) has never looked so good!
Moving Java EE to the Eclipse Foundation is going to be a process, not an event. I do expect this will be an open process that encourages community members to contribute.
“The mission of Eclipse EE4J is to define and evolve API specifications, reference implementations, and technology compatibility kits for Java application server implementations,” according to the draft charter. “Java application servers are software platforms that application developers and administrators use to develop, deploy, and manage server-side Java applications and microservices. EE4J leverages and evolves the Java EE 8 standards in order to achieve this objective.”
The success of EE4J depends upon:
Rapid transition of Java EE 8 technologies to the EE4J project
A nimble, flexible and open process for evolving EE4J API specifications, reference implementations, and technology compatibility kits.
A strong community of developers, vendors, and end users who support and evolve the EE4J technologies.
Adapting and evolving EE4J technologies, and delivering innovations that address new requirements of existing users, and that attract new users.
Meeting well-defined compatibility standards across EE4J implementations, and across Java EE 8 and EE4J versions.
Enabling competing vendors and complementary technology providers to provide innovations that add value to EE4J technologies.
The initial scope of the EE4J project during late CY2017 and early CY2018 is to transition existing Java EE 8 technologies to the project and to define processes for evolving the platform:
A core set of Java EE 8 technologies, including GlassFish technologies, and Java EE technologies for which Oracle is the specification lead, forms the initial core of the EE4J platform.
This includes sources for Java EE 8 Reference Implementations (RIs), Technology Compatibility Kits (TCKs), project build and test scripts, and product documentation sufficient to build a documented RI from Eclipse Enterprise for Java sources and other software available in open source.
Some of the EE4J API implementations and TCKs continue to be available in other open source projects.
The initial Eclipse Enterprise for Java RI is compatible with GlassFish 5.0, and passes Java EE 8 compatibility tests transitioned to EE4J.
Read the entire draft charter here.
There’s also an ee4j-community mailing list for the community to use to provide feedback. Join the conversation!