Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Archive for the ‘Foundation’ Category

EE4J Code Arrives

Last week the EE4J project achieved an important milestone when the source code for the API and reference implementation of JSON-P JSR-374 project was pushed by Dmitry Kornilov into its GitHub repository in the EE4J organization. This is the first project of the initial nine proposed to reach this stage.

This may seem like a small step in a very large process, but it is a concrete demonstration of the commitment to move forward with the migration of Java EE to the Eclipse Foundation. The Oracle team and the Eclipse Foundation staff had a ton of work to do to make this possible. This is definitely one of those cases where the visible code contributions are just the visible tip of an iceberg’s worth of effort.

Here are just a few examples of the work that went on to get to this stage:

  • The names of the projects such as Glassfish represent important trademarks in the industry. Oracle transferred ownership of these project names to the Eclipse Foundation so that they can be held and protected for the community.
  • The EMO staff reviewed the projects proposals, ran the project creation review, provisioned the repositories and set up the committer lists.
  • The Oracle team packaged up the source code and updated the file headers to reflect the new EPL-2.0 licensing.
  • The EMO IP staff scanned the code and ensured that all was well before approving it for initial check-in.

Now that the collective team has run through this process with JSON-P we will be working to get the remaining eight initial projects pushed out as quickly as possible. Hopefully by the end of this month. Meanwhile, more projects will be proposed and we will be migrating a steady stream of Java EE projects into EE4J.

Exciting times!


Written by Mike Milinkovich

January 15, 2018 at 11:51 am

EE4J Progress: Nine New Projects Proposed at the Eclipse Foundation

I am very pleased to announce that the first nine project proposals for the Eclipse Enterprise for Java (EE4J) top-level project have been formally published for community review. This is the first step to making the migration of Java EE to the Eclipse Foundation a reality.

The process of migrating the EclipseLink (JPA) and Eclipse Yasson (JSON-B) projects to EE4J is also underway.

We look forward to feedback from the community on these proposals!

EE4J Project Proposals

Name: Eclipse Grizzly
Top-Level Project: EE4J
Stage: Community Review
Project Link:

Description: Writing scalable server applications in the Java™ programming language has always been difficult. Before the advent of the Java New I/O API (NIO), thread management issues made it impossible for a server to scale to thousands of users. The Eclipse Grizzly NIO framework has been designed to help developers to take advantage of the Java™ NIO API.

Name: Eclipse OpenMQ
Top-Level Project: EE4J
Stage: Community Review
Project Link:

Description: Eclipse Open Message Queue (OpenMQ) is a complete message-oriented middleware platform, offering high quality, enterprise-ready messaging.

OpenMQ is included in GlassFish.

Name: Eclipse Mojarra
Top-Level Project: EE4J
Stage: Community Review
Project Link:

Description: Eclipse Mojarra is the Reference Implementation for the JavaServer Faces specification (JSR-372). JavaServer Faces (JSF) is a Java specification for building component-based user interfaces for web applications. It is also a MVC web framework that simplifies construction of user interfaces (UI) for server-based applications by using reusable UI components in a page.

Mojarra is included in GlassFish.

Name: Eclipse Message Service API for Java (JSR-914)
Top-Level Project: EE4J
Stage:  Community Review
Project Link:

Description: JSR- 914: The Java Message Service (JMS) API is a Java Message Oriented Middleware API for sending messages between two or more clients. It is an implementation to handle the Producer-consumer problem.

Name: Eclipse Tyrus
Top-Level Project: EE4J
Stage: Community Review
Project Link:

Description: Eclipse Tyrus provides a reference implementation for Java API for WebSocket, starting from the specification defined by JSR-356.

Name: Eclipse Java API for RESTful Web Services (JAX-RS)
Top-Level Project: EE4J
Stage: Community Review
Project Link:

Description: JAX-RS: Java API for RESTful Web Services (JAX-RS) is a Java programming language API spec that provides support in creating web services according to the Representational State Transfer (REST) architectural pattern.

Name: Eclipse Jersey
Top-Level Project: EE4J
Stage: Community Review
Project Link:

Description: Eclipse Jersey is a REST framework that provides JAX-RS (JSR-339) Reference Implementation and more. Jersey provides its own APIs that extend the JAX-RS toolkit with additional features and utilities to further simplify RESTful service and client development. Jersey also exposes numerous extension SPIs so that developers may extend Jersey to best suit their needs.

Name: Eclipse WebSocket API for Java (JSR-356)
Top-Level Project: EE4J
Stage: Community Review
Project Link:

Description: Java API for WebSocket (JSR-356), specifies the API that Java developers can use when they want to integrate WebSockets into their applications – both on the server side as well as on the Java client side.

Name: Eclipse JSON Processing
Top-Level Project: EE4J
Stage: Community Review
Project Link:

Description: Eclipse JSON Processing (JSON-P) is a Java API to process (e.g. parse, generate, transform and query) JSON documents. It produces and consumes JSON in a streaming fashion (similar to StAX API for XML) and allows to build a Java object model for JSON using API classes (similar to DOM API for XML).



Written by Mike Milinkovich

November 21, 2017 at 11:31 am

Posted in Foundation

Help Pick the New Name for Java EE

This blog post is based on the text of Eclipse EE4J’s very first GitHub Issue. Please join the conversation over there!

We need a new brand name for the set of specifications that will be created by the new community process. This brand name will also become a certification mark in the industry for compatible, independent implementations. The open source projects that fall under the Eclipse EE4J top level project will be one such implementation. In short, we need a new name to replace “Java EE”. Much like the OpenJDK project implements the Java SE Platform specification, the EE4J projects will provide implementations of a set of specifications that we today call Java EE: we need a brand name for this set of specifications.

With this in mind, we are initiating a community process to select the brand name. This process will be managed by the EE4J Project Management Committee (“PMC”) with assistance from the Eclipse Management Organization (“EMO”). The name that is selected by this process must pass legal and other trademark searches to ensure that the names are available for use. As a result, it is possible that the favoured selection will not be the ultimate choice. The final decision will be made by the EMO Executive Director (“EMO(ED)”) in consultation with the PMC.

The process is described in greater detail below.


Names can be nominated by anyone in the community via this GitHub Issue record.

Nominations will be open from November 15 until November 30, 2018.

Naming Guidelines

All suggested names must conform to the following:

Any suggested names which fail to meet the above criteria will be rejected.

Name Selection Process

The process will be executed as follows:

  1. Members of the community will be invited to enter their nominations into the specified channel;
  2. At the end of the nomination period, the names suggested by the community will be reviewed by the PMC to identify those which meet the criteria specified in the by the naming guidelines (depending on response, the PMC may decide to further reduce the list to a manageable size);
  3. The PMC will then initiate a community vote using the CIVS system (which will produce an overall ranking of the choices); and
  4. The results of the vote will be delivered to the EMO(ED) who will engage in the required legal and other trademark searches to ensure that the names are available for use, and consult with the PMC to make the final decision.

Since we have no idea what sort of community response to expect, it is difficult to time box anything other than the initial nomination process. But this will be an open and transparent process, and we invite the community to engage in all aspects of it. There is a great deal of legal, marketing, and community thought that goes into selecting an industry brand, so it’s important that we get this right. This may take a little time.

Written by Mike Milinkovich

November 15, 2017 at 11:29 am

Posted in Foundation

On Naming, or Why EE4J Does Not Suck

“You keep using that word. I do not think it means what you think it means.” — Inigo Montoya, The Princess Bride, on Vizzini’s use of the word “inconceivable”.

On Thursday we announced that the draft top-level project charter for Eclipse Enterprise for Java (EE4J) was available for community feedback. Since that time, we haven’t received any feedback on the charter, but we have certainly had a lot of passionate feedback on the choice of name. If I could, I would summarize the bulk of the feedback that we’ve seen as “…EE4J is a pretty good acronym, but WTF is Eclipse doing in the name?” A lot of that feedback is based on some incorrect assumptions about what the EE4J name means. Which is totally my fault, because my initial blog post did not provide any context for how EE4J will be used, and not used, as a name and a brand. Hopefully this post will correct that.

Before I begin, I have to mention that a very large caveat on everything that follows. This post is based on my best guess on how things are going to work out, with the information I have at this moment. However, there are a significant number of agreements that have to be discussed regarding names, trademarks, and so on that have not yet been completed. It is possible that the future will not unfold as I think it will. So with that said….

EE4J is not the brand

I think that many people are assuming that EE4J will become the brand that replaces Java EE. Wrong. Java EE is a certification mark. To label something as “Java EE”, you need to get a license from Oracle and pass the TCKs. There are many implementations of Java EE such as WebLogic, WebSphere, JBoss, and Glassfish. EE4J is the name of the top-level project  at the Eclipse Foundation. As such it is the umbrella under which the source code and TCKs for Glassfish, EclipseLink, and (hopefully) Eclipse MicroProfile will exist.

We are months away from even starting to define the specification process that will be used in the future. However, when we do I expect that this new process will create a new certification mark which can be properly considered the new “Java EE” name. We will be engaging with the community in the selection of that name.

The existing project names will continue to be used

I have seen some comments along the lines of “…it’ll be weird to install Eclipse Enterprise for Java into IntelliJ”. I’m actually pretty sure that what people will be installing is more likely to be called something like Eclipse Glassfish, or Eclipse MicroProfile.

Again, EE4J is the name of the top-level project at Eclipse. The projects within EE4J will continue to have their own identity, just as they do today. The committers and the PMC for EE4J will be deciding what artifacts they will be releasing and whether anything actually ships under the name EE4J. Maybe they will, maybe they won’t. But only time will tell.

The solution space is smaller than you think

Anyone who has ever built and maintained a large piece of software knows that naming is hard. Naming widely used technologies that take on a brand identity and which require trademarking are harder still. Selecting the EE4J name had to solve a number of real world constraints:

  • We wanted it to contain the word Java, but it also had to comply with the Java trademark guidelines. Oracle is the only entity that can use the word Java at the beginning of a name. Which meant that using “for Java” was pretty much a fixed requirement.

  • Whether you call it JEE, J2EE, or Java EE for the entire life of the enterprise Java platform “EE” has been in the name. Continuing that tradition provides some clear benefits in terms of continuity and brand recognition. For what it is worth, we basically selected the acronym first and then backed into what the letters in the acronym might mean.

  • The name has to be available to be trademarked. We actually ran full legal trademark searches on a couple of alternate names, and EE4J was the clear winner in terms of availability.


Hopefully this post provides some context for the naming choice that will help people understand what EE4J is, and is not, as a project name, brand, and trademark.

As Mark Little of Red Hat said in his post earlier today

There’s a lot of pent-up passion and energy around Java EE and it would be so much better if individuals focused that on the charter at this point than complaining about the name. Yes, I understand that some people feel the name is important to the success of this effort but I can tell you all that there’s a lot more to choosing a name for a foundation or massively successful project than just … choosing the name.

The passion and commitment of the people in the Java EE community is amazing. Working with this community and welcoming you all to Eclipse is an opportunity and a responsibility that all of us at the Eclipse Foundation take very seriously. The future success of EE4J and the enterprise Java platform is going to be determined by whether we can get you talented, smart, and passionate Javaistas to contribute to the projects and the community. 

I am looking forward to JavaOne next week, and hope to see many of you there!

P.S. Comments and discussion are welcomed over on the ee4j-community list. There are already over 100 subscribers there!

Written by Mike Milinkovich

September 30, 2017 at 5:30 pm

Posted in Foundation

Introducing EE4J: The first step towards Java EE at the Eclipse Foundation

I am very excited and proud to introduce the new top-level Eclipse Enterprise for Java (EE4J) project. For those that might not have heard, Oracle has announced their intention to move Java EE to the Eclipse Foundation. Creating the EE4J top-level project is the first step to making this a reality.

Moving Java EE to the Eclipse Foundation is going to be an exciting and massive undertaking. It is a significant opportunity to use the Eclipse open development model to accelerate innovation in Java for enterprise and cloud native computing. We look forward to engaging with the millions of developers and organizations using Java EE.

The Java EE technology is a very large portfolio of source code, TCKs and specifications. Moving all of Java EE will be a significant undertaking for the community. For instance,

  1. 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.
  2. 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.
  3. Create an open build infrastructure so EE4J can be built and tested by the community.
  4. Establish a new specification process under the auspices of the Eclipse Foundation.

The good news is Oracle, along with IBM and Red Hat, is moving incredibly fast. Publishing the top-level project charter is an important first step. However, we are aware that there are literally millions of developers who have a vested interest in the future of the enterprise edition of the Java Platform, and who quite rightfully would like to have detailed plans now for how and when the above list are going to be completed. Unfortunately, the details are going to take some time to plan and execute. Moving Java EE to the Eclipse Foundation is going to be process, not an event. I do expect this will be an open process that encourages community members to contribute.

Today marks a very significant milestone in our journey. We are pleased to announce that the draft charter for the Eclipse Enterprise for Java top-level project is now available for community review and feedback. We have created the ee4j-community mailing list for the community to use to provide that feedback, so please subscribe to the list and join the conversation!

Written by Mike Milinkovich

September 28, 2017 at 8:30 pm

Posted in Foundation, Open Source

Java EE Moves to the Eclipse Foundation

Oracle announced today that they, along with IBM and Red Hat, will be moving Java EE to the Eclipse Foundation. I would like to welcome everyone involved to our community. We look forward to working with all of the participants in the Java EE ecosystem as it moves to a more open and collaborative development model.

Java EE has been at the center of enterprise computing for almost twenty years. As enterprises move to a more cloud-centric model, it is clear that Java EE requires a more rapid pace of innovation. The open source model has been shown time and again to be the most successful way to innovate in today’s world. The Eclipse Foundation is focused on enabling open collaboration among individuals, small companies, enterprises, and the largest vendors. The Eclipse MicroProfile project is, we believe, an excellent example of the developer community led style of collaboration we support. We look forward to supporting the Java EE community as it creates the platform for the next twenty years of business applications.

Written by Mike Milinkovich

September 12, 2017 at 4:21 pm

Posted in Foundation

Java: Free At Last

There was lots of news in the land of Java yesterday. If you have not already seen the posts by Mark Reinhold and Donald Smith of Oracle, I encourage you to read:

There has been an enormous number of articles written about this news, most of which have focused on the new time-based release cadence. Obviously coming from an Eclipse background, I’m a big believer in the idea of release trains. After all, Eclipse Foundation projects have been doing this for over a decade. I believe that this is going to be a good thing for the Java platform, once the teams inside Oracle get into the groove of producing time boxed releases.

But relatively little has been written about what I think is the really big news:

“…Oracle plans to ship OpenJDK builds under the GPL…” and “…within a few releases there should be no technical differences between OpenJDK builds and Oracle JDK binaries.”

Which means that Java will finally be freed of the explicit and implicit field of use restrictions which have dogged it since its invention. Developers will be free to use Java on any device, without requiring any additional licensing or other permission. I believe that this is going to lead to a resurgence of innovation in the Java ecosystem. And I am particularly optimistic about what this could mean for Java as the language of choice for many solutions in the Internet of Things.

The license that Java binaries are currently distributed under today is the Oracle Binary Code License, which states (emphasis added):

“General Purpose Desktop Computers and Servers” means computers, including desktop and laptop computers, or servers, used for general computing functions under end user control (such as but not specifically limited to email, general purpose Internet browsing, and office suite productivity tools). The use of Software in systems and solutions that provide dedicated functionality (other than as mentioned above) or designed for use in embedded or function-specific software applications, for example but not limited to: Software embedded in or bundled with industrial control systems, wireless mobile telephones, wireless handheld devices, kiosks, TV/STB, Blu-ray Disc devices, telematics and network control switching equipment, printers and storage management systems, and other related systems are excluded from this definition and not licensed under this Agreement.

Making Java binaries available directly from OpenJDK is going to free the Java platform for developers. Getting these directly from the platform owner, and (more importantly) having them be identical to the commercial binaries is a radical step forward. OpenJDK-based binaries will be exactly on par with, and equivalent to, the commercial ones. Although almost all of the Java source code has been open source at OpenJDK for many years, the subtle differences in content, performance, and reliability have prevented mainstream adoption of OpenJDK binaries by enterprises and industrials.

A little over a decade ago, Sun Microsystems started the process of open sourcing Java. It seems that Oracle is finally finishing the job. Good for them.

Written by Mike Milinkovich

September 7, 2017 at 4:45 pm

Posted in Foundation