The great code migration from Oracle to EE4J: Grizzly is shaping up nicely
The great Java EE migration is hitting its stride as various bits and bobs begin the shuffle from Oracle to the Eclipse Foundation. Since there’s so much happening right now, we’re checking in to see how things are going on and what’s next for EE4J, including a quick look at Grizzly NIO.
The great Java EE migration continues apace as Oracle and the Eclipse Foundation get ready to transfer everything over. Since there are so many moving parts, it’s probably not a bad idea to take a quick breather from packing boxes and see how everything is going so far. After all, making this move a success is a priority for the Eclipse Foundation and the EE4J community.
So, how is it going so far? Let’s take a look.
What’s in a name?
Java EE needs a new name. We knew that already. According to Mike Milinkovich, Executive Director at the Eclipse Foundation, they are already running trademark reviews on potential names to make sure they can be properly secured. No one wants a legal battle somewhere over copyright infringement.
Once they have a short list of potentials, there will be a community vote to make a final choice. We’re replacing a well-known name: community buy-in is important. But first, the lawyers have to do their thing.
Everything needs some kind of working plan to keep order and things moving in the right direction. So, although Eclipse is busy moving code, they’re also looking to the future. Eclipse Foundation intends on establishing a working group to provide a member-driven governance model for the EE4J community.
If an open source project is to succeed with business, a core governance charter is useful for establishing some kind of framework that everyone can agree upon. Eclipse intends on having a first draft available soon (hopefully by the end of January) for the community to review.
The great migration
One big thing that’s going on right now is the migration of code from Oracle to EE4J. Code is actually moving around on GitHub at this very moment. The first nine projects have been created and provisioned.
The next step is to propose the next projects to get shipped over. Oracle has proposed that the JSON-B API and JavaMail projects should be moved next, with JAX-B, JAX-WS, JSTL, UEL, JAF, Security, JTA, Enterprise Management, Concurrency, and Common Annotations to follow.
Everyone wants this to be done as quickly and coherently as possible. The big goal is to get everything up and running as fast as possible, to make sure that the community stays as intact as possible.
Eclipse is also concerned about showing that these projects are capable of shipping ASAP. So, a big short-term goal is to have the EE4J project ship a Java EE-8 compliant release in short order for Eclipse Glassfish and other projects. Why?
First and foremost, it demonstrates that Eclipse is capable of running and supporting the EE4J projects. Secondly, it means that developers can access EE4J projects as soon as possible, making it easier to nature and develop a community of developers and organizations. Eclipse is concerned about transplant shock. No one wants to put in all this effort only for the community to fail to thrive.
Relatedly, this is why Eclipse is asking people to leave the API projects alone for now. While some of them have been moved over into the Eclipse side, there’s still a lot that needs to be done before we can really settle in. Changing the APIs directly in the EE4J projects right now is like unpacking that one box of old books while a mostly full moving truck is still waiting outside with the rest of your things. Sure, the bookshelves need to be rearranged, but it’s not high on the priority list, if you know what I’m saying.
Because of the reasons mentioned above, EE4J is trying to push as many projects through under the auspices of the Eclipse Foundation. One of the first up has been Grizzly NIO.
Grizzly NIO is a framework designed to take care scalable server-side applications in Java. Thanks to the Java New I/O API (NIO), developers can easily scale to thousands of users without thread management issues. Grizzly allows developers to build scalable and robust servers using NIO, while still offering extended framework components like Web Framework (HTTP/S), WebSocket, Comet, and more.
Grizzly’s latest stable release was 2.3, but there is an upcoming 3.0 release that should be out soon. If you’re interested in trying it out, Grizzly NIO is available here on GitHub.