Skip to main content
  • Log in
  • Manage Cookies
Eclipse Foundation
Download
  • Projects
  • Working Groups
  • Members
  • Community
    • Marketplace
    • Events
    • Planet Eclipse
    • Newsletter
    • Videos
    • Blogs
  • Participate
    • Report a Bug
    • Forums
    • Mailing Lists
    • Wiki
    • IRC
    • Research
  • Eclipse IDE
    • Download
    • Learn More
    • Documentation
    • Getting Started / Support
    • How to Contribute
    • IDE and Tools
    • Newcomer Forum
  • More
      • Community

      • Marketplace
      • Events
      • Planet Eclipse
      • Newsletter
      • Videos
      • Blogs
      • Participate

      • Report a Bug
      • Forums
      • Mailing Lists
      • Wiki
      • IRC
      • Research
      • Eclipse IDE

      • Download
      • Learn More
      • Documentation
      • Getting Started / Support
      • How to Contribute
      • IDE and Tools
      • Newcomer Forum
    • Search

  1. Home
  2. Blogs
  3. Ivar Grimstad's blog
  4. Demystifying Java SE Level for Jakarta EE

Demystifying Java SE Level for Jakarta EE

Monday, June 14, 2021 - 05:13 by Ivar Grimstad

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.

Tags: 
EclipseFoundation
Jakarta EE
Community
Eclipse Foundation
OpenSource
Source: 
https://www.agilejava.eu/2021/06/14/demystifying-java-se-level-for-jakarta-ee/
  • Ivar Grimstad's blog

Eclipse Foundation Blogs

  • Wayne Beaton (820 posts)
  • Mike Milinkovich (319 posts)
  • Ivar Grimstad (244 posts)
  • Benjamin Cabé (131 posts)
  • Tanja Obradovic (60 posts)
  • Thabang Mashologu (37 posts)
  • John Kellerman (27 posts)
  • Paul Buck (22 posts)
  • Brian King (19 posts)
  • Frédéric Desbiens (19 posts)
  • Christopher Guindon (15 posts)
  • Mikaël Barbero (14 posts)
  • Gael Blondelle (14 posts)
  • Hailley Seed (10 posts)
  • Denis Roy (9 posts)
  • Hudson Kelly (8 posts)
  • Michael Plagge (4 posts)
  • Serina El Salibi (3 posts)
  • Shabnam Mayel (3 posts)
  • Shanda Giacomoni (3 posts)
  • Jacob Harris (2 posts)
  • Clark Roundy (2 posts)
  • Stephanie Swart (1 posts)
  • Karla Ferrer (1 posts)
  • Sharon Corbett (1 posts)
  • Paul White (1 posts)

Recent blog posts

  • Hashtag Jakarta EE #162
  • DEVIES Award to Jakarta EE 10
  • Jakarta EE track at Devnexus 2023!!!!
  • Hashtag Jakarta EE #161
  • Jakarta EE Community Update - 2022 in Review
  • jChampionsConf 2023
  • Eclipse Cloud DevTools Contributor Award: Theia Developers for Detachable Views
  • Hashtag Jakarta EE #160
  • THAT Conference 2023
  • European Cyber Resiliency Act: Potential Impact on the Eclipse Foundation
More

Eclipse Foundation

  • About Us
  • Contact Us
  • Sponsor
  • Members
  • Governance
  • Code of Conduct
  • Logo and Artwork
  • Board of Directors
  • Careers

Legal

  • Privacy Policy
  • Terms of Use
  • Copyright Agent
  • Eclipse Public License
  • Legal Resources

Useful Links

  • Report a Bug
  • Documentation
  • How to Contribute
  • Mailing Lists
  • Forums
  • Marketplace

Other

  • IDE and Tools
  • Projects
  • Working Groups
  • Research@Eclipse
  • Report a Vulnerability
  • Service Status

Copyright © Eclipse Foundation. All Rights Reserved.

Back to the top