B4J Question Corretto 11 - Alternative to Java 11

[ThRuST]

This post is about Corretto, the open source alternative to Open Java 11.
Here you can post your experiences with this Open Java alternative. Also share your experience with Corretto and installers made with Packager11.

Official website here

"Amazon Corretto is a no-cost, multiplatform, production-ready distribution of the Open Java Development Kit (OpenJDK). Corretto comes with long-term support that will include performance enhancements and security fixes. Amazon runs Corretto internally on thousands of production services and Corretto is certified as compatible with the Java SE standard. With Corretto, you can develop and run Java applications on popular operating systems, including Linux, Windows, and macOS."

What comes to mind is how the Java 8/9 parameters work for Packager11, if it works at all!!

 

[Erel]

B4JPackager11 works with OpenJDK + OpenJFX 11. I don't see any reason to use a different implementation of Java. This is just a waste of time.

It is very simple to use B4JPackager11. You just need to follow the instructions.

 

[ThRuST]

@Erel Thanks for pointing this out. Since I heard that OpenJDK is on a 6 month release cycle, I worry that the executable from the installer won't run after 6 month.

 

[OliverA]

I worry that the executable from the installer won't run after 6 month

The B4JPackager11 will include a complete JRE environment. As long as that environment will run on whatever OS version it is running on, your application will run. There is no guarantee though that, for example, Windows 25.3 (The Spring update in 2025, if that is the way Microsoft will keep doing things) will not break something - just saying.

What could be some issues with OpenJDK's release cycle not having a LTS version? Let's say 18 months down the road
1) You find a bug in OpenJDK 11. Unless it has already been addressed, you will most likely never see an update for the bug. The standard answer most likely be upgrade to the newest version (14?)
2) You find a cool new library that you want to use. Since OpenJDK is on a 6 month cycle, the author (being young and cool - not me) will target the current OpenJDK. For some odd reason, it is doing something that will not work with OpenJDK 11. Most likely, the author will not respond to any requests to make it work with 11, since it's support cycle has ended. So 1) ignore the library (most likely case) or 2) upgrade to the newest OpenJDK.

More notes:
1) Keeping up with the release cycle may not be an issue as long (and this should be the case) the changes are incremental. Just be aware that with a 6 months cycle, 2 years from now you'll have up to 4 sets of changes.
2) Nothing stops you from using OpenJDK 11 for years. Just be aware that bugs and libraries may leave you behind.
3) The requirement for Java 11 and up applications to come bundled with the JRE make even more sense now. An installed application is not dependent on a system wide installed JRE that may break the applications functionality at any given system JRE update. This actually gives the developer more control and allows for a more stable user experience. This point right here, should be a huge benefit to what you are trying to accomplish with your application (distributing it to laptop vendors, etc.) and should be a really strong reason for you to leave 8/9 behind and jump forward to 11. Updating your application to the latest JRE should also be a breeze, since your update will include the latest JRE.

Please note, I may be completely of the rails here and anyone can chime in and let me know. With @Erel not stressing, you should not be stressing.

 

[ThRuST]

@OliverA Thanks for a complete response upon this matter. I have no intention to stress anyone with my questions.
Of course I worry that my application should stay up to date but their new life cycle workplan brings some questions and concerns.

A project that has three years in the making with support from 5-10 experts with extreme working hours needs maintenance and
it happens to be me who sit behind the levers to make sure it works. To keep up to date with each Java version becomes a "chase"
that is a waste of time really, as long as no new libraries are included in the project. Thereby my decision to develope with JDK v9.0.4.

A few more month to wrap it all up and it will work nicely with the old Java. An old Porsche might outrun a new Ferrari, if properly customized.

 

[OliverA]

A project that has three years in the making with support from 5-10 experts with extreme working hours needs maintenance and
it happens to be me who sit behind the levers to make sure it works. To keep up to date with each Java version becomes a "chase"
that is a waste of time really, as long as no new libraries are included in the project. Thereby my decision to develope with JDK v9.0.4

That's why I'm so puzzled that you went with 9. 9 was just an interim release, never meant to be LTS. Both 9 and 10 were there to make the learning curve easier for the items that 11 brought to the table and the items that 11 took away/changed. Support for 8 will be a long time coming, even unpaid support (just not from Oracle).

 

[ThRuST]

Well that was mainly because of some libraries which was updated to work with the, at the time, latest JDK v9 before the major change in Java 10 that had no support for earlier versions so that's when I got "stuck" in the earlier Java. Mainly also because of that Swing was used with Java 8 and RichTextFX got support for Java 9,
which had me tied up to either leave some functions out to stay up to date, or be content with the previous libs. This is always a dilemma that I never really liked ever since Java 10 came out. I don't mean to offend anyone by saying this, but Microsoft might have an advantage when Oracle made this extreme turn. But I still hang on to JavaFX.