EclipseFoundation

Hashtag Jakarta EE #78

Welcome to the seventy-eighth issue of Hashtag Jakarta EE!

Summer is here (at least for those of us located in the Northern hemisphere…) and things are slowing down a little everywhere. But, the Jakarta EE Platform project continues to check items off the list preparing for Jakarta EE 10.

In our last call, we summarized the vote we have had running on the public mailing list regarding which version of Java SE to use the base for Jakarta EE 10. The preferred selection by the community (committers and non-committers) was the one labeled “Option 1”. This option establishes Java SE 11 as the base for Jakarta EE 10. That means that the Jakarta EE APIs will be able to take advantage of up-to Java SE 11 language features and the API JARs will be compiled to Java SE 11 byte code level.

The option also states that the TCK should be able to test runtimes that are using any Java SE level of 11 and above. This is actually the most interesting part for Jakarta EE application developers. As long as the implementation of my choice is offering to run on e.g. Java SE 17, I can use all the Java SE 17 features I want in my application. The fact that the APIs are compiled with Java SE 11 and aren’t exposing any language features above 11, does not really affect me that much.

It is really a win-win since it allows more conservative organizations to stay on Java SE 11 for as long as they wish while the ones more eager to stay up-front can move on to Java SE 17 and above.

Do check out the meeting minutes from our weekly platform calls, and don’t forget to subscribe to the platform project mailing list if you want to participate in these discussions.

Hashtag Jakarta EE #77

Welcome to the seventy-seventh issue of Hashtag Jakarta EE!

The 2021 JVM Ecosystem Report by Snyk was published this week. The focus of the report is on the most important aspects for Today’s JVM developers. The report shows that Java SE 11 is the dominant version of Java in production environments. It is good to see that the industry is moving past Java SE 8. This is also great input to the decision on what Java SE version to use as a baseline for Jakarta EE 10. The report also touches on application frameworks. Jakarta EE (and Java EE) is doing very well with a market share of 12.7% and 24.2% respectively.

The article Java EE and Jakarta EE: What IT leaders should know in The Enterprisers Project highlights how Jakarta EE helps bridge old and new technologies in hybrid cloud environments.

On Tuesday, June 24, I will be presenting Beyond Jakarta EE 9.1 at jOnConf 2021. At the end of the day, I will be participating in a panel with the topic Software Architectures: Enterprise Java.

Eclipse GlassFish 6.2.0 was released this week! This version includes Eclipse Krazo, which means that Jakarta MVC is supported out of the box. A huge milestone for Jakarta MVC!

Demystifying Java SE Level for Jakarta EE

As I mentioned in Hashtag Jakarta EE #76, the Jakarta EE Platform project is in the process of determining the Java SE requirements for Jakarta EE 10. In this post, I try to shed some light on the implications of the various options currently up for a vote. What do these options actually mean for:

a) the Jakarta EE API developers
b) the vendors/projects implementing Jakarta EE specifications, and
c) the application developers.

I have discussed the options and the implications for these three groups below.

Option 1: source=Java SE 11, bin=Java SE 11, TCK=Java SE 11+

Java SE 11 as source/language level and binary level for all API JARs. Compatible Implementations are free to pass TCKs using any Java SE version at 11 or higher.

a) API developers are restricted to the language features in Java SE 11. This means that features such as Records can not be used in the APIs. The API JARs must be compiled to Java SE 11 class level.

b) Implementors can implement their compatible implementations using any language features from any Java SE version. They may choose to certify using any version from 11 and higher. For example, a vendor may choose to support only Java SE 17 and higher if they wish. Or they may choose to support any Java SE version from 11 and higher.

c) Application developers can develop their applications using any language features from any Java SE version. If they use Java SE 16, or higher, they are able to use Records in their applications as they would like. However, some mapping, or conversion, may be needed when interacting with the Jakarta EE APIs. The upper limit of the Java SE version will depend on what version their selected implementation (runtime) supports.

Option 2: source=Java SE 11, bin=Java SE 17, TCK=Java SE 17+

Java SE 11 as source/language level and Java SE 17 as the binary level for all API JARs. Compatible Implementations are free to pass TCKs using any Java SE version at 17 or higher.

a) API developers are restricted to the language features in Java SE 11. This means that features such as Records can not be used in the APIs. The API JARs must be compiled to Java SE 17 class level.

b) Implementors can implement their compatible implementations using any language features from any Java SE version. They have to certify using Java SE 17 or higher.

c) Application developers can develop their applications using any language features from any Java SE version. If they use Java SE 16, or higher, they are able to use Records in their applications as they would like. Some mapping, or conversion, may be needed when interacting with the Jakarta EE APIs.

Option 3: source=Java SE 17, bin=Java SE 17, TCK=Java SE 17+

Java SE 17 as source/language level and binary level for all API JARs. Compatible Implementations are free to pass TCKs using any Java SE version at 17 or higher.

a) API developers can use any language features from any Java SE version. This means that features such as Records can be used in the APIs. The API JARs must be compiled to Java SE 17 class level.

b) Implementors can implement their compatible implementations using any language features from any Java SE version. They have to certify using Java SE 17 or higher.

c) Application developers can develop their applications using any language features from any Java SE version. If they use Java SE 16, or higher, they are able to use Records in their applications as they would like.

Conclusion

As an application developer, I would always want to use the highest version of Java SE possible, so option 3 would be my obvious choice. However, should I think as a vendor with an existing customer base, I would probably prefer option 1. This option offers full flexibility. I could please my more slow-moving customers by certifying on 11. In addition to that, I could also certify on 17 and thereby please the more impatient developers. It would also enable me to offer an upgrade path for the existing customers from 11 to 17, ensuring them that the future is bright for them as well. Option 2 doesn’t make sense to me at all. Why should the API developers be restricted to 11 language features, but required to compile to 17? And everyone else are required to use 17?

When I think about it, there aren’t that many language features between Java SE 11 and 17 that would make life that much easier for the API developers, except maybe Records that would make sense to build some support around in some of the APIs. But I don’t think that justifies the cost of leaving so many users of the technology behind as many of them are still on Java SE 8. Java SE 17 could be the baseline for Jakarta EE 11, which would allow the API developers time to let the best idioms for the newer language features be established before adding them to the specifications.

So, if you’ve read this far, you’ve probably also guessed that my favorite is Option 1.

Hashtag Jakarta EE #76

Welcome to the seventy-sixth issue of Hashtag Jakarta EE!

One of the goals for the Jakarta EE Platform project is to define a predictable way the Jakarta EE specifications are aligned with Java SE. For example: Which Java SE version should Jakarta EE 10 require? This is one of the questions currently being discussed on the weekly Jakarta EE Platform calls. We have narrowed it down to three options that are currently being voted on:

Option 1: source=Java SE 11, bin=Java SE 11, TCK=Java SE 11+
Java SE 11 as source/language level and binary level for all API JARs. Compatible Implementations are free to pass TCKs using any Java SE version at 11 or higher.

Option 2: source=Java SE 11, bin=Java SE 17, TCK=Java SE 17+
Java SE 11 as source/language level and Java SE 17 as the binary level for all API JARs. Compatible Implementations are free to pass TCKs using any Java SE version at 17 or higher.

Option 3: source=Java SE 17, bin=Java SE 17, TCK=Java SE 17+
Java SE 17 as source/language level and binary level for all API JARs. Compatible Implementations are free to pass TCKs using any Java SE version at 17 or higher.

Everyone is encouraged to chime in on the mailing list with their opinion. Remember to mark the committer flag in your vote to true only if you are a committer on the Jakarta EE Platform project.

The intention of the Jakarta EE Core Profile specification is to target smaller runtimes and allow them to be certified as Jakarta EE compatible products. The set of Jakarta EE specifications that will be included in the profile has not been defined yet, but here is the latest suggestion for how it could potentially look like.

Do check out the Dismiss the Myths: Get to know Jakarta EE (Java EE) webinar series from Payara to get some common myths dismissed. Among other things, you will experience that Java is highly relevant, and keeps up-to-date with the changes in the IT world. And that there is a bright future for Jakarta EE!

The Call for Proposals for EclipseCon 2021 ends on Tuesday, June 15, so there is still time for you to submit your Jakarta EE talk to have a chance of being a speaker!

Hashtag Jakarta EE #75

Welcome to the seventy-fifth issue of Hashtag Jakarta EE!

The Jakarta EE Platform project does not rest on its laurels! Vivid discussions are going in the weekly platform calls as well as on the mailing lists. Read the minutes from the platform calls to keep informed in case you are not able to join the calls.

Talking about keeping up-to-date, I will be speaking at J4K this week. My talk, Jakarta EE Core Profile – A Slimmer Jakarta EE, is about the Jakarta EE Core Profile which you may say is very much a work-in-progress. This talk will give you the latest status update as well as pointers to how to contribute and influence the direction of the specification.

I am extremely happy to see that Hibernate ORM 5.5.0 is now certified as a compatible implementation of Jakarta Persistence! They have passed the TCKs for both Jakarta Persistence 2.2 and Jakarta Persistence 3.0 which means that they are aligned with both Jakarta EE8 and Jakarta EE 9 supporting both the jakarta.* namespace as well as javax.*. This is an important milestone. Provides a migration path for all those applications out there using Hibernate ORM for persistence.

The Call for Proposals for EclipseCon 2021 ends on June 15, so there is still time for you to submit your Jakarta EE talk to have a chance of being a speaker!

The planning for JakartaOne LiveStream 2021 has just started. Mark December 7, 2021 in your calendar today. More details and dates for the Call For Paper will be announced shortly. Stay tuned!

Hashtag Jakarta EE #74

Welcome to the seventy-fourth issue of Hashtag Jakarta EE!

Jakarta EE 9.1 is RELEASED! Here’s what you should do now:

Step 1: Update your pom.xml

<dependency>
  <groupId>jakarta.platform</groupId>
  <artifactId>jakarta.jakartaee-api</artifactId>
  <version>9.1.0</version>
</dependency>

Step 2: Migrate to jakarta.* namespace

Follow this migration guide for the namespace migration.

Step 3: Run

Download the Jakarta EE 9.1 Compatible Product of your choice.

Tomorrow is the last day to take the 2021 Jakarta EE Developer Survey! Please take a couple of minutes to help us shape the future direction of Jakarta EE. Now that we have released Jakarta EE 9.1, the focus is on the next release. The work has already started with the establishment of the new Jakarta EE Core Profile and discussions around the release- and versioning strategy going forward. Follow the discussions in the Jakarta EE Platform Weekly call. The survey will provide valuable input to this work.

The early bird deadline for EclipseCon 2021 is coming up! Make sure you submit your talk before June 1, 2021, for a chance to be one of the first five talks selected for the conference.

Timeline:
June 1: Early-Bird Submission Deadline
June 15: Final Submission Deadline
July 1: Notification Sent

Navigate to EclipseCon 2021 Call for Proposals and submit your Jakarta EE talk today!

Jakarta EE 9.1 is RELEASED!

Join us in celebrating a new release of Jakarta EE!

The Jakarta EE Working Group Releases Jakarta EE 9.1 as Industry Continues to Embrace Open Source Enterprise Java! Jakarta EE 9.1 adds support for Java SE 11 runtimes to the foundational Jakarta EE 9 release. This gives developers more flexibility when migrating from previous Jakarta EE releases.

In order to upgrade to the new version, simply change the dependency version in your pom.xml to 9.1.0. If you are upgrading from a version prior to Jakarta EE 9, follow the migration steps for the namespace change from javax.* to jakarta.*.

Maven dependency for Jakarta EE Platform 9.1

<dependency>
  <groupId>jakarta.platform</groupId>
  <artifactId>jakarta.jakartaee-api</artifactId>
  <version>9.1.0</version>
</dependency>

Maven dependency for Jakarta EE Web Profile 9.1

<dependency>
  <groupId>jakarta.platform</groupId>
  <artifactId>jakarta.jakartaee-web-api</artifactId>
  <version>9.1.0</version>
</dependency>

Hashtag Jakarta EE #73

Welcome to the seventy-third issue of Hashtag Jakarta EE!

Jakarta EE 9.1 will be released on Tuesday, May 25, 2021! Stay tuned for announcements on this blog, the jakarta.ee website, Jakarta EE on Twitter, and a bunch of other places.

But, we don’t rest there. The work with Jakarta EE 10 is progressing as well. The creation- and plan review for Jakarta EE Core Profile 10 was approved this week by the Jakarta EE Specification Committee. We have also started the issues for defining the scope of Jakarta EE Web Profile 10 and Jakarta EE Platform 10. Plan reviews of these are expected to be initiated shortly.

The project proposal for Jakarta Config is being processed. Since it is a project that will produce a specification under the Jakarta EE Specification Process (JESP), a creation review by the specification committee is required. This review ballot is ongoing and will end this week. Community members are encouraged to chime in and place their (non-binding) vote.

I am very pleased to announce that Eclipse Krazo, an implementation of Jakarta MVC was integrated into Eclipse GlassFish this week! This is an important milestone for the project.

If you haven’t filled out the 2021 Jakarta EE Developer Survey yet, I hope you will take a couple of minutes required to provide us with valuable input in shaping the direction of Jakarta EE!

Hashtag Jakarta EE #72

Welcome to the seventy-second issue of Hashtag Jakarta EE!

In the Jakarta EE Platform call this week, we decided to ask the specification projects for feedback on whether October 15, 2021 is an achievable date for having their specifications ready for release. So far, the feedback has been positive. It is great to see that the specifications are moving forward again. The Jakarta EE 9 release with the associated namespace change from javax.* to jakarta.* may very well prove to be the tap on the bottle that got the ketchup flowing.

The Eclipse Cargo Tracker is a fantastic example of an end-to-end Jakarta EE application that showcases core Jakarta EE technologies. Thanks to Scaleforce and Jelastic for providing resources to deploy the demo application to the cloud.

Try out the Cargo Tracker!

If you are interested in contributing to the project, or just look at the code, go to the Cargo Tracker GitHub repository.

A warm welcome to The Apache Software Foundation that joined the Jakarta EE working group as a guest member this week.

Hashtag Jakarta EE #71

Welcome to the seventy-first issue of Hashtag Jakarta EE!

Let’s look at Jakarta EE 10! By filtering on the EE10 label in our GitHub issue tracker, you will find the list of topics currently under discussion. I would like to highlight a couple of the issues.

Jakarta EE 10 Direction Statement (#352) lists focus areas that we are working on in order to come up with a proper roadmap for the platform. The platform team has been tasked by the Jakarta EE Steering Committee to produce a statement of direction for the steering committee meeting on May 11, 2021. I think we are in pretty good shape, but it will most certainly be refined more in the platform call a couple of hours before the steering committee gathers.

Create a new core profile specification (#353) collects the discussion around creating a new Jakarta EE Core Profile. We have created the plan review record and expect the ballot for creation- and plan reviews to be started pretty soon. Check out the JESP Guide for information about what these review steps actually means.

Speaking about plan reviews, we have a lot of them going on right now. Just check out the list of pull requests for plans. The Jakarta EE 10 Plan Reviews project board shows the current status of the reviews as they flow through our process.

In addition to this, a project proposal for Jakarta Config is being drafted. I expect it to be made public for community review within short.

If you haven’t filled out the 2021 Jakarta EE Developer Survey yet, I hope you will take a couple of minutes required to provide us with valuable input in shaping the direction of Jakarta EE!