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.
