[MAGNOLIA-8104] Verify and add Java 16 to certified stack Created: 06/Oct/20  Updated: 14/Oct/21  Resolved: 19/May/21

Status: Closed
Project: Magnolia
Component/s: None
Affects Version/s: None
Fix Version/s: 6.2.9

Type: Task Priority: Neutral
Reporter: Ervin Vystup Assignee: Quach Hao Thien
Resolution: Done Votes: 0
Labels: VN-Implementation, maintenance
Remaining Estimate: 0d
Time Spent: 13.5d
Original Estimate: Not Specified

Attachments: Text File dev-1630_java16opnJDK_linuxMint20_1.txt     PNG File m6.2-java16.png    
Issue Links:
Cloners
is cloned by MAGNOLIA-8164 Verify and add Java 17 (LTS) to certi... Closed
Relates
relates to DOCU-2135 JDK14?? Closed
dependency
depends upon BUILD-460 Update libraries for Java 16 Closed
is depended upon by MAGNOLIA-8004 Compatibility with JDK 15 / Tomcat 9.... Closed
documentation
to be documented by MAGNOLIA-8097 DOC: Add Java 16 to 6.2 certified sta... Closed
relation
Template:
Acceptance criteria:
Empty
Task DoR:
Empty
Release notes required:
Yes
Documentation update required:
Yes
Date of First Response:
Story Points: 13

 Description   

Certified stack:

"JDK 16 reached General Availability on 16 March 2021." https://openjdk.java.net/projects/jdk/16/

Checklist

General Java 16 compatibility:

Run ITs on Jenkins with Java 16

 recursive publication of assets, restoring version
 groovy scripts
 uploading asset zip file
 publication & workflow
 imaging renditions
resource hot-fixing
long-running actions w/ scheduler
importing/exporting XML bootstraps
backup & restore
component personalization & preview
cloud validation (cloud only supports Java LTS releases)
javascript-models
verify addons (bump addon-tests containers's Java to version 16



 Comments   
Comment by Martin Drápela [ 06/Oct/20 ]

HI, tried quickly (and informally) roll out 6.2.3ce demo webapp on
linux mint with

openjdk 15 2020-09-15
OpenJDK Runtime Environment (build 15+36-1562)
OpenJDK 64-Bit Server VM (build 15+36-1562, mixed mode, sharing)

and the server fails to start with this message

2020-10-06 09:01:27,394 ERROR info.magnolia.init.MagnoliaServletContextListener : Oops, Magnolia could not be started
 java.lang.NullPointerException: Cannot invoke "com.google.inject.Injector.getBindings()" because "target" is null

Comment by Martin Drápela [ 07/Oct/20 ]

AdoptOpenJDK15 - same issue (6.2.3CE demo):

2020-10-07 09:24:32,836 ERROR info.magnolia.init.MagnoliaServletContextListener : Oops, Magnolia could not be started
{{ java.lang.NullPointerException: Cannot invoke "com.google.inject.Injector.getBindings()" because "target" is null}}
{{ at info.magnolia.objectfactory.guice.GuiceUtils.hasExplicitBindingFor(GuiceUtils.java:158) ~[magnolia-core-6.2.3.jar:?]}}
{{ at info.magnolia.objectfactory.guice.GuiceUtils.hasExplicitBindingFor(GuiceUtils.java:152) ~[magnolia-core-6.2.3.jar:?]}}
{{ at info.magnolia.objectfactory.guice.GuiceComponentProvider.getComponent(GuiceComponentProvider.java:107) ~[magnolia-core-6.2.3.jar:?]}}

openjdk version "15" 2020-09-15
OpenJDK Runtime Environment AdoptOpenJDK (build 15+36)
OpenJDK 64-Bit Server VM AdoptOpenJDK (build 15+36, mixed mode, sharing)

Comment by Ondrej Chytil [ 12/Jan/21 ]

On Mac OS Catalina and Oracle JDK 15.0.1 I'm getting the same error as Martin with Magnolia 6.2.5.

Comment by Federico Grilli [ 28/Apr/21 ]

Thanks sang.ngo for the investigation. The error about JS models module makes sense indeed, Nashorn JS engine having been removed from JDK 15 onwards. 

Comment by Mikaël Geljić [ 30/Apr/21 ]

First findings from my side:

That's all I needed for a basic CE setup at least, there might be more for DX Core. I didn't face the same Guice issue, but mostly the two stack traces below. In my case it was easy to trace back to byte-buddy.

--- AT STARTUP
2021-04-29 15:54:06,630 ERROR info.magnolia.event.SimpleEventBus                : Exception caught when dispatching info.magnolia.module.PopulateModulesEvent with info.magnolia.config.module.ModuleConfigurationRegistry$$Lambda$267/0x000000080126e8b0 eventHandler.
java.lang.IllegalArgumentException: Could not create type
	at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:154) ~[byte-buddy-1.10.8.jar:?]
        ...
Caused by: java.lang.UnsupportedOperationException: Cannot define class using reflection: Unsupported class file major version 60
	at net.bytebuddy.dynamic.loading.ClassInjector$UsingReflection$Dispatcher$Initializable$Unavailable.defineClass(ClassInjector.java:409) ~[byte-buddy-1.10.8.jar:?]

--- AT LOGIN
2021-04-29 15:54:17,623 ERROR info.magnolia.cms.filters.ServletDispatchingFilter: Unable to load servlet class info.magnolia.admincentral.AdmincentralServlet : Failed to initialise UI IoC infrastructure
javax.servlet.ServletException: Failed to initialise UI IoC infrastructure
	at info.magnolia.admincentral.AdmincentralServlet.servletInitialized(AdmincentralServlet.java:101) ~[magnolia-admincentral-6.2.8-SNAPSHOT.jar:?]
        ...
Caused by: java.lang.IllegalArgumentException: Could not create type
	at net.bytebuddy.TypeCache.findOrInsert(TypeCache.java:154) ~[byte-buddy-1.10.8.jar:?]
	...
Caused by: java.lang.UnsupportedOperationException: Cannot define class using reflection: Unsupported class file major version 60
	at net.bytebuddy.dynamic.loading.ClassInjector$UsingReflection$Dispatcher$Initializable$Unavailable.defineClass(ClassInjector.java:409) ~[byte-buddy-1.10.8.jar:?]

Comment by Quach Hao Thien [ 14/May/21 ]

Cannot move forward due to failed test cases on platform/ui: https://jenkins.magnolia-cms.com/job/platform/job/ui/job/master/443/consoleFull

Comment by Mikaël Geljić [ 18/May/21 ]

Yes, I'd be cautious about the Guice 5 upgrade (see also migration notes - https://github.com/google/guice/wiki/Guice501#migrating-from-423), especially in 6.2.

I came to the same conclusion that the Guice issue is highly likely caused by javascript-models, although the stack trace tells us nothing about that.
The way Guice works, is that it will only realize something is wrong when we actually build the injector. My suspicion is that a component mapping leads either to a class not found, or one that depends on Nashorn, either via injection, field init or similar that would resolve in a linking error. And if constructing the injector fails, then we only see the NPE as a side-effect.

We should try to find ways to preemptively scan component configurations and improve logs when that happens. ComponentProviderConfigurationBuilder#classForName seemed like a compelling place to do that, but the checks need to be more sophisticated than mere class-loading (see potential causes above).

Alternatively, maybe we can circumvent this by identifying if some javascript-models components are not lazy and should be?

Comment by Federico Grilli [ 18/May/21 ]

Based on Mika's assumptions above, if we exclude javascript-models, basically the current codebase would be compatible with JDK 16?

Generated at Mon Feb 12 04:29:41 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.