Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Posts Tagged ‘java ee

Jakarta EE 10 Brings Java Development Into the Modern Cloud Native Era

leave a comment »

Jakarta EE, a Working Group hosted by the Eclipse Foundation, released Jakarta EE 10 today. 

This achievement was only possible because of a global community of contributors. Congratulations and thank you to everyone who played a part in this release. 

There are many new and innovative features added by the Jakarta EE community.

Jakarta EE 10 Enables Modern, Lightweight Java Applications and Microservices

Let’s start with some of the key updates in Jakarta EE 10 — updates that plant Jakarta EE firmly in the modern era of open source microservices and containers. 

Most prominently, Jakarta EE 10 includes a new profile specification: Jakarta EE Core Profile. The Core Profile includes a subset of Jakarta EE specifications that target the smaller, lightweight runtimes needed for microservices development. This is the first new Profile added to the enterprise Java specifications in over a decade.

In addition, new functionality has been added to more than 20 component specifications. For example:

Jakarta EE 10 also broadens support for annotations so it’s easier to build modularized applications and there’s better integration across component APIs.

Finally, I want to point out that Jakarta EE 10 gives enterprises the flexibility to leverage Java in the way that’s best for their organization. They can:

  • Develop and deploy Jakarta EE 10 applications on Java SE 11 as well as Java SE 17, the most current long-term support (LTS) release of Java SE
  • Take advantage of new features, including the modular system, that were introduced in Java SE 9 and supported in Java SE 11

The Jakarta EE Gamble Is Paying Off

This is all great news for Jakarta EE. But to understand how significant this release is, we need to go back to the Java EE days.

Java EE was the bedrock of application development for the Fortune 1000 for 20 years before it moved to the Eclipse Foundation as Jakarta EE. But the first Jakarta EE releases didn’t add new functionality. Then, Jakarta EE 9 introduced a major breaking change: the move to the jakarta.* namespace.

It’s hard to overstate what a gamble that was. Java EE had been basically backwards-compatible for more than two decades. We asked enterprises to change the fundamentals of applications they’d been relying on for a long time. We asked the enterprise Java ecosystem to re-align their products and opens source projects on a new namespace. Oftentimes, when you try to make such a radical change, your ecosystem says no, it’s too much work. And quite a few people thought the Jakarta EE gamble could fail for exactly that reason. 

But it didn’t. IBM, Red Hat, Payara, Spring, the Apache Tomcat and TomEE projects, and Eclipse Jetty, to name a few, all moved to the new namespace with us. 

Now, with new support for modern microservices architectures and containers, Jakarta EE 10 paves the way for Jakarta EE to drive the innovative, multi-vendor standards needed for the future of our industry. 

Get Involved in the Future of Jakarta EE

The momentum around Jakarta EE 10 is well underway. Eclipse GlassFish has released a compatible implementation, and other enterprises and project teams — including Fujitsu, IBM, Oracle, Payara, Red Hat and Tomitribe — are already working towards certifying Jakarta EE 10 compatible products 

Jakarta EE has an exciting future ahead, and we want everyone to participate and contribute. To learn more, connect with the global community. If enterprise Java is important to your business strategy, join the Jakarta EE Working Group. Learn more about the benefits and advantages of membership here.

Written by Mike Milinkovich

September 22, 2022 at 12:00 pm

Posted in Jakarta EE, Open Source

Tagged with , ,

Introducing the Jakarta EE Specification Process

I am very happy to announce that we are publishing a draft of the Eclipse Foundation Specification Process for community review and feedback. This specification process will be used by Jakarta EE as the new open specification process, replacing the JCP process previously used for Java EE. It is also expected that this new process will be of interest to other Eclipse working groups.

We are really looking forward to your feedback, which you can do via the Jakarta EE Community mailing list (preferred), or on the document comments.  The feedback provided will be used as input to finalizing a first version of the specification process and its adoption by Jakarta EE and other working groups at the Eclipse Foundation.  

As you are reviewing this draft specification process, please keep in mind the following key points about the approach that was taken by the Specification Committee.

  1. We want to design a specification process to replace the JCP. While there are many differences with the JCP, the key objective was to make the whole process as lightweight as possible.
  2. We want the specification process to be as close to open source development as possible. This is actually not a trivial exercise, as by its very nature drafting specifications is a somewhat different process.
  3. This is the Eclipse Spec Process, so we want to reuse the Eclipse Development Process wherever possible, and we want to ensure that the general flow and tone of the EDP is followed.
  4. We want to create a process that allows code-first development. Specifically, we want to enable a culture where experimentation can happen in open source and then have specifications be based on those experiences.
  5. We want the specifications that result from this process to be as high quality as possible. In particular, this means that we need to take care of the intellectual property flows, and to protect the community’s work from bad actors. This requirement manifests as two fundamentally important differences from the EDP:
    • Specification Committee approval is required for releases from Spec Projects, in addition to the normal PMC approval; and
    • We introduce the notion of “Participants” who are committers who represent specific member companies on a Spec Project. This is necessary to ensure that the IP contributions (particularly patents) from companies are properly captured by the process.

All of us at the Eclipse Foundation would like to recognize the tireless efforts of the members of the Specification Committee. A lot of hard work has gone into this document, and it’s very much appreciated. We are certain that Jakarta EE, and many other Eclipse technologies, benefit from the thoughtful efforts of this Committee.  In particular, we would like to thank the following Specification Committee members and alternates:

Fujitsu: Kenji Kazumura​, Mikel DeNicola
IBM: Dan Bandera​, Kevin Sutter
Oracle: Bill Shannon​, Ed Bratt​, Dmitry Kornilov
Payara: Steve Millidge​, Arjan Tijms
Red Hat: Scott Stark, Mark Little
Tomitribe: David Blevins​, Richard Monson-Haefel
PMC Representative: Ivar Grimstad
Elected Members: Alex Theedom, Werner Keil​

I also wish to recognize Tanja Obradovic and Wayne Beaton from the Eclipse Foundation team who have driven the process throughout – many thanks to you both!

Written by Mike Milinkovich

October 16, 2018 at 3:18 pm

Posted in Foundation, Jakarta EE, Open Source

Tagged with , ,

And the Name Is…

We are happy to announce that the new name for the technology formerly known as Java EE is….[insert drumroll]… Jakarta EE.

Almost 7,000 people voted in our community poll, and over 64% voted in favour of Jakarta EE. Thanks to everyone who voted, blogged, or tweeted! This has been quite the process, and we are all really happy with the community support throughout.

naming_poll_results

As we have been making progress on migrating Java EE to the Eclipse Foundation there have been a lot of moving pieces and parallel threads, especially around naming. Thankfully, we think we are getting to the end of this, and the names at least are starting to sort themselves out.  We have prepared this handy table to assist with the translation from the old names to the new names.

Eclipse Jakarta Working Group

Old Name New Name
Java EE Jakarta EE
Glassfish Eclipse Glassfish
Java Community Process (JCP) [*] Jakarta EE Working Group (Jakarta EE)
Oracle development management Eclipse Enterprise for Java (EE4J)
Project Management Committee (PMC)

Note that permission for products to formally use the Jakarta EE trademark will be dependent upon passing a as-yet-to-be-defined compatibility program run by EE.next. However, as of today, it is preferred that when you are generically referring to this open source software platform that you call it Jakarta EE rather than EE4J. EE4J, the Eclipse Top-level project,  is the only name we’ve had for a couple of months, but as we at least tried to make clear, that was never intended to be the brand name.

Update: Fixed a typo plus the formatting of the Glassfish row in the translation table.
Update 2: [*] To be clear, the Java Community Process will continue to exist and to support the Java SE and ME communities. However, it will not be the place where Jakarta EE specifications will be developed.
Update 3: Corrected the name of the working group from EE.next to Jakarta EE.

Written by Mike Milinkovich

February 26, 2018 at 2:00 pm

Posted in Foundation

Tagged with , ,

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