Posts Tagged ‘Java’
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.
AQAvit Brings Quality Assurance to Adoptium Marketplace and Java Ecosystem
The launch of the Adoptium Marketplace on May 26 is exciting news for the millions of developers, researchers, and organizations who rely on TCK-tested compatible Java runtimes. As noted in the announcement, by providing a vendor neutral home for the OpenJDK ecosystem, the marketplace makes it easier than ever to access Java SE-conformant binaries necessary for cloud native and enterprise deployments.
But there’s more to the story. For a long time, compatibility has been the name of the game when it came to Java implementations. The Adoptium Marketplace has been set up to take the Java ecosystem to the next stage of its development.
That’s where Eclipse AQAvit comes in. It brings quality assurance metrics into the marketplace, so that the Java community can begin to select binaries not just based on compatibility but on quality.
Eclipse AQAvit Brings Quality Assurance to Java
Everything in the marketplace will be compatible with the relevant version of the Java SE Technology Compatibility Kit (TCK).
But TCK compatibility doesn’t tell you anything about the quality of the implementation. In recent years, the number of OpenJDK-based runtime distributions has absolutely exploded. And although many vendors maintain their own release quality tests, OpenJDK distros have historically not been built to any consistent quality standard. It has become increasingly clear that the Java ecosystem needs a consistent, multi-vendor definition of quality.
Ensuring high-quality binaries are ready for production deployment is crucial for the Adoptium Marketplace. The AQAvit project team compiled tens of thousands of tests and built a few of their own to produce a comprehensive, systematic way of ensuring the quality of runtimes available. The AQAvit Quality Verification Suite covers a broad set of requirements, ensuring binaries provide superior:
- Performance
- Security
- Resilience
- Endurance
They also ensure that the binaries can pass a wide variety of application test suites and can verify new functionality during runtime development. That’s what’s unique about the Adoptium Marketplace: it provides peace of mind knowing that the binaries are not only compatible but will actually meet the demanding requirements of your enterprise applications.
Contributing Helps Ensure AQAvit Meets Your Needs
And in the spirit of open source, you give a little to get a lot.
Many of the founding members of the Adoptium Working Group are Java developers and vendors, including Alibaba Cloud, Azul, Huawei, IBM, iJUG, Karakun AG, Microsoft, New Relic, and Red Hat. The marketplace enables working group members to promote their Java SE compatible releases verified to Eclipse AQAvit’s quality criteria. Their membership helps support the cloud-based infrastructure that drives Adoptium’s efficiency as a shared community project. In other words, the working group collaborates to create and provide access to high-performance, enterprise-caliber, cross-platform, open source-licensed, and Java-compatible binaries of OpenJDK builds, through the marketplace.
Contributing to the AQAvit project is one of the best ways to ensure access to runtimes that meet specific needs. We encourage Java community members to get involved and contribute additional tests to cover the use cases their applications require. They’ll be incorporated in the AQAvit test suite, so every binary going forward will have to meet that standard. This way enterprises and developers can be confident any AQAvit-verified binaries they use will function as needed.
Security Updates for Java
Quality assurance is a big part of what makes the Adoptium Marketplace unique, but it’s not the whole picture. Security fixes are also an important focus.
Once upon a time, you could count on getting security fixes for old versions of Java for a long time. After all, if you’ve deployed a set of applications on a version, you’re probably going to want to use it for a long time.
That’s no longer the case elsewhere. But all the distributions in the Adoptium Marketplace will be kept up to date with the latest security patches or those patches will be backported to older LTS versions. This way you can be sure that your applications are secure, no matter which version of Java you’re running them on. Of course, this goes for new versions of Java too.
Everything Users Need in One Place
The Adoptium Marketplace brings together all these elements — quality assurance, adaptability to community needs, security updates for every version, sustainability — into a one-stop shop for binaries. Ultimately, this delivers five key assurances to end users:
- The binary has been tested and is compatible with the relevant version of the Java SE TCK
- The binary was built in accordance with open source principles
- The binary has been fully verified using the AQAvit quality verification criteria, having passed through multiple tests to ensure it meets industry quality standards
- The binary is as secure as possible, with the latest security updates included
- The binary is brought to you by a vendor committed to supporting and participating in a multi-vendor, vendor-neutral collaboration
If your organization is considering participating in the Adoptium Working Group, have a look at the Charter and Participation Agreement. Or if you have questions, email us at membership@eclipse.org.
The Eclipse IDE Working Group Celebrates Its First Anniversary
Today we celebrate the one year anniversary of the Eclipse IDE Working Group. A year ago, the Eclipse Foundation launched this Working Group focused on the Eclipse IDE and the Eclipse Simultaneous Release (SimRel). We would like to share some of our successes since the launch of the Working Group in April 2021.
Highlights
- 20 Years of the Eclipse IDE: 2021 was a momentous year for the Eclipse IDE, as we celebrated its 20 year anniversary!
- Welcome Ed! Ed Merks joined us as a SimRel Architect and Release Engineer. Ed’s first set of tasks included preparing PGP signing support for the 2022-06 release and mapping out the project dependencies.
- Productive collaboration Our collaboration with the Planning Council has been very effective. We have identified the top issues as outlined by the Planning Council and have a plan to address them.
PGP: A Community Success Story
A great community success story for the Eclipse IDE Working Group is the delivery of a fully-functional, secure PGP implementation for Eclipse 4.23 (SimRel 2022-03). This enhancement augments Eclipse’s existing security support which is based on jar signing. Jar signing has the significant drawback that artifacts originating from external dependencies must be modified in order to sign them, i.e., jar signatures are intrinsic to the artifact. In contrast, PGP signatures are extrinsic to the artifact and have long been used in Maven repositories to provide certification of origin. Eclipse’s PGP support facilitates significantly streamlined consumption of Maven-based artifacts by Eclipse projects, making it easier for our community to exploit and deliver the latest and greatest libraries with each quarterly simultaneous release.
The initial proof-of-concept PGP implementation was contributed by Mickael Istria. In combination with Mickael’s on-going participation, along with Christoph Läubrich’s technical insights, the working group has helped to harden the PGP implementation to industrial-strength quality for the SimRel 2022-03 delivery. Even the existing support for jar signing has been improved, as users can now easily save trusted X.509 certificates to avoid repeated trust prompts as is typical with self-signed certificates. Issue 11 provides a detailed track record of all the activities around PGP signing during the 2022-03 release cycle as well as additional background information.
With this groundwork in place, our community as a whole can exploit PGP signing for broader adoption in the Eclipse 4.24 (SimRel 2022-06) delivery this coming June.
Planning Council’s Top 3 Items
The Planning Council plays an important role in the Eclipse IDE WG. The Planning Council can be seen as the “technical” arm of the WG. At the beginning of the first year, under the leadership of Mélanie Bats, the Planning Council was tasked by the Steering Committee to identify the top issues affecting the successful release and adoption of the Eclipse IDE as a platform and a product.
After much brainstorming and debate the Planning Council recommended the “top three” items to the Steering Committee to focus on:
- The “Bus Factor“, particularly of the release engineering processes of the Simultaneous Release (SimRel).
- Identifying individual project risks, for example identifying which projects contributing to the SimRel are under-resourced and understanding which downstream projects are affected.
- Updating the graphical layer Eclipse where it is lagging behind operating system changes, for example improving dark mode, better operating system and web browser integration.
The Steering Committee took these items and translated them to action points that are now being carried out and has allocated a substantial portion of the IDE WG’s budget to improving these common parts of the Eclipse IDE. The highlights of this work include:
- Hiring Ed Merks as the SimRel release engineer.
- Ed has also found time to start mapping out the incredibly complicated dependency graphs between the dozens of different projects contributing to the SimRel to better understand the impact of any particular project discontinuing participation and to fully understand the dependency chain of each bundle in the SimRel repository.
- The Eclipse Foundation has created new guidelines for funding work such as the graphical layer improvements. This is the most recent action point and already some bugs are being fixed under this program.
One year into the Eclipse IDE WG and Jonah Graham is now the chair of the Planning Council. The Planning Council is pleased to see some concrete actions taking place under the new Working Group. The structures and processes in the Working Group have progressed well and additional funding of the IDE WG will see direct improvements in the quality, stability and adoption of the Eclipse IDE.
Engage in the Working Group
We still have much to do! If you are interested in joining us and supporting the development of the Eclipse IDE technology stack, improving the user experience of the platform, and making it more attractive for organisations, let us know. We welcome the opportunity to speak with everyone who wants to help shape the future of the Eclipse IDE.
The resources funded by the IDE Working Group members are really paying dividends for our community, both for the producers and for the consumers. If you’re a consumer, please consider investing in our community’s ongoing success by supporting the Eclipse IDE with funding, contributions, new ideas, new points of view, and by getting directly involved in development efforts. Better funding enables us to achieve more, and more hands make the work lighter.
If you are interested in becoming a Working Group member, you can get in touch with us by completing the membership form or by sending an email to the Membership Coordination Team. If you are interested in becoming a sponsor, let us know.
Stay In Touch
We love exchanging ideas, so if you have any questions or would like to know more about what we do here, connect with us! You can also join our meetings to find out more about what we’re up to. They are open to the community and take place every 2 weeks from 2:30pm to 3:30pm (CET) on Tuesdays. Or you can contact a member of the steering committee, we’re always happy to talk to you.
Meet Adoptium: Open Source Java Runtimes for Enterprises
Today we announced the creation of the Adoptium Working Group, whose mission is to bring high-quality, open source Java runtimes to millions of developers building the next generation of enterprise applications.
Adoptium was created in collaboration with the AdoptOpenJDK Technical Steering Committee, and supports the Eclipse Adoptium top-level project. The working group provides the vendor-neutral governance, infrastructure, marketing, community building, and developer advocacy work needed to ensure timely releases of Java runtimes and strengthen the project’s community.
The Adoptium project continues the work initiated by the AdoptOpenJDK community. The project gives developers a trusted location where they can download fully compatible, high-quality distributions of Java runtimes based on OpenJDK source code. In a few short years AdoptOpenJDK became the leading provider of OpenJDK-based binaries used to power production workloads in embedded systems, desktops, traditional servers, modern cloud platforms, and mainframes. Adoptium will continue that mission as a vendor-neutral, multi-vendor initiative hosted at the Eclipse Foundation. We appreciate the trust that the AdoptOpenJDK TSC has placed in us as we become the new stewards of this amazing community.
The founding members of the working group include numerous Java developers, as well as vendors such as Alibaba Cloud, Huawei, IBM, iJUG, Karakun AG, Microsoft, New Relic, and Red Hat. This strong participation clearly shows the value the industry sees in transitioning the widely adopted AdoptOpenJDK technologies and community to the Eclipse ecosystem. I would also like to recognize the efforts of Oracle in negotiating a TCK license agreement with us in support of this initiative.
Benefits for the Global Java Ecosystem
Developers and enterprises need a dependable source of open source, compatible Java runtimes that are fully supported with timely patches and updates. AdoptOpenJDK was created in 2017 to provide a community-based solution to this requirement, delivering open build and test systems for OpenJDK across multiple platforms, and delivering high quality binaries for use. Developers responded enthusiastically, downloading more than 240 million Java binaries from AdoptOpenJDK.
Moving the AdoptOpenJDK technologies and community to the Eclipse Foundation benefits the AdoptOpenJDK community and the many members of the global Java ecosystem:
- The AdoptOpenJDK community can leverage our governance framework and intellectual property services, as well as our developer advocacy, marketing, legal, and hosting capabilities, to help ensure the AdoptOpenJDK initiative and community continue to flourish. The community can strengthen its vendor independence, while maintaining a strong relationship with existing sponsors and the Java community as a whole.
- Developers and enterprises in the Java ecosystem have reliable access to fully compatible Java runtimes for hybrid cloud and multi-cloud enterprise development.
Adoptium complements the other Java-based projects already hosted at the Eclipse Foundation, including the Jakarta EE and MicroProfile specification communities, and open source projects such as Eclipse GlassFish, Eclipse Jetty, and Eclipse Vert.x.
I want to thank everyone who was involved in establishing the Adoptium Working Group. I also want to welcome everyone from the AdoptOpenJDK community to the Eclipse Foundation, and encourage you to continue building on the character and spirit of your great community.
Get Involved in Adoptium
There are a few different ways to get involved in the Adoptium community at the Eclipse Foundation:
- Join the Adoptium Working Group. For details about working group governance and membership, read the Adoptium Working Group Charter and Participation Agreement.
- Explore the Eclipse Adoptium top-level project, and its sub-projects, Eclipse AQAvit and Eclipse Temurin.
- Join the Eclipse Adoptium project mailing list.
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!
Life at Eclipse 