Archive for May 2019
The Cloud Native Imperative — Results from the 2019 Jakarta EE Developer Survey
The results of the 2019 Jakarta EE Developer Survey are out. Almost 1,800 Java developers from around the world have spoken. Taken together with the engagement and response to my recent posts on the future of Jakarta EE (see my latest blog here), the survey makes clear the developer community is focused on charting a new course for a cloud native future, beginning with delivering Jakarta EE 8. The Java ecosystem has a strong desire to see Jakarta EE, as the successor to Java EE, continue to evolve to support microservices, containers, and multi-cloud portability.
Organized by the Jakarta EE Working Group, the survey was conducted over three weeks in March 2019. Just like last year (see the 2018 results here), Jakarta EE member companies promoted the survey in partnership with the London Java Community, Java User Groups, and other community stakeholders. Thank you to everyone who took the time to participate. Access the full findings of the survey here.
Some of the highlights from this year’s survey include:
- The top three community priorities for Jakarta EE are: better support for microservices, native integration with Kubernetes (tied at 61 percent), followed by production quality reference implementations (37 percent). To move mission-critical Java EE applications and workloads to the cloud, developers will need specifications, tools, and products backed by a diverse vendor community. Jakarta EE Working Group members have committed to deliver multiple compatible implementations of the Jakarta EE 8 Platform when the Jakarta EE 8 specifications are released.
- With a third of developers reporting they are currently building cloud native architectures and another 30 percent planning to within the next year, cloud native is critically important today and will continue to be so;
- The number of Java applications running in the cloud is projected to substantially increase, with 32 percent of respondents expecting that they will be running nearly two-thirds of their Java applications in the cloud within the next two years;
- Microservices dominates as the architecture approach to implementing Java in the cloud, according to 43 percent of respondents;
- Spring/Spring Boot again leads as the framework chosen by most developers for building cloud native applications in Java;
- Eclipse Microprofile’s adoption has surged, with usage growing from 13 percent in 2018 to 28 percent today;
- Java continues to dominate when it comes to deploying applications in production environments. It comes as no surprise that most companies are committed to protecting their past strategic investments in Java.
Once again, thanks to everyone who completed the survey and to the community members for their help with the promotion.
Let me know what you think about this year’s survey findings. We are open to suggestions on how we can improve the survey in the future, so please feel free to share your feedback.
Frequently Asked Questions About Jakarta EE 8
I’d like to thank the community for the level of engagement we’ve seen in response to my post from last week. This post, which again represents the consensus view of the Jakarta EE Steering Committee, answers some questions about Jakarta EE 8, which is planned as the initial release of Jakarta EE, and is intended to be fully compatible with Java EE 8, including use of the javax namespace. We thought it would be useful to reiterate the messages we have been delivering about this release.
Note that this post is not about future Jakarta releases where the namespace will be changed. There is a vigorous discussion going on right now on the jakarta-platform-dev@eclipse.org list (archive), so if you are interested in that topic, I would suggest you participate there. We expect that it will be about a month before the Jakarta EE Spec Committee will determine the next steps in the Jakarta EE roadmap.
Will Jakarta EE 8 break existing Java EE applications that rely upon javax APIs?
No, Jakarta EE 8 will not break existing existing Java EE applications that rely upon javax APIs. We expect Jakarta EE 8 to be completely compatible with Java EE 8. We expect Jakarta EE 8 to specify the same javax namespace, and the same javax APIs and the same behavior as is specified in Java EE 8. We expect that implementations that pass the Java EE 8 TCKs will also pass the Jakarta EE 8 TCKs, because the Jakarta EE 8 TCKs will be based on the same sources as the Java EE 8 TCKs. Jakarta EE 8 will not require any changes to Java EE 8 applications or their use of javax APIs.
What will Jakarta EE 8 consist of?
The Jakarta EE 8 specifications will:
- Be fully compatible with Java EE 8 specifications
- Include the same APIs and Javadoc using the same javax namespace
- Provide open source licensed Jakarta EE 8 TCKs that are based on, and fully compatible with, the Java EE 8 TCKs.
- Include a Jakarta EE 8 Platform specification that will describe the same platform integration requirements as the Java EE 8 Platform specification.
- Reference multiple compatible implementations of the Jakarta EE 8 Platform when the Jakarta EE 8 specifications are released.
- Provide a compatibility and branding process for demonstrating that implementations are Jakarta EE 8 compatible.
Will there be Jakarta EE 8 compatible implementations?
Yes. Multiple compatible implementations of the Jakarta EE 8 Platform will be available when the Jakarta EE 8 specifications are released. We expect that any Java EE 8 compatible implementation would also be Jakarta EE 8 compatible, and the vendors in the Jakarta EE Working Group intend to certify their Java EE 8 compatible implementations as Jakarta EE 8 compatible. In addition, because the Jakarta EE TCKs are available under an open source license, we will “lower the bar” for other technology providers to demonstrate Jakarta EE compatibility for their implementations. The lower cost and more liberal Jakarta EE trademark licensing will allow more technology providers to leverage and strengthen the Jakarta EE brand in the Enterprise Java community. Jakarta EE 8 will provide a new baseline for the evolution of the Jakarta EE technologies, under an open, vendor-neutral community-driven process.
What is the process for delivery of Jakarta EE 8
The process for delivery of Jakarta EE 8 specifications will be fully transparent and will follow the Jakarta EE Specification Process. Expect to see in coming weeks the delivery of initial, draft Jakarta EE 8 component specifications corresponding to Java EE 8 component specifications. These will contain Javadoc defining the relevant APIs, and TCKs for compatibility testing. To publish specification text, we need to acquire copyright licenses for this text. We have obtained Oracle and IBM’s copyright licenses for their contributions, and intend to obtain the remaining copyright licenses required to publish the text of the Jakarta EE 8 Platform specification, and as much as possible of the component specifications. If you contributed to the Java EE specifications at the JCP in the past, expect to be contacted by the Eclipse Foundation to provide a license to use your contributions in Jakarta EE going forward. Providing such a license will be an important step in supporting the new specification process and the Jakarta EE community. You will see these draft specifications evolve to final specifications in an open community process. Join the specification projects and participate!
When will Jakarta EE 8 be delivered?
The Jakarta EE Working Group intends to release final Jakarta EE 8 specifications by the fall of 2019. This is an open community-driven effort, so there will be transparency into the process of driving the Jakarta EE 8 specifications, delivery of the Jakarta EE 8 TCKs, and Jakarta EE 8 compatible implementations.
Update on Jakarta EE Rights to Java Trademarks
Summary of progress to date and implications of the agreement between Eclipse and Oracle on Jakarta EE and use of Java trademarks and the javax namespace.
Introduction
The migration of Java EE to the Eclipse Foundation has been an enormous effort on behalf of the Eclipse Foundation staff and the many contributors, committers, members, and stakeholders that are participating.
This post was reviewed and represents the consensus view of the Jakarta EE Steering Committee.
Earlier this year GlassFish 5.1 was certified at Eclipse using the Java EE 8 TCK at the Eclipse Foundation. Since then under the direction of the working group the community established a Jakarta EE Specification Process (JESP) for the evolution of the Jakarta EE specs at the Eclipse Foundation. Specification projects are being created for all of the Jakarta EE specifications. The TCK process is being refined for Jakarta EE in concert with the new Jakarta EE compatibility logo. This is all being done in support of the Jakarta EE 8 release.
Progress to Date
The Jakarta community has been busy.
- Oracle contributed GlassFish and the Java EE APIs and TCKs to Jakarta EE.
- The Jakarta EE Working Group was formed and supporting committees to provide governance to the community and facilitate collaboration.
- Eclipse GlassFish was certified with the Java EE TCK at the Eclipse Foundation.
- The Eclipse Foundation Specification Process was created, and customization created and approved for the Jakarta EE Specification Process.
- Specification projects are being created and work is underway now within the community to deliver the Jakarta EE 8 release later this year.
- There is an initiative underway for Oracle, IBM, Red Hat and other members of the JCP to contribute their specification documents created at the JCP to Jakarta.
It had been the mutual intention of the Eclipse Foundation and Oracle to agree to terms that would allow the evolution of the javax package namespace in Jakarta EE specifications. Unfortunately, following many months of good-faith negotiations, the Eclipse Foundation and Oracle have been unable to agree on terms of an agreement for the Eclipse Foundation community to modify the javax package namespace or to use the Java trademarks currently used in Java EE specifications. Instead, Eclipse and Oracle have agreed that the javax package namespace cannot be evolved by the Jakarta EE community. As well, Java trademarks such as the existing specification names cannot be used by Jakarta EE specifications. Because of the complexity and confidential nature of our negotiations, the Eclipse Foundation and Oracle have also agreed that we will not attempt to characterize here what has resulted in this outcome. It is the best outcome we could mutually achieve for the community. Some additional context is provided in the Eclipse Foundation Board and Jakarta EE Steering Committee meeting minutes.
What restrictions does this outcome impose on the Eclipse community?
Oracle’s Java trademarks are the property of Oracle and the Eclipse Foundation has no rights to use them. The implications of this are as follows:
- The javax package namespace may be used within Jakarta EE specifications but may be used “as is” only. No modification to the javax package namespace is permitted within Jakarta EE component specifications. Jakarta EE specifications that continue to use the javax package namespace must remain TCK compatible with the corresponding Java EE specifications.
- Jakarta EE component specifications using the javax package namespace may be omitted entirely from future Jakarta EE Platform specifications.
- Specification names must be changed from a “Java EE” naming convention to a “Jakarta EE” naming convention. This includes acronyms such as EJB, JPA or JAX-RS.
In addition to the above, any specifications which use the javax namespace will continue to carry the certification and container requirements which Java EE has had in the past. I.e., implementations which claim compliance with any version of the Jakarta EE specifications using the javax namespace must test on and distribute containers which embed certified Java SE implementations licensed by Oracle. These restrictions do not apply to Jakarta EE specifications which do not utilize javax, including future revisions of the platform specifications which eliminate javax.
Note that the ratified Jakarta EE specifications will be available under a different license (the Eclipse Foundation Specification License). This is the reason why the Eclipse Foundation is currently asking the community to update their contributor and committer agreements.
What is next for the Jakarta EE Working Group?
The Jakarta EE Working Group including Oracle will continue to do what they set out to do: namely, move Java EE to the Eclipse Foundation. The group remains committed to creating a Jakarta EE 8 specification, logoed under the Eclipse Foundation’s Jakarta trademark. Further, the group is also committed to future versions of the Jakarta EE specifications that deliver on the original promises of innovation and evolution in cloud-native Java.
What does it mean for Jakarta EE to not modify the javax package namespace?
The Agreement does allow for modification and evolution under a new namespace, such as jakarta. It is expected that all future evolution and innovation will not use the javax namespace.
What happens to the Jakarta EE brand?
The Jakarta EE compatibility and the Jakarta EE member logos have both been decided on by the community and published. Work is underway to deliver the branding usage guidelines and supporting trademark license agreement. We expect to see the usage of these brands later this year.
Will there be a Jakarta EE 8?
Yes. The community is working hard to deliver the Jakarta EE 8 release, which is Java EE 8 delivered from Eclipse. We expect that many application servers will certify as Jakarta EE 8 compatible.
What happens beyond Jakarta EE 8?
The guiding principle for Jakarta EE 9 will be to maximize compatibility with Jakarta EE 8 for future versions without stifling innovation. This will most likely involve two key topics: migration of some or all of the Jakarta EE specification source to a new namespace for future evolution; means to provide backwards compatibility with javax at a binary level, allowing old applications to run on Jakarta 9 implementations with some form of build or runtime tooling.
So while there will be a point in time where future versions of specifications will have to go through a source code incompatible change with respect to the previous javax based packages, this will be a straightforward transformation.
Further plans are being evolved by the Jakarta EE community via the Jakarta EE Platform Project. Your comments and participation are encouraged.
What does this mean for the EE4J projects?
The specification projects need to be renamed to not use Oracle’s Java trademarks. The Jakarta community gets to decide on the new names. This is an opportunity to tighten up the naming and get a better level of consistency. The future of Eclipse Enterprise for Java (EE4J) projects will be determined by the community who participate in those specifications and open source projects.
What is next for Eclipse GlassFish?
Work is underway at the Eclipse GlassFish project running the Jakarta EE 8 TCK and being ready to support its role in the TCK for interop testing. The future of Eclipse GlassFish will be determined by the community who participate in the project.
How will specs be updated beyond Jakarta EE 8?
Jakarta EE specifications will be updated according to the approved Jakarta EE Specification Process (JESP). The actual enhancements will be determined by the community who participate in those specification projects.
Life at Eclipse 