Life at Eclipse

Musings on the Eclipse Foundation, the community and the ecosystem

Archive for the ‘Jakarta EE’ Category

Top Trends in the Jakarta EE Developer Survey Results

Our annual Jakarta EE Developer Survey results gives everyone in the Java ecosystem insight into how the cloud native world for enterprise Java is unfolding and what the latest developments mean for their strategies and businesses. Here’s a brief look at the top technology trends revealed in this year’s survey.

For context, this year’s survey was completed by almost 950 software developers, architects, and decision-makers around the world. I’d like to sincerely thank everyone who took the time to complete the survey, particularly our survey partners, Jakarta EE Working Group members Fujitsu, IBM, Jelastic, Oracle, Payara, Red Hat, and Tomitribe, who shared the survey with their communities. Your support is crucial to help ensure the survey results reflect the viewpoints of the broadest possible Java developer audience.

Jakarta EE Continues to Deliver on Its Promise

Multiple data points from this year’s survey confirm that Jakarta EE is fulfilling its promise to accelerate business application development for the cloud.

As in the 2020 survey results, Jakarta EE emerged as the second-place cloud native framework with 47 percent of respondents saying they use the technologies. That’s an increase of 12 percent over the 2020 survey results, reflecting the industry’s increasing recognition that Jakarta EE delivers important strategic and technical benefits.

Almost half of the survey respondents have either already migrated to Jakarta EE or plan to within the next six to 24 months. Together, Java EE 8, Jakarta EE 8, and Jakarta EE 9 are now used by 75 percent of survey respondents. And Jakarta EE 9 usage reached nine percent despite the fact the software was only released in December 2020.

With the rise of Jakarta EE, it’s not surprising that developers are also looking for faster support from Java EE/Jakarta EE and cloud vendors.

Microservices Usage Continues to Increase

Interestingly, the survey revealed that monolithic approaches are declining in favor of hybrid architectures. Only 18 percent of respondents said they’re maintaining a monolithic approach, compared to 29 percent who have adopted a hybrid approach and 43 percent who are using microservices.

A little over a year ago, monolithic implementations were outpacing hybrid approaches, showing just how quickly the cloud native Java world is evolving. In alignment with these architectural trends, MicroProfile adoption is up five percent over last year to 34 percent.

Download the Complete Survey Results

For additional insight and access to all of the data collected in our 2021 Jakarta EE Developer survey, we invite everyone to download the survey results.

Written by Mike Milinkovich

September 14, 2021 at 7:00 am

Posted in Jakarta EE

Jakarta EE 9.1 Accelerates Open Source Enterprise Java

Just a little more than five months ago, I was sharing news about the Jakarta EE 9 platform release. Today, I’m very pleased to tell you that the Jakarta EE Working Group has released the Jakarta EE 9.1 Platform and Web Profile specifications and related Technology Compatibility Kits (TCKs). Congratulations and thanks to everyone in the Jakarta EE community who made this release possible.

The accelerated innovation we’re seeing in Jakarta EE, and the growing number of compatible implementations, are clear signs that enterprise Java is experiencing a renaissance.

Enterprises Have New Agility to Develop and Evolve Java Applications

Jakarta EE 9 opened the door to the next era of innovation using cloud native technologies for Java by delivering the “big bang” namespace change to jakarta.*. 

Jakarta EE 9.1 takes that rejuvenation to the next level. The release includes a number of updates and new options, and is compatible with Java SE 11, which is seeing increasing adoption. The 2020 Jakarta EE Developer Survey revealed that 28 percent of respondents were using Java SE 11, compared to 20 percent of respondents in 2019.

Together, the advances in Jakarta EE 9.1 give enterprises the flexibility to make more choices, and to mix and match technologies as needed to meet their unique application development and migration requirements. With Jakarta EE 9.1, enterprises can:

  • Develop and deploy Jakarta EE 9.1 applications on Java SE 11, the most current LTS release of Java SE, as well as Java SE 8
  • Leverage Java SE 11 features that have been added since Java SE 8 in their Jakarta EE 9.1 applications 
  • Take advantage of new technologies that support Java SE 11 in their Jakarta EE 9.1 applications
  • Move existing Jakarta EE 9 applications to Java SE 11 without changes
  • Migrate existing Java EE and Jakarta EE 8 applications to Jakarta EE 9.1 using the same straightforward process available for migration to Jakarta EE 9

With a variety of paths to choose from, every enterprise can develop and migrate Java applications in a way that aligns with their technical objectives and business goals.

There Are Already Five Jakarta EE 9.1-Compatible Applications

As we announce Jakarta EE 9.1, five products from global leaders in the Java ecosystem have already been certified as compatible with the release:

  • IBM’s Open Liberty
  • Eclipse Glassfish
  • Apache TomEE
  • Red Hat’s Wildfly
  • ManageCat’s ManageFish

These implementations are proof positive the Java ecosystem recognizes the value Jakarta EE brings to their business and the technologies they develop.

The rapid technology adoption we’re seeing with Jakarta EE is thanks to the openness of  the Jakarta EE Specification Process. This simplified process dramatically lowers the barrier to entry, making it much easier for organizations of all sizes to have their products certified as a compatible implementation and leverage the Jakarta EE brand for their own business success.

The number of compatible implementations across Jakarta EE releases is growing all the time, so be sure to check the Jakarta EE compatible products webpage for the latest list. To be listed as a Jakarta EE-compatible product, follow the instructions here.

Learn More About Jakarta EE 9.1 and Get Involved

To learn more about the Jakarta EE 9.1 release contents, read the Jakarta EE 9.1 release plan and check out the specifications.

As the focus shifts to Jakarta EE 10, the Jakarta EE Working Group and community welcome all organizations and individuals who want to participate. To learn more and get involved in the conversation, explore the benefits of membership in the Jakarta EE Working Group and connect with the community.

Written by Mike Milinkovich

May 26, 2021 at 7:05 am

Posted in Foundation, Jakarta EE

On Patents and Specifications

We’ve been fielding a number of questions lately about the intersection of our spec process and patents. A couple of these community discussions have gone off in directions that are off target, factually incorrect, or both. Therefore, the purpose of this short FAQ is to explain the patent license options provided by the Eclipse Foundation Intellectual Property Policy for use by specifications developed by specification projects under the Eclipse Foundation Specification Process (EFSP). 

Disclaimer: This is not legal advice. I am not a lawyer. It has not been reviewed by counsel. Consult your own attorney. In addition, this note does not form part of any official Eclipse Foundation policy or process, but rather is provided for informational purposes only to aid those involved in our specification projects to better understand the EFSP and the choices available. I’ll update the content as needed.

One important point to keep in mind when reading this: we believe that the EFSP fully complies with the Open Standards Requirement for Software established by the Open Source Initiative. In other words, the EFSP is designed specifically to be open source friendly.  

Why do specifications require patent licenses?

The purpose of every specification is to stimulate the development of implementations. These implementations may be derived from open source code maintained at the Eclipse Foundation or elsewhere, or they may be independently developed. They may be made available under open source licenses or proprietary. In order to facilitate and encourage these implementations, all specification processes provide some notion of patent licenses from the parties involved in developing the specifications.

What types of patent licenses are used by various specification organizations?

There are a wide variety of specification patent license options available from various sources. 

Some terms that you may hear are:

  • FRAND means fair, reasonable, and non-discriminatory licenses. This means that before you can implement the specification you are required to obtain a license from the patent holders who developed the specification. FRAND is generally considered to be antithetical to open source development, as it requires permission and money to implement a specification or potentially even to use an implementation of such a specification.
  • FRAND-Z is FRAND where the cost of the license is set to zero. Note that although this removes the cost concerns of FRAND, permission may still be required for use and/or implementation. 
  • RF or royalty-free provides a priori royalty-free licenses from the participants developing the specifications to downstream users and implementers. This is considered a best practice for enabling open source implementations of a specification. All Eclipse Foundation specifications are developed on a royalty-free basis. 
  • Non-assert is another legal mechanism which provides a result effectively similar to royalty-free. A non-assert says that a patent holder will not assert their patent rights against an implementer or user. 

Do these licenses mean that an implementer or user can never be sued for patent infringement?

No. The patent licenses are intended to ensure that an implementer or user doesn’t need to be worried about being sued by the parties involved in developing the specifications. It does not provide protection from uninvolved third parties who may believe they have intellectual property rights applicable to the specification. 

Note that the above implies that it is in the interests of the entire community and ecosystem that many participants (particularly patent-owning participants) be involved in developing the specifications. It also explains why it is in the best interest of the community that all participants in the specification process have signed agreements in place documenting their commitment to the patent licensing under the EFSP. 

What patent licenses are granted by the EFSP?

The patent licenses provided via the EFSP apply to all downstream implementations of Final Specifications, including independent implementations. They cover all patents owned by each Participant in the specification project that are essential claims needed by any implementer or user of the specification. Note that the licenses cover the entire specification, not just to the parts of the specification that a participant may have contributed to. We provide our specifications two options for patent licenses: the Compatible Patent License and the Implementation Patent License. The differences between those two are explained below.

But my open source license already has a patent license in it. Why do I need more than that?

The patent licenses provided in open source licenses such as APACHE-2.0 grant a license for contributor-owned patents which apply to their contribution either alone or as combined with the work. The patent license is only to that program/implementation. Note that the APACHE-2.0 patent license  “…applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work…”. Relative to the EFSP, such grants are deficient in both scope (applies only to their contributions) and target (applies only to that implementation). 

What is the difference between the two patent license options provided by the EFSP?

The only difference between the Compatible Patent License and and the Implementation Patent License is the timing of when the patent license grant comes into effect. In the Compatible Patent License, the license grant only happens when the implementation has demonstrated that it is fully compatible with the specification by passing the relevant TCK. The Implementation Patent License provides immediate patent licenses to all implementers, even to partial or work-in-progress implementations. The first choice emphasizes the importance of compatibility. The latter choice emphasizes the importance of open development. Both are valuable options available to Eclipse specification projects. 

Is one of these patent license options better than the other?

No. There are perfectly valid reasons why a specification project may choose either one of these options. Both options provide downstream implementers of the specifications royalty-free licensing to the patents of the participants who developed the specification. The Implementation Patent License favours open development as there is less concern that a work-in-progress implementation does not have access to the patent licenses. Where there is a strong emphasis on desiring compatibility across all implementations, the Compatibility Patent License is a valid choice. Another scenario is a small company with few patents. They may also prefer the Compatibility Patent License to ensure that they’re not providing an open-ended patent license to any competitors who may only partially implement the spec. 

Does the Eclipse Foundation recommend either of these two choices?

As an open source foundation our default preference is the Implementation Patent License as we always want to promote open collaborative development. But as described above, there are perfectly valid reasons why a specification project may prefer the Compatibile Patent License. Ultimately it is up to each working group to make their own selection.

I’ve read the EFSP and I don’t see anything about patent licenses. WUWT?

The patent licenses are provided in the Eclipse Foundation Intellectual Property Policy. A future version of the EFSP will make this clearer.

Is the Eclipse Foundation itself granted any licenses to patents? 

No. The Eclipse Foundation itself does not acquire any patent rights in the specifications. The patent licenses are granted from the participating patent owners directly to implementers and users of those specifications. More specifically, the patent license grants are “… to everyone to make, have made, use, sell, offer to sell, and import…” implementations of the specifications.

(Updated on 2021-07-05 to add two FAQ entries.)

Written by Mike Milinkovich

May 13, 2021 at 3:20 pm

Jakarta EE Is Taking Off

With the results of the 2020 Jakarta EE survey and the initial milestone release of the Jakarta EE 9, it’s clear the community’s collective efforts are resonating with the global Java ecosystem.

Before I get to the survey results, I want to say a huge thank you to everyone who took the time to participate in the survey. We received nearly 2,200 responses from software developers, architects, and decision-makers around the world — an increase of almost 20 percent over last year’s survey. With your insight, we’ve gained a clear and comprehensive view of enterprise Java strategies and priorities globally, which in turn we are freely sharing with the ecosystem.

Jakarta EE Adoption and Compatible Implementations Are on the Rise

Less than a year after its initial release, Jakarta EE has emerged as the second-place cloud native framework with 35 percent of respondents saying they use it. While the Spring and Spring Boot frameworks are still the leading choices for building cloud native applications, their usage share dropped 13 percent to 44 percent in the 2020 survey results.

Combined, Java EE 8 and Jakarta EE 8 hit the mainstream with 55 percent adoption. Jakarta EE 8 was responsible for 17 percent of that usage, despite only shipping for the first time in September 2019. This is truly significant growth.

We’re also seeing a strong uptick in Jakarta EE 8 compatible products. Companies including IBM, Red Hat, Payara, Primeton, TmaxSoft, and Apusic now have Jakarta EE 8 Full Platform compatible products. Since January 2020, we’ve had four new Full Platform compatible implementations and one new Web Profile compatible implementation. In addition to Eclipse GlassFish 5.1, this brings Jakarta EE 8 adoption to 12 compatible products. This is an outstanding achievement for the Jakarta EE community to have more full platform compatible products in 8 months than Java EE 8 had in over 2 years. You can see the complete list here.

You can also expect to see additional compatible implementations in the coming months as more applications are passing Technology Compatibility Kit (TCK) tests and are well on their way to becoming certified as Jakarta EE 8-compatible products.

Architectural Approaches Are Evolving

This year’s Jakarta EE survey also showed a slight drop in the popularity of using a microservices architecture for implementing Java systems in the cloud compared to last year. At the same time, use of monolithic architectures for implementing Java systems in the cloud nearly doubled since last year’s survey and is now at 25 percent.

These results may indicate that companies are pragmatically choosing to simply “lift and shift” existing applications to the cloud instead of rearchitecting them as microservices.

Interestingly, the survey also indicated the Jakarta EE community would like to see better support for microservices in the platform. When you combine this fact with the rise of Jakarta EE, it’s reasonable to believe developers may be starting to favor vendor-neutral standards for building Java microservices over single-vendor microservices frameworks.

The Industry Is Moving to the New Jakarta EE Namespace

The support we’re seeing for the adoption of the new namespace in Jakarta EE 9 reinforces the value the industry sees in Jakarta EE. Technology leaders are already investing to ensure their software supports the Jakarta EE 9 namespace changes and others have indicated they will do the same. Some of these implementations include:

  • Eclipse GlassFish 6.0 milestone release is available to download
  • Jetty 11.0.0-alpha0 milestone release is available to download
  • Apache Tomcat 10.0 M6 milestone release is available to download
  • Payara Platform 6 milestone release coming in Q4 2020
  • OpenLiberty 20.0.0.7 Beta release is available with basic Web application support to download
  • Apache TomEE 9.0 milestone release using Eclipse Transformer project tools is available to download
  • WildFly 21 is planning a milestone release for fall 2020
  • Piranha Micro p20.6.1 milestone release is available to download.

While the Jakarta EE 9 tooling release doesn’t include new features, it’s a very important and necessary step on the road to Jakarta EE 10 and the next era of innovation using cloud native technologies for Java. With the full Jakarta EE 9 release in fall this year, Jakarta EE will be ideally positioned to drive true open source, cloud native innovation using Java.

Diversity, Achieved

One of the items that I am particularly happy about is the achievement of establishing Jakarta EE as a vendor-neutral, community-led technology platform. When we started the process of moving Java EE from Oracle to the Eclipse Foundation there were some who doubted that it could be accomplished successfully. The numbers tell the story: Oracle’s contributions are still leading the pack at 27%, but the community-at-large is

JakartEEDev v2
now over 40%. Contributions from our other members are led by Payara, VMware (Pivotal), Red Hat, and IBM. Based on these results, it is clear that Jakarta EE has truly achieved its original objective of becoming a vendor-neutral, community-led industry initiative. A lot of people worked very hard to achieve this, and I’m thrilled by the results.

Discover Jakarta EE

Here are three ways to learn more about Jakarta EE and understand why it’s gaining mainstream adoption so quickly:

  • Join the community at the Jakarta EE 9 Milestone Release Virtual Party and networking opportunity on Tuesday, June 23 at 11:00 a.m. EDT. To register for the event, click here.
  • Find out more about the Jakarta EE 9 milestone release here.
  • Review the complete 2020 Jakarta EE Survey results here.

Edit: Reflect IBM’s contributions
Edit #2: Add link to Apache TomEE download

Written by Mike Milinkovich

June 23, 2020 at 7:03 am

Add Your Voice to the 2020 Jakarta EE Developer Survey

Our third annual Jakarta EE Developer Survey is now open and I encourage everyone to take a few minutes and complete the survey before the April 30 deadline. Your input is extremely important.

With your feedback, the entire Java ecosystem will have a better understanding of the requirements, priorities, and perceptions in the global Java developer community. This understanding enables a clearer view of the Java industry landscape, the challenges Java developers are facing, and the opportunities for enterprise Java stakeholders in the cloud native era.

The Jakarta EE Developer Survey is one of the Java industry’s largest developer surveys. Since the survey’s inception, we’ve received thousands of responses from developers around the world, including 1,700 responses in 2019 — a clear indication the Java developer community recognizes the value of the survey results.

Last year, we were able to share critical insight into the state of cloud native innovation for enterprise Java development globally, including expected growth rates for Java apps in the cloud as well as leading architectures, applications, and technologies. We were also able to share the community’s top priorities for Jakarta EE.

This year, we’re asking developers to tell us more about their next steps for Java and cloud native development and their choices for architectures, technologies, and tools as cloud native resources for Java mature.

With this updated information, platform vendors, enterprises, and individual developers in the Java ecosystem will have a better understanding of how the cloud native world for enterprise Java is unfolding and what that means for their strategies and businesses. And the Jakarta EE community at the Eclipse Foundation will have a better understanding of the community’s top priorities for future Jakarta EE releases.

The Jakarta EE Developer Survey is your opportunity to add your voice to the global Java ecosystem and we’re counting on our entire community to help us gain the broadest possible view of the state of cloud native technologies in the context of enterprise Java. Best of all, this year we’ve organized the survey so it takes less than 10 minutes to complete!

To access the survey, click here.

Written by Mike Milinkovich

April 7, 2020 at 8:02 am