Posts Tagged ‘java ee’
Introducing Our Keynote Speakers at OCX 2024
As we approach the Open Community Experience (OCX), scheduled to take place from 22-24 October in Mainz, Germany, my anticipation and excitement continues to build. This event marks a new chapter for our community, with a fresh conference format that I believe will bring even more value to all of us. The focus on collocated events is something I’m particularly enthusiastic about, as it allows us to explore a broader range of topics including automotive and Java, while EclipseCon remains at the heart of this experience.
Whether you’re a regular EclipseCon attendee or joining us from one of the many communities that make up our “community of communities,” I look forward to connecting with you. For me, our flagship conference is more than just an event—it’s a yearly highlight where I get to reconnect with old friends, make new ones, and engage in the meaningful conversations that drive our collective work forward.
I’m honoured to be delivering the keynote on “The State of the Eclipse Foundation” this year. I’ll be sharing key updates, our vision for the future, and how we plan to continue driving innovation in the open source space. As we celebrate the Eclipse Foundation’s 20th anniversary, it’s a pivotal moment for us, and I’m excited to take you along on this journey.
But it’s not just me you’ll hear from. We’ve lined up a stellar group of keynote speakers, each bringing their unique expertise and deep expertise in their respective fields. Prepare to be inspired by some of the brightest minds in the industry:
- Haibo Chen from Huawei will deliver an exciting session titled “Empowering a Connected Intelligent World With OpenHarmony and Oniro.” This talk will explore how OpenHarmony and Oniro, both open source initiatives, are driving the connected intelligent future.
- Cédric Dumont, an extreme sports athlete and base-jumping pioneer, will provide the inspirational keynote “Scaling New Heights: Emerging trends in performance and leadership for thriving as a team in disruption.”
- Ruth Ikegah, an Open Source Program Manager, acclaimed speaker, and GitHub Star, will deliver her keynote “From Local Roots to Global Impact: Building an Inclusive Open Source Community in Africa.” Ruth will highlight how inclusivity fuels innovation and growth within the global open source community.
- Yann Lechelle from Probabl will take the stage with “Eyes Wide Open, AIs Wide Open – Or How to Remain in Control in the Age of AI,” exploring the big picture implications of compute, data, and machine learning, and how we can stay competitive while safeguarding the values that make us human.
- Sarah Novotny, a leading voice in open source, who has guided projects like Kubernetes, OpenTelemetry, NGINX, and MySQL, will present “We Build Software in the Open to Build Trust.” She’ll discuss the need for transparent and collaborative open source software development and its profound economic and societal impact.
- Leandro von Werra, from Hugging Face, will offer insights into the future of LLMs for code and how the BigCode project is paving the way for open and responsible AI-driven development at the session “BigCode: Building Open LLMs for Code”.
And that’s just the beginning. OCX 2024 is packed with sessions, workshops, and networking opportunities designed to spark innovation, collaboration, and growth. Whether you’re deeply involved in open source software or just beginning your journey, there’s something here for everyone.
I’m genuinely excited about what we’ll experience together at OCX 2024. This is our chance to come together, share our knowledge, and set the stage for the future of open source development. Don’t miss the opportunity to save by taking advantage of early bird pricing—register before 7 October 2024.
See you there!
Jakarta EE 10 Brings Java Development Into the Modern Cloud Native Era
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 Contexts and Dependency Injection (CDI) 4.0 includes a new CDI-Lite specification allowing a reflection-free programing model that enables compiling to native by providing build compatible extensions.
- Jakarta RESTful Web Services 3.1 standardizes a Java SE Bootstrap API and support for multipart/form-dat
- Jakarta Security 3.0 supports OpenID Connect for authentication to help developers meet modern web-based security requirements
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.
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.
- 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.
- 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.
- 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.
- 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.
- 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!
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.
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.
| 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.
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!
Life at Eclipse 