Ask - Test

Hello, we recently updated an existing liferay workspace to using gralde8.5 and azul openJDK17, following the official tutorial (https://learn.liferay.com/ja/w/dxp/liferay-development/tooling/liferay-workspace/configuring-liferay-workspace). However, the arquillian integration test tasks ( gradle: testIntegration ) failed due to JDK17's accessible restriction.

environment

• gradle8.5
• zulu-JDK17
• liferay gradle plugin: 10.1.0
• liferay 2024q3.7

Problem

• the testIntegration task failed because:

Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field static final java.lang.invoke.MethodHandles$Lookup java.lang.invoke.MethodHandles$Lookup.IMPL_LOOKUP accessible: module java.base does not "opens java.lang.invoke" to unnamed module @3155a7c7

• by verifying the log we found that

Caused by: java.lang.ExceptionInInitializerError
	at com.liferay.petra.string.StringBundler$StringConcatenator.<clinit>(StringBundler.java:470)
	at com.liferay.petra.string.StringBundler._toStringStringConcatenator(StringBundler.java:304)

• the source code says (https://github.com/liferay/liferay-portal/blob/2133193931be02e06abca82835315ed6aee23349/modules/core/petra/petra-string/src/main/java/com/liferay/petra/string/StringBundler.java#L370)

line370:    field.setAccessible(true);

Thus we considered it was due to the restriction of JDK17. However, if we check the tomcat's setenv.sh under the `[workspace]/bundles/tomcat-xxxx/bin/` folder we could see that:

JDK_JAVA_OPTIONS="$JDK_JAVA_OPTIONS --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/sun.net.www.protocol.http=ALL-UNNAMED --add-opens=java.base/sun.net.www.protocol.https=ALL-UNNAMED --add-opens=java.base/sun.util.calendar=ALL-UNNAMED --add-opens=jdk.zipfs/jdk.nio.zipfs=ALL-UNNAMED"
 

Besides, the gradlew's log shown that:

NOTE: Picked up JDK_JAVA_OPTIONS:  --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/sun.net.www.protocol.http=ALL-UNNAMED --add-opens=java.base/sun.net.www.protocol.https=ALL-UNNAMED --add-opens=java.base/sun.util.calendar=ALL-UNNAMED --add-opens=jdk.zipfs/jdk.nio.zipfs=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED

Thus the configuration was just the same as the recommended one at the Liferay's blog: (https://liferay.dev/blogs/-/blogs/jdk-17-jdk-21-solving-module-does-not-opens-to-unnamed-module). 

We wonder if there is anything we missed? Looking for your kind help. Thanks.