OpenSource

Hashtag Jakarta EE #81

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

Last week we hosted the Jakarta EE Update call. If you missed it, don’t despair as it was recorded. As usual, it will be cut into smaller themed pieces and published on the Jakarta EE YouTube channel.

The Jakarta EE Platform project has stated a clarification regarding the Java SE level for Jakarta EE 10. The component specifications are recommended, not recommended to compile their API jar files to Java SE 11. That means that they can compile to lower Java SE levels if it fits them better. The recommendation, however, is still to compile to Java SE 11 using the --release option to the compiler. Exemplified here by the maven compiler plugin configuration.

...
    <maven.compiler.release>11</maven.compiler.release>
...

The topic of release cadence and time-based vs feature-based continues. I suspect this to be the major discussion point in the platform call next week. One of the questions that are being discussed is whether to tie the roadmap and release cadence to the Java SE LTS releases, effectively meaning a three-year release cycle for the Jakarta EE Platform and Profiles. Please join in on the discussions on the mailing list and the weekly platform project calls.

The JakartaOne Livestream 2021 Call-for-Paper is open! Take this opportunity and submit your talk to the third edition of this one-day virtual conference. If you are a new speaker, take a look at the previous editions for inspiration. If you have spoken at any of, or both, the previous events, make sure to complete your collection of the JakartaOne Livestream buttons.

Hashtag Jakarta EE #80

Welcome to the eightieth issue of Hashtag Jakarta EE!

Our next Jakarta EE Update call is coming up on Wednesday, July 14th. Join in to get the latest updates from the Jakarta EE working group. It is an informal event where you will be able to ask any questions you may have, and hopefully get them answered. Refer to the Jakarta EE Community Calendar for details.

The weekly calls in the Jakarta EE Platform project continue. Last week’s call was largely dominated by discussions around versioning schemes. I expect that this will continue in this week’s call as well.

Check out the Jakarta EE Specifications Calendar for meeting details. There are several other regular calls listed here as well. The Jakarta CDI project meets weekly. The same goes for Jakarta Config, while Jakarta MVC has monthly calls.

If you arrange calls for your Jakarta specification project, please do remember to add them to the calendar, so everyone interested is able to join. Both for once-in-a-while, ad-hoc as well as regular calls.

The number of compatible products for Jakarta EE 9.1 continues to rise. The Jakarta EE 9.1 Platform Compatible Products are Eclipse GlassFish, ManageFish Server, Open Liberty, Payara Server Community, and WildFly.

The Jakarta EE 9.1 Web Profile Compatible Products are Apache TomEE, Eclipse GlassFish, Open liberty, and WildFly.

Get Listed!

If you are doing some interesting work that involves Jakarta EE technologies, please do reach out to me. I will be happy to add it to an upcoming issue of Hashtag Jakarta EE.

Hashtag Jakarta EE #79

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

I have previously described how to migrate manually from the javax.* to jakarta.* namespace in this migration guide. While this migration is a pretty easy task, it can be time-consuming and error-prone. But don’t despair, the community is coming to your help by providing tools that can do this for you, or at least assist you in the process. Just take a look at these:

The Tomcat Migration Tool for Jakarta EE provides easy-to-use command-line tooling for transforming Jakarta EE applications on the javax.* namespace over to jakarta.*. You can choose between two profiles depending on whether you are using the Jakarta EE APIs supported by Apache Tomcat, or the entire suite of specifications.

The Eclipse Transformer also provides transformation of Jakarta EE applications on the javax.* namespace to jakarta.*. It can operate on source files as well as class files and has an extensive set of configuration options. The Eclipse Transformer can also be used as a custom class loader, so it can perform the transformation at runtime.

In the upcoming 2021.2 version of IntelliJ IDEA, there will be built-in support for migrating from javax.* to jakarta.*. Check out Automatic migration from Java EE to Jakarta EE for a description of the functionality. If you look closely, you will notice that the sample application they are using is my Complete Duke application that I use to demo the namespace change. You can find it, and others in my Jakarta EE Duke sample projects. It is awesome that the folks at JetBrains found my demo app useful enough to use for showcasing this feature!

As I mentioned above, the Eclipse Transformer provides custom classloader capabilities so the namespace migration can be done at runtime. Many of the Jakarta EE implementations are using this technology in the Jakarta EE 9 and Jakarta EE 9.1 compatible products. I have included an example here of how you can run a Jakarta EE 8 application transformed to Jakarta EE 9.1 and packaged in a WildFly bootable JAR.

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!

25 Years of Java!

25 years and still going strong! Java is everywhere. It is the #1 programming language in the World. And it continues to evolve! Java has been a part of my entire professional career. Let’s get together and celebrate the past 25 years and look ahead for the next 25!

My #movedbyJava timeline

1996: Wrote my first Hello, World! in Java
1998: Started my professional career as a Java programmer
1999: My first JavaOne
2007: Joined the Java Community Process (JCP)
2013: First time presenting at JavaOne
2016: Became Java Champion
2016: Elected into the JCP Executive Committee
2016: Got a Duke tattoo
2020: Still coding Java

New Challenges Ahead

I am super excited to announce that October 1st, I will become the first Jakarta EE Developer Advocate at Eclipse Foundation!

So, What’s new? Hasn’t this guy been doing this for years already?

Well, yes, and no. My day job has always been working as a consultant even if I have been fortunate that Cybercom Sweden (my employer of almost 15 years) has given me the freedom to also work on open source projects, community building and speaking at conferences and meetups.

What’s different then?

Even if I have had this flexibility, it has still been part-time work which has rippled into my spare time. It’s only so much a person can do and there are only 24 hours a day. As a full-time Jakarta EE Developer Advocate, I will be able to focus entirely on community outreach around Jakarta EE.

The transition of the Java EE technologies from Oracle to Jakarta EE at Eclipse Foundations has taken a lot longer than anticipated. The community around these technologies has taken a serious hit as a result of that. My primary focus for the first period as Jakarta EE Developer Advocate is to regain the trust and help enable participation of the strong community around Jakarta EE. The timing of establishing this position fits perfectly with the upcoming release of Jakarta EE 8. From that release and forward, it is up to us as a community to bring the technology forward.

I think I have been pretty successful with being vendor-neutral throughout the years. This will not change! Eclipse Foundation is a vendor-neutral organization and I will represent the entire Jakarta EE working group and community as the Jakarta EE Developer Advocate. This is what distinguishes this role from the vendor’s own developer advocates.

I hope to see you all very soon at a conference or meetup near you!

Amazon Corretto 8

UPDATE! I have updated the option of running Corretto in Docker to using the amazoncorretto Docker image available from Docker Hub.

Amazon Corretto is a production-ready distribution of OpenJDK with long-term support including performance- and security updates provided by Amazon.

Tweet announcing Amazon Coretto 8

Amazon provides installation packages and instructions for Linux, Windows, and macOS, as well as a Docker. The latest installation package is based on OpenJDK version 1.8.0_202:

$ java -version
openjdk version "1.8.0_202"
OpenJDK Runtime Environment Corretto-8.202.08.2 (build 1.8.0_202-b08)
OpenJDK 64-Bit Server VM Corretto-8.202.08.2 (build 25.202-b08, mixed mode)
$

If you don’t want to, or isn’t able to install Corretto on your workstation, t is pretty straightforward to try it out using Docker:

$docker run -it amazoncorretto

bash-4.2# java -version
openjdk version "1.8.0_202"
OpenJDK Runtime Environment Corretto-8.202.08.1 (build 1.8.0_202-b08)
OpenJDK 64-Bit Server VM Corretto-8.202.08.1 (build 25.202-b08, mixed mode)

bash-4.2#

Amazon Corretto is licensed under the same license as OpenJDK (GPLv2 with CPE) and there are no costs associated with using it. Amazon will provide quarterly security updates to Corretto 8 at least until June 2023.

But Java 8 is sooo old!

Relax, Amazon plans to make Corretto 11 available during the first half of 2019. Corretto 11 will be based on OpenJDK 11.

Java EE with NetBeans 10

The Apache NetBeans project is really shaping up. Version 10.0 was released on the 27th of December 2018. The main features added since version 9.0 are listed on the download page. For me personally, the most important feature is the JDK 11 Support.

So, what about Java EE then?

Until all the NetBeans sources have been transferred from Oracle to Apache and incorporated into the Apache NetBeans build, an additional step is required in order to get Netbeans set up for Java EE development.

The first thing you need to do is to add the NetBeans 8.2 Distribution Update Center. Select Tools->Plugins in Apache NetBeans 10.0. Then click on the Settings tab and choose Add. Paste in the URL: 

http://updates.netbeans.org/netbeans/updates/8.2/uc/final/distribution/catalog.xml.gz

Update Plugin Center Configuration

After saving the configuration, the next step is to select the Available Plugins tab and type java ee in the search field.

Search for Java EE plugins

As a minimum, check the plugin called Java EE Base and click the Install button. Follow the instructions and accept the licenses. NetBeans will need to restart before continuing after the installation.

After this, you are able to set up a Java EE server as shown with GlassFish 5.0 below. Choose Tools->Servers and then click Add Server.

GlassFish 5.0 with NetBeans 10.0

Happy Coding!

Eclipse GlassFish Release Plan

UPDATED!

Yesterday, the release plan for Eclipse GlassFish was announced on the EE4J mailing list. For convenience, I have repeated the plan here:

September 18
All code required for GF build contributed.

September 23
Eclipse GlassFish builds.

October 1
Java EE 8 CTS testing. We are able to run CTS tests on Eclipse GlassFish.

October 22 ⚡
CI/CD release pipelines completed.

October 22
Eclipse GlassFish 5.1-RC1 milestone release.

November 5 ⚡
Dependencies updated. All projects are released to OSSRH and have dependencies to Eclipse version of other components.

November 30 ⚡
Release Review completed.

December 14 ⚡
Eclipse GlassFish 5.1 release. All CTS tests are passed.

There is a lot of work to do, so every contribution is appreciated, especially regarding setting up the CI/CD pipelines for all the EE4J projects. Take a look at our status sheet and sign up where you think you can contribute.