Featured Platform Liferay DXP 2023.Q3

Unofficial JDK17/JDK21 Building Bug Bounty Program

Help us help you by finding and reporting build issues from JDK17 and/or JDK21...

thumbnail
David H Nebinger
Published Date2 Months Ago - 2119 Views

Everyone loves a bug bounty program, right?

Well I want to launch an unofficial bug bounty program today!

What are we looking for? Bugs related to performing builds using JDK17 and/or JDK21.

So anything related to dev tools, such as Blade, the IDE plugins, the Liferay Workspace/Gradle, Maven plugins, the various workspace plugins like ServiceBuilder, RESTBuilder, themes, Docker builds, client extensions, the database upgrade client, building/bundling Javascript portlets, Liferay Docker Images, the works.

When you run into an issue, retry it using JDK11. If it builds correctly and can be deployed from JDK11 but fails under JDK17 or JDK21, this is a bug suitable for this unofficial bug bounty program!

Report your bugs as follows:

  • For CE developers, post to the #portal channel on the Liferay Community Slack.
  • For DXP developers, post to the #portal channel on the Liferay Community Slack, but also open a support ticket.

Be sure to include all necessary context for your apparent build failure. A zip file with a workspace and instructions for reproduction would be simply awesome!

Bug bounty programs have bounties, right? Well most of the time, but this is an unofficial bug bounty program. Best I can offer you is some Liferay swag. And for the person that submits the most verified JDK17/JDK21 build bug reports, I'll get you a Visa gift card...

Some basic requirements:

  • You should be using Gradle 8.5 (used in new workspaces created by Blade).
  • You should be using the Liferay Workspace plugin version 12.0.0 (set this in your settings.gradle file).
  • You should be using a later dot release of JDK 17 or JDK 21 (the initial GAs won't cut it).
  • The flavor of the JDK must be on the Liferay 7.4 Compatibility Matrix (basically a JDK that passes the TCK, so that's like OpenJDK, Oracle's JDK, Zulu, etc).
  • You are using/targeting Liferay 7.4 DXP 2024 Q3 (or better) or Liferay 7.4 CE GA125 (or better).

So there you have it! Let the bug hunt begin!

Why issue this unofficial bug bounty program? The day is coming when JDK 11 will not be an option, to stay up to date with Liferay will mean having to update to JDK 17 or JDK 21. Finding and resolving JDK issues with the developer toolchain now, rather than later, will give our guys time to resolve the build issues before they become blockers in the future. So help us ensure the tools work so we can help you with an easier transition to JDK 17 or JDK 21...
upgrade jdk21 jdk17 bug bounty
Comment (5)

More Blog Entries

thumbnail

Extract and store Logs from Liferay PaaS/SaaS Services

thumbnail
Marcial Calvo Valenzuela
12 Sep
0
thumbnail

Liferay Portal 7.4 GA125 and Liferay Commerce 4.0 GA125 Release

thumbnail
Jamie Sammons
16 Oct
0
Blogs
thumbnail
Christoph Rabel
2 Months Ago - Edited

Not really a bug, but good to know:

When you try to start Liferay 7.4/2024Q2/2024Q3 with JDK 21 in IntelliJ it doesn't work. When you add the --add-opens=... flags to the VM Options you get a step farther, but then the sidecar Elasticsearch does not startup.

The "trick" is to add them as environment variables(!). You can't simply add them to the VM options, that's not sufficient. (Note: Go into setenv.bat/setenv.sh, JDK_JAVA_OPTIONS is what you need). I guess, you will need to do the same in Eclipse, I didn't try.

Please sign in to reply.
thumbnail
Orin Fink
25 Days Ago - Edited

When testing 7.4 CE GA125 and having the hebrew language support in place using "old" Hebrew local (iw_IL) we would get OSGI unsatisfied reference errors on startup, seemingly from the _objectDefinitionLocalService and possibly others.   However, if we modify the language to use the "new" Hebrew local (he_IL) we did not get the unsatisfied reference issues. Subsequently, in the shielded-container-web.xml, we would have to modify the i18n servlet mappings for the same. by making both of these changes, we would have a clean startup and support for the Hebrew / Israel local again.  However, it is also noted that the /iw/ language prefix now would be /he/ and any internal hard coded links or references to those pages would need to be updated and having an appropriate redirect for external URLs is necessary as well.

Please sign in to reply.