quarkus: java.lang.NoSuchMethodError: java.lang.String.getBytes()[B on graalvm Linux RHEL
Describe the bug I create a new quarkus 1.6.0.Final project with nothing special (only quarkus-rest-client and no code) Java 11.0.3 If I run on Linux RHEL 7 and GraalVM and I got this error :
java.lang.NoSuchMethodError: java.lang.String.getBytes()[B
Expected behavior I should run it without error (In a bigger usecase I have picocli and small amount of code, but to test I delete all the code and picocli extension and get same error)
Actual behavior If I run with GraalVM 19.3.2 I got :
15:56:43 + mvn -v
15:56:44 Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; 2019-08-27T17:06:16+02:00)
15:56:44 Maven home: /opt/mvnDockerDefault
15:56:44 Java version: 11.0.3, vendor: AdoptOpenJDK, runtime: /opt/jdk11.0.3
15:56:44 Default locale: fr_FR, platform encoding: Cp1252
15:56:44 OS name: "linux", version: "3.10.0-862.14.4.el7.x86_64", arch: "amd64", family: "unix"
15:57:55 + target/gerrit-cli-1.0.0-SNAPSHOT-runner
15:57:55 java.lang.NoSuchMethodError: java.lang.String.getBytes()[B
I I run with GraalVM 20.1.0 I got this
+ gerritCli/gerrit project --name GerritEfluidRestClient
java.lang.NoSuchMethodError: java.lang.String.getBytes()[B
at com.oracle.svm.jni.functions.JNIFunctions$Support.getMethodID(JNIFunctions.java:1095)
at com.oracle.svm.jni.functions.JNIFunctions$Support.getMethodID(JNIFunctions.java:1080)
at com.oracle.svm.jni.functions.JNIFunctions.GetMethodID(JNIFunctions.java:384)
at java.io.FileInputStream.open0(FileInputStream.java)
at java.io.FileInputStream.open(FileInputStream.java:219)
at java.io.FileInputStream.<init>(FileInputStream.java:157)
at java.io.FileInputStream.<init>(FileInputStream.java:112)
at com.oracle.svm.core.posix.linux.LinuxPhysicalMemory$PhysicalMemorySupportImpl.sizeFromCGroup(LinuxPhysicalMemory.java:83)
at com.oracle.svm.core.posix.linux.LinuxPhysicalMemory$PhysicalMemorySupportImpl.size(LinuxPhysicalMemory.java:55)
at com.oracle.svm.core.heap.PhysicalMemory.doInitialize(PhysicalMemory.java:141)
at com.oracle.svm.core.heap.PhysicalMemory.tryInitialize(PhysicalMemory.java:111)
at com.oracle.svm.core.genscavenge.HeapPolicy.samplePhysicalMemorySize(HeapPolicy.java:383)
at com.oracle.svm.core.genscavenge.ThreadLocalAllocation.runSlowPathHooks(ThreadLocalAllocation.java:143)
at com.oracle.svm.core.genscavenge.ThreadLocalAllocation.slowPathNewInstance(ThreadLocalAllocation.java:136)
at com.oracle.svm.core.posix.thread.PosixJavaThreads.setNativeName(PosixJavaThreads.java:154)
at com.oracle.svm.core.posix.thread.PosixJavaThreads.beforeThreadRun(PosixJavaThreads.java:202)
at com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:505)
at com.oracle.svm.core.posix.thread.PosixJavaThreads.pthreadStartRoutine(PosixJavaThreads.java:193)
To Reproduce Steps to reproduce the behavior:
- Create new Quarkus 1.6.0Final (same with 1.5.0.Final) project with nothing special
- Run mvn package -P native with GraalVM 19.3.1 19.3.2 or 20.1.0
- Run executable on Linux RHEL 7
Configuration Nothing in configuration file
Environment (please complete the following information):
- Output of
uname -aorver:
Linux d6eb2f26d7d0 3.10.0-862.14.4.el7.x86_64 #1 SMP Fri Sep 21 09:07:21 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux - RHEL distribution :
cat /etc/redhat-release
16:13:07 Red Hat Enterprise Linux Server release 7.5 (Maipo)
- Output of
java -version:
16:17:35 java version "1.8.0_172"
16:17:35 Java(TM) SE Runtime Environment (build 1.8.0_172-b11)
16:17:35 Java HotSpot(TM) 64-Bit Server VM (build 25.172-b11, mixed mode)
If this can be the problem ?
This is the same with
16:22:17 + java -version
16:22:17 openjdk version "11.0.3" 2019-04-16
16:22:17 OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.3+7)
16:22:17 OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.3+7, mixed mode)
I got this trace during native compilation :
16:18:17 [INFO] [org.jboss.threads] JBoss Threads version 3.1.1.Final
16:18:17 [INFO] [io.quarkus.deployment.pkg.steps.JarResultBuildStep] Building native image source jar: /mnt/mesos/sandbox/jenkins/workspace/Ftools/Fgerrit/gerritCli.validation-gerrit/gerritCli_1594649761794/target/gerrit-cli-1.0.0-SNAPSHOT-native-image-source-jar/gerrit-cli-1.0.0-SNAPSHOT-runner.jar
16:18:17 [INFO] [io.quarkus.deployment.pkg.steps.NativeImageBuildStep] Building native image from /mnt/mesos/sandbox/jenkins/workspace/Ftools/Fgerrit/gerritCli.validation-gerrit/gerritCli_1594649761794/target/gerrit-cli-1.0.0-SNAPSHOT-native-image-source-jar/gerrit-cli-1.0.0-SNAPSHOT-runner.jar
16:18:17 [INFO] [io.quarkus.deployment.pkg.steps.NativeImageBuildStep] Running Quarkus native-image plugin on GraalVM Version 19.3.2 CE
16:18:17 [INFO] [io.quarkus.deployment.pkg.steps.NativeImageBuildStep] /opt/graalvm-ce-java11-19.3.2/bin/native-image -J-Djava.util.logging.manager=org.jboss.logmanager.LogManager -J-Duser.language=fr -J-Dfile.encoding=Cp1252 --initialize-at-build-time= -H:InitialCollectionPolicy=com.oracle.svm.core.genscavenge.CollectionPolicy$BySpaceAndTime -H:+JNI -jar gerrit-cli-1.0.0-SNAPSHOT-runner.jar -H:FallbackThreshold=0 -H:+ReportExceptionStackTraces -H:-AddAllCharsets -H:-IncludeAllTimeZones -H:EnableURLProtocols=http --no-server -H:-UseServiceLoaderFeature -H:+StackTrace gerrit-cli-1.0.0-SNAPSHOT-runner
16:18:22 [gerrit-cli-1.0.0-SNAPSHOT-runner:890] classlist: 3 736,78 ms
16:18:23 [gerrit-cli-1.0.0-SNAPSHOT-runner:890] (cap): 1 069,20 ms
16:18:24 [gerrit-cli-1.0.0-SNAPSHOT-runner:890] setup: 2 717,60 ms
16:18:37 16:18:36,361 INFO [org.jbo.threads] JBoss Threads version 3.1.1.Final
16:18:47 [gerrit-cli-1.0.0-SNAPSHOT-runner:890] (typeflow): 8 406,74 ms
16:18:47 [gerrit-cli-1.0.0-SNAPSHOT-runner:890] (objects): 11 689,21 ms
16:18:47 [gerrit-cli-1.0.0-SNAPSHOT-runner:890] (features): 555,87 ms
16:18:47 [gerrit-cli-1.0.0-SNAPSHOT-runner:890] analysis: 21 525,62 ms
16:18:48 [gerrit-cli-1.0.0-SNAPSHOT-runner:890] (clinit): 528,00 ms
16:18:48 [gerrit-cli-1.0.0-SNAPSHOT-runner:890] universe: 1 460,26 ms
16:18:50 [gerrit-cli-1.0.0-SNAPSHOT-runner:890] (parse): 1 718,08 ms
16:18:54 [gerrit-cli-1.0.0-SNAPSHOT-runner:890] (inline): 4 164,04 ms
16:19:12 [gerrit-cli-1.0.0-SNAPSHOT-runner:890] (compile): 15 951,48 ms
16:19:12 [gerrit-cli-1.0.0-SNAPSHOT-runner:890] compile: 23 601,73 ms
16:19:15 [gerrit-cli-1.0.0-SNAPSHOT-runner:890] image: 3 229,66 ms
16:19:17 [gerrit-cli-1.0.0-SNAPSHOT-runner:890] write: 1 703,18 ms
16:19:17 [gerrit-cli-1.0.0-SNAPSHOT-runner:890] [total]: 58 407,90 ms
16:19:17 [INFO] [io.quarkus.deployment.pkg.steps.NativeImageBuildStep] Execute [objcopy, --strip-debug, /mnt/mesos/sandbox/jenkins/workspace/Ftools/Fgerrit/gerritCli.validation-gerrit/gerritCli_1594649761794/target/gerrit-cli-1.0.0-SNAPSHOT-runner]
16:19:17 [INFO] [io.quarkus.deployment.QuarkusAugmentor] Quarkus augmentation completed in 60736ms
- GraalVM version (if different from Java): 19.3.2
- Quarkus version or git rev: 1.6.0.Final
- Build tool (ie. output of
mvnw --versionorgradlew --version): mvn 3.6.2 (same with 3.6.3)
16:17:35 + mvn -v
16:17:35 Apache Maven 3.6.2 (40f52333136460af0dc0d7232c0dc0bcf0d9e117; 2019-08-27T17:06:16+02:00)
16:17:35 Maven home: /opt/mvnDockerDefault
16:17:35 Java version: 11.0.3, vendor: AdoptOpenJDK, runtime: /opt/jdk11.0.3
16:17:35 Default locale: fr_FR, platform encoding: Cp1252
16:17:35 OS name: "linux", version: "3.10.0-862.14.4.el7.x86_64", arch: "amd64", family: "unix"
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 25 (16 by maintainers)
Hi
On a project without resteasy the hack : A workaround could be to define an @AutomaticFeature to register the String#getBytes() method for JNI access Works for me now with graalvm 20.2
But on a project with resteasy it does not, I have this error (in a docker container) :
I have add this here : https://github.com/tcollignon/example-quarkus-10682