Life at Eclipse

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: https://projects.eclipse.org/proposals/eclipse-grizzly

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: https://projects.eclipse.org/proposals/eclipse-openmq

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:  https://projects.eclipse.org/proposals/eclipse-mojarra

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: https://projects.eclipse.org/proposals/eclipse-message-service-api-java

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: https://projects.eclipse.org/proposals/eclipse-tyrus

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: https://projects.eclipse.org/proposals/eclipse-restful-web-services-api-java

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:https://projects.eclipse.org/proposals/eclipse-jersey

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: https://projects.eclipse.org/proposals/eclipse-websocket-api-java

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: https://projects.eclipse.org/proposals/eclipse-json-processing

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).

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.

Nominations

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:

• They must conform to Oracle’s trademark usage guidelines. Amongst other things this means that the name cannot start with the word “Java”.
• They must conform to the Eclipse Foundation trademark guidelines.
• They must not be obscene, sexist, racist, controversial, etc., and they must not be frivolous (e.g. we’re not going to choose Boaty McBoatface or the like.)

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.