Support both GraalVM 19.3.1 and 20.0.0 #7269

gwenneg · 2020-02-18T23:37:30Z

As mentioned by @gastaldi on Zulip, GraalVM 20.0 is now available: https://www.graalvm.org/docs/release-notes/20_0/

@cescoffier We'll need two new ubi-quarkus-native-image (JDK 8 and 11) for that version, but I suppose this has a lower priority than the Mutiny integration since 1.3.0.CR1 is getting close.

The text was updated successfully, but these errors were encountered:

gwenneg · 2020-02-19T08:36:25Z

I'll start running locally the complete Quarkus build in native mode with GraalVM 20.0 tonight to identify possible issues ASAP (unless the ubi images are ready by then).

gsmet · 2020-02-19T08:50:55Z

FYI quarkusio/quarkus-images#55

iwangxiaodong · 2020-02-20T05:30:04Z

I use GraalVM 20.0.0 + io.quarkus:quarkus-bom:1.3.0.Alpha2, Output error:

Error: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: type is not available in this platform: io.quarkus.runtime.graal.DiagnosticPrinter$Target_PosixJavaThreads
Trace:
at parsing io.quarkus.runtime.graal.DiagnosticPrinter.printDiagnostics(DiagnosticPrinter.java:46)
Call path from entry point to io.quarkus.runtime.graal.DiagnosticPrinter.printDiagnostics(PrintStream):
at io.quarkus.runtime.graal.DiagnosticPrinter.printDiagnostics(DiagnosticPrinter.java:29)
at io.quarkus.runtime.Application$2.handle(Application.java:209)
at sun.misc.Signal$InternalMiscHandler.handle(Signal.java:198)
at jdk.internal.misc.Signal$1.run(Signal.java:220)
at java.lang.Thread.run(Thread.java:834)
at com.oracle.svm.core.thread.JavaThreads.threadStartRoutine(JavaThreads.java:527)
at com.oracle.svm.core.windows.WindowsJavaThreads.osThreadStartRoutine(WindowsJavaThreads.java:138)
at com.oracle.svm.core.code.IsolateEnterStub.WindowsJavaThreads_osThreadStartRoutine_4bc03aa26f8cdfc97ebd54050e8ae4bce1023851(generated:0)
at com.oracle.graal.pointsto.constraints.UnsupportedFeatures.report(UnsupportedFeatures.java:129)
at com.oracle.svm.hosted.NativeImageGenerator.runPointsToAnalysis(NativeImageGenerator.java:738)
... 8 more

Because Platform.WINDOWS.class? @Platforms({ Platform.LINUX.class, Platform.DARWIN.class })

emmanuelbernard · 2020-02-20T08:22:51Z

@gwenneg and all. The idea would be to be able to support both 20 and 19.3.x in Quarkus in parallel (like we briefly did 19.2 and 19.3) if at all possible. The reason is 19.3 is LTS.

gwenneg · 2020-02-20T09:25:41Z

@iwangxiaodong Thanks for reporting this! I'll run some Windows native tests tonight and see if I can reproduce it locally.

@emmanuelbernard Ok, I'll make the required changes and tests to try to support both versions.

gwenneg · 2020-02-20T20:58:03Z

I will centralize the double compatibility status and tests results here:

	svm:19.3.1 (SDK)	svm:20.0.0 (SDK)
ubi-quarkus-native-image:19.3.1-java8	Current `master` branch	#7321 - Tests ✅
ubi-quarkus-native-image:19.3.1-java11	Current `master` branch	#7321 - Tests ✅ part 1 & part 2
ubi-quarkus-native-image:20.0.0-java8	#7320 - Tests ✅	#7291 - Tests ✅
ubi-quarkus-native-image:20.0.0-java11	#7320 - Tests ✅ part 1 & part 2	#7291 - Tests ✅ part 1 & part2

gwenneg · 2020-02-21T10:02:45Z

The JDK 8 and 11 native tests were successful for all GraalVM SDK and Docker image combinations.

I'll take a closer look at the logs tonight just to make sure we don't miss an issue that would happen without making the build fail. I didn't have time to run the Windows test yesterday so I'll also do this tonight.

gwenneg · 2020-02-21T23:05:21Z

I didn't see anything suspicious in the logs.

I tried to run a local GraalVM 20.0.0 in Windows, but after tons of Windows components downloads, my environment still doesn't seem to be GraalVM-ready... I'll try again tomorrow.

iwangxiaodong · 2020-02-22T01:53:18Z

@gwenneg

GraalVM 20.0.0 in Windows 10 x64:

Install Visual Studio Community 2017 (C++ components)

SET GRAALVM_HOME="G:...\graalvm-ce-java11-20.0.0"
SET PATH="%PATH%;%GRAALVM_HOME%\bin"
gu available
gu install native-image

cd C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Visual Studio 2017\Visual Studio Tools\VC
Click "x64 Native Tools Command Prompt for VS 2017"
set JAVA_TOOL_OPTIONS="-Dfile.encoding=UTF-8"
G:\gradle-6.1.1-bin\gradle-6.1.1\bin\gradle clean
G:\gradle-6.1.1-bin\gradle-6.1.1\bin\gradle --configure-on-demand -x check buildNative

gwenneg · 2020-03-01T22:45:03Z

I tried building Quarkus with GraalVM 20.0.0 and both Visual Studio Community 2017 and 2019 (including all C++ components) but never got past an error about a missing unistd.h. There are several GraalVM issues (some are open, others are closed) that mention this problem but I couldn't find any solution so far...

Do you have an idea about what could be the problem on my Windows environment? This is my first time using GraalVM on Windows so I might be missing something.

iwangxiaodong · 2020-03-02T01:18:37Z

@gwenneg

Write text file can fix missing unistd.h :

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\include\unistd.h

#ifndef _UNISTD_H
#define _UNISTD_H
#include <io.h>
#include <process.h>
#endif /* _UNISTD_H */

gwenneg · 2020-03-02T22:03:13Z

Thanks @iwangxiaodong! I was finally able to build Quarkus with GraalVM 20.0 on Windows.

I can see the error you had with io.quarkus.runtime.graal.DiagnosticPrinter$Target_PosixJavaThreads, but also another one:

Error: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: No instances of sun.nio.ch.Iocp are allowed in the image heap as this class should be initialized at image runtime. Object has been initialized without the native-image initialization instrumentation and the stack trace can't be tracked.
Trace:
        at parsing sun.nio.ch.WindowsAsynchronousFileChannelImpl.open(WindowsAsynchronousFileChannelImpl.java:105)
Call path from entry point to sun.nio.ch.WindowsAsynchronousFileChannelImpl.open(FileDescriptor, boolean, boolean, ThreadPool):
        at sun.nio.ch.WindowsAsynchronousFileChannelImpl.open(WindowsAsynchronousFileChannelImpl.java:104)
        at sun.nio.fs.WindowsChannelFactory.newAsynchronousFileChannel(WindowsChannelFactory.java:215)
        at sun.nio.fs.WindowsFileSystemProvider.newAsynchronousFileChannel(WindowsFileSystemProvider.java:145)
        at java.nio.channels.AsynchronousFileChannel.open(AsynchronousFileChannel.java:253)
        at io.vertx.core.file.impl.AsyncFileImpl.<init>(AsyncFileImpl.java:97)
        at io.vertx.core.file.impl.FileSystemImpl.doOpen(FileSystemImpl.java:903)
        at io.vertx.core.file.impl.FileSystemImpl$18.perform(FileSystemImpl.java:897)
        at io.vertx.core.file.impl.FileSystemImpl$18.perform(FileSystemImpl.java:894)
        at io.vertx.core.file.impl.FileSystemImpl$BlockingAction.handle(FileSystemImpl.java:974)
        at io.vertx.core.file.impl.FileSystemImpl$BlockingAction.handle(FileSystemImpl.java:955)
        at io.vertx.core.impl.ContextImpl.lambda$executeBlocking$2(ContextImpl.java:316)
        at io.vertx.core.impl.ContextImpl$$Lambda$771/0x00000007c1b7e840.run(Unknown Source)
        at com.oracle.svm.core.jdk.RuntimeSupport.executeHooks(RuntimeSupport.java:144)
        at com.oracle.svm.core.jdk.RuntimeSupport.executeStartupHooks(RuntimeSupport.java:89)
        at com.oracle.svm.core.JavaMainWrapper.runCore(JavaMainWrapper.java:143)
        at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:186)
        at com.oracle.svm.core.code.IsolateEnterStub.JavaMainWrapper_run_5087f5482cc9a6abc971913ece43acb471d2631b(generated:0)

I'm now trying trying to fix these. Adding Platform.WINDOWS.class does not help unfortunately.

iwangxiaodong · 2020-03-03T02:30:30Z

@gwenneg

Click "x64 Native Tools Command Prompt for VS 2017"
In Prompt Console execute: gradle --configure-on-demand -x check buildNative
Maybe can fix：No instances of sun.nio.ch.Iocp are allowed

Good luck.

gwenneg · 2020-03-03T06:52:06Z

The issue comes from the following Quarkus code which is only compatible with Linux/macOS for now:

quarkus/core/runtime/src/main/java/io/quarkus/runtime/graal/DiagnosticPrinter.java

Lines 46 to 50 in 3fbdbc3

    
           if (Target_PosixJavaThreads.hasThreadIdentifier(thread)) { 
        
               final long nativeId = Target_PosixJavaThreads.getPthreadIdentifier(thread).rawValue(); 
        
               w.print("0x"); 
        
               w.println(Long.toHexString(nativeId)); 
        
           } else {

I tried a few things without success yesterday, I'll try again tonight.

gwenneg · 2020-03-03T22:06:57Z

I may have a solution for the DiagnosticPrinter issue. The Quarkus CI is currently running on my fork, I'll submit a PR here if it is successful.

gwenneg · 2020-03-03T23:29:09Z

I have an idea of a possible fix for the vertx issue mentioned above. I'll try to submit a PR about it tomorrow.

iwangxiaodong · 2020-03-03T23:29:41Z

@gwenneg

Congratulations!

thejibz · 2020-03-04T09:00:24Z

@gwenneg
I was also struggling with this exact same issue ! Tried some hacky patch in the .class ... Thank you for your PR, hope it will be accepted soon !

iwangxiaodong · 2020-03-06T14:30:41Z

@gwenneg

quarkus 1.3.0.CR1 and GraalVM 20.0.0 on Windows

c = (HttpURLConnection) new URL(url).openConnection();
get response code ... Runtime

Caused by: 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.net.Inet6AddressImpl.lookupAllHostAddr(Inet6AddressImpl.java)
at java.net.InetAddress$PlatformNameService.lookupAllHostAddr(InetAddress.java:929)
at java.net.InetAddress.getAddressesFromNameService(InetAddress.java:1515)
at java.net.InetAddress$NameServiceAddresses.get(InetAddress.java:848)
at java.net.InetAddress.getAllByName0(InetAddress.java:1505)
at java.net.InetAddress.getAllByName(InetAddress.java:1364)
at java.net.InetAddress.getAllByName(InetAddress.java:1298)
at java.net.InetAddress.getByName(InetAddress.java:1248)
at java.net.InetSocketAddress.(InetSocketAddress.java:220)
at sun.net.NetworkClient.doConnect(NetworkClient.java:182)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:474)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:569)
at sun.net.www.protocol.https.HttpsClient.(HttpsClient.java:265)
at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:372)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:191)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect0(HttpURLConnection.java:1187)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:1081)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:177)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1587)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1515)
at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:527)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:334)

gwenneg · 2020-03-06T15:13:41Z

Thanks for reporting this new issue @iwangxiaodong. I'll take a look at it in a few hours.

ctomc · 2020-03-06T21:24:12Z

the unistd.h issue when building on windows is fixed by upgrading to wildfly-common 1.5.4.Final-format-001 that was just released by @dmlloyd

gwenneg · 2020-03-07T22:27:04Z

@iwangxiaodong I can't reproduce locally the HttpURLConnection issue you posted above. Could you please give us more details about it or even better provide us with a minimal reproducer?

iwangxiaodong · 2020-03-08T03:49:53Z

@gwenneg

Only used quarkus-resteasy.

buildNative - Build time is Successful, runtime is Internal Server Error:
Caused by: java.lang.NoSuchMethodError: java.lang.String.getBytes()[B

Source code - example.zip

Visit url http://localhost:8080/demo

Xabin · 2020-03-09T06:29:01Z

@iwangxiaodong
I was able to both build and run your example without issues.

However, during build I got an error which marked the build as failed, even though it produced a correctly working executable:

Execution failed for task ':buildNative'.

io.quarkus.builder.BuildException: Build failure: Build failed due to errors
[error]: Build step io.quarkus.deployment.pkg.steps.NativeImageBuildStep#build threw an exception: java.lang.RuntimeException: Failed to build native image
at io.quarkus.deployment.pkg.steps.NativeImageBuildStep.build(NativeImageBuildStep.java:342)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at io.quarkus.deployment.ExtensionLoader$2.execute(ExtensionLoader.java:938)
at io.quarkus.builder.BuildContext.run(BuildContext.java:273)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:2027)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1551)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1442)
at java.base/java.lang.Thread.run(Thread.java:834)
at org.jboss.threads.JBossThread.run(JBossThread.java:479)
Caused by: java.nio.file.NoSuchFileException: C:\dev\repo\quarkus-example\build\quarkus-example-unspecified-native-image-source-jar\quarkus-example-unspecified-runner
at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:85)
at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
at java.base/sun.nio.fs.WindowsFileAttributeViews$Basic.readAttributes(WindowsFileAttributeViews.java:53)
at java.base/sun.nio.fs.WindowsFileAttributeViews$Basic.readAttributes(WindowsFileAttributeViews.java:38)
at java.base/sun.nio.fs.WindowsFileSystemProvider.readAttributes(WindowsFileSystemProvider.java:198)
at java.base/java.nio.file.Files.readAttributes(Files.java:1763)
at java.base/java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:225)
at java.base/java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:276)
at java.base/java.nio.file.FileTreeWalker.walk(FileTreeWalker.java:322)
at java.base/java.nio.file.Files.walkFileTree(Files.java:2716)
at io.quarkus.bootstrap.util.IoUtils.copy(IoUtils.java:98)
at io.quarkus.deployment.pkg.steps.NativeImageBuildStep.build(NativeImageBuildStep.java:336)
... 12 more

It seems to expect the build process to produce a Linux-style binary (no file ending) when it actually ends with .exe. I haven't looked into what the code actually does, though.

ctomc · 2020-03-09T08:39:25Z

This looks like same issue maven plugin had.
On windows resulting executable has .exe suffix while code that is coping resulting exe to final destination is trying to copy it without suffix and Doesn't find it.

Xabin · 2020-03-09T08:47:29Z

@ctomc Ah, I see you already fixed that. Good job :) #7663

iwangxiaodong · 2020-03-09T08:52:50Z

@Xabin @ctomc

Build time is Successful, runtime is Internal Server Error

Visit url http://localhost:8080/demo Caused by: java.lang.NoSuchMethodError: java.lang.String.getBytes()[B

ctomc · 2020-03-09T08:53:59Z

For same code that that works under jvm?

iwangxiaodong · 2020-03-09T08:54:46Z

@ctomc yes!

jvm is Successful

iwangxiaodong · 2020-03-12T14:28:00Z

@gwenneg @ctomc @Xabin

Help me build above example.zip on Windows with GraalVM Java 11（quarkus 1.3.0.CR2）, Please.

reproduce：
Caused by: java.lang.NoSuchMethodError: java.lang.String.getBytes()[B

gwenneg · 2020-03-12T15:01:39Z

Sorry for not posting an update here @iwangxiaodong.

I tried to reproduce your issue without success 3 days ago. I'll try again in a few hours.

geoand · 2020-03-17T10:39:11Z

Hasn't this one been implemented already?

gwenneg · 2020-03-17T20:03:48Z

@geoand: The double GraalVM support is done. We should probably close this issue and deal with @iwangxiaodong's problem in a new one.

newk5 · 2020-04-08T09:50:26Z

I have an idea of a possible fix for the vertx issue mentioned above. I'll try to submit a PR about it tomorrow.

@gwenneg any progress on this?

I'm getting the exact same vertx error when trying to compile to native on windows Graalvm 20.0 JDK8 with Quarkus 1.3.1 Final.

gsmet · 2020-04-08T09:52:32Z

@newk5 if you have an error with 1.3.1.Final, please create a reproducer with the stacktrace and a reproducer. We have no knowledge of remaining issues so if there is one, better have a separate issue for it.

Thanks!

newk5 · 2020-04-08T12:33:42Z

@newk5 if you have an error with 1.3.1.Final, please create a reproducer with the stacktrace and a reproducer. We have no knowledge of remaining issues so if there is one, better have a separate issue for it.

Thanks!

@gsmet

I created a sample here that reproduces the issue: https://github.com/newk5/quarkus-jsf
It uses the new JSF MyFaces extension: https://github.com/apache/myfaces/tree/master/extensions/quarkus/showcase

GraalVM Build used: graalvm-ce-java8-windows-amd64-20.0.0
Command used to compile: cmd /c 'call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\vcvars64.bat" && mvnw package -Pnative'

I'm on Windows 10 64bit

The stacktrace is exactly as posted above:

Error: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: No instances of sun.nio.ch.Iocp are allowed in the image heap as this class should be initialized at image runtime. To see how this object got instantiated use -H:+TraceClassInitialization.
Detailed message:
Trace:
        at parsing sun.nio.ch.WindowsAsynchronousFileChannelImpl.open(WindowsAsynchronousFileChannelImpl.java:105)
Call path from entry point to sun.nio.ch.WindowsAsynchronousFileChannelImpl.open(FileDescriptor, boolean, boolean, ThreadPool):
        at sun.nio.ch.WindowsAsynchronousFileChannelImpl.open(WindowsAsynchronousFileChannelImpl.java:104)
        at sun.nio.fs.WindowsChannelFactory.newAsynchronousFileChannel(WindowsChannelFactory.java:208)
        at sun.nio.fs.WindowsFileSystemProvider.newAsynchronousFileChannel(WindowsFileSystemProvider.java:140)
        at java.nio.channels.AsynchronousFileChannel.open(AsynchronousFileChannel.java:248)
        at io.vertx.core.file.impl.AsyncFileImpl.<init>(AsyncFileImpl.java:97)
        at io.vertx.core.file.impl.WindowsFileSystem.doOpen(WindowsFileSystem.java:71)
        at io.vertx.core.file.impl.FileSystemImpl$18.perform(FileSystemImpl.java:897)
        at io.vertx.core.file.impl.FileSystemImpl$18.perform(FileSystemImpl.java:894)
        at io.vertx.core.file.impl.FileSystemImpl$BlockingAction.handle(FileSystemImpl.java:974)
        at io.vertx.core.file.impl.FileSystemImpl$BlockingAction.handle(FileSystemImpl.java:955)
        at io.vertx.core.impl.ContextImpl.lambda$executeBlocking$2(ContextImpl.java:316)
        at io.vertx.core.impl.ContextImpl$$Lambda$207/1933228522.run(Unknown Source)
        at com.oracle.svm.core.jdk.RuntimeSupport.executeHooks(RuntimeSupport.java:144)
        at com.oracle.svm.core.jdk.RuntimeSupport.executeStartupHooks(RuntimeSupport.java:89)
        at com.oracle.svm.core.JavaMainWrapper.runCore(JavaMainWrapper.java:143)
        at com.oracle.svm.core.JavaMainWrapper.run(JavaMainWrapper.java:186)
        at com.oracle.svm.core.code.IsolateEnterStub.JavaMainWrapper_run_5087f5482cc9a6abc971913ece43acb471d2631b(generated:0)

I also had to add:

quarkus.native.additional-build-args=--allow-incomplete-classpath

to the application.properties, otherwise, in addition to the error above, I also got this one:

Error: com.oracle.graal.pointsto.constraints.UnresolvedElementException: Discovered unresolved method during parsing: java.nio.ByteBuffer.flip(). To diagnose the issue you can use the --allow-incomplete-classpath option. The missing method is then reported at run time when it is accessed the first time.
Trace:
        at parsing org.apache.myfaces.view.facelets.util.Classpath.decodeFilesystemUrl(Classpath.java:376)
Call path from entry point to org.apache.myfaces.view.facelets.util.Classpath.decodeFilesystemUrl(String):
        at org.apache.myfaces.view.facelets.util.Classpath.decodeFilesystemUrl(Classpath.java:347)
        at org.apache.myfaces.view.facelets.util.Classpath._getAlternativeJarFile(Classpath.java:296)
        at org.apache.myfaces.view.facelets.util.Classpath._searchResource(Classpath.java:87)
        at org.apache.myfaces.view.facelets.util.Classpath.search(Classpath.java:69)
        at org.apache.myfaces.resource.DefaultResourceLibraryContractsProvider.getClassloaderResourceLibraryContracts(DefaultResourceLibraryContractsProvider.java:81)
        at org.apache.myfaces.config.FacesConfigurator.configureRuntimeConfig(FacesConfigurator.java:974)
        at org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:502)
        at org.apache.myfaces.webapp.AbstractFacesInitializer.buildConfiguration(AbstractFacesInitializer.java:389)
        at com.oracle.svm.reflect.AbstractFacesInitializer_buildConfiguration_77775dac3b1281e6381c1ec2242b309017e37a5d_2702.invoke(Unknown Source)
        at java.lang.reflect.Method.invoke(Method.java:498)
        at com.rometools.rome.feed.impl.EqualsBean.beanEquals(EqualsBean.java:145)
        at com.rometools.rome.feed.impl.EqualsBean.equals(EqualsBean.java:107)
        at java.util.HashMap.getNode(HashMap.java:579)
        at java.util.HashMap.get(HashMap.java:557)
        at com.oracle.svm.jni.access.JNIReflectionDictionary.getFieldNameByID(JNIReflectionDictionary.java:278)
        at com.oracle.svm.jni.functions.JNIFunctions.ToReflectedField(JNIFunctions.java:856)
        at com.oracle.svm.core.code.IsolateEnterStub.JNIFunctions_ToReflectedField_80d8233579d5215df0227b770e5c01228a0de9b9(generated:0)

dmlloyd · 2020-04-08T12:42:54Z

This error happens when your application or one of its artifacts was built using Java 9 or later using source/target of 8 and then run it on Java 8 (or compile it on GraalVM 8). You can correct the problem in one of two ways:

Use release instead of source/target when you build
Use GraalVM for Java 11 instead

newk5 · 2020-04-08T13:07:46Z

This error happens when your application or one of its artifacts was built using Java 9 or later using source/target of 8 and then run it on Java 8 (or compile it on GraalVM 8). You can correct the problem in one of two ways:

Use release instead of source/target when you build

Use GraalVM for Java 11 instead

Yea I read about that java.nio.ByteBuffer.flip() error being related to being compiled on java9 or above and I have tried to use the --release flag before but I got this error:
maven-compiler-plugin:3.8.1:compile (default-compile) on project quarkus-jsf: Fatal error compiling: invalid flag: --release ->

My app was compiled with java8. I'm not sure if any of the artifacts specified on my pom.xml were built on java9 or above though. I guess I'll try GraalVM with java11 and see how that goes.

(I believe the vertx error is not related to this though, that is a separate issue)

newk5 · 2020-04-09T00:38:28Z

@dmlloyd @gsmet
Much to my surprise, it seems that when using a Java11 GraalVM CE build, I was able to compile it just fine. It fixed both of those errors (vertx one and the ByteBuffer.flip).

I found 2 issues after that though:

1 - When accessing the page on the browser I got this error:

I fixed it by adding this to my application.properties:
quarkus.native.additional-build-args=-H:IncludeResourceBundles=sun.util.resources.TimeZoneNames

2 - When I run the .exe there is a vertx cache folder created at:

C:\Users\Carlos\AppData\Local\Temp\vertx-cache

but when I close the .exe (by clicking the cmd window 'X' button), this folder is not deleted, which makes it so that the next time I try to run the .exe, it fails with this error:

If I manually delete the folder created on the vertx-cache directory, I can once again run the .exe.

One thing I noticed was that if instead of closing the .exe by closing the cmd window 'X' button I do Ctrl+C instead inside the cmd window, the vertx cache folder is correctly deleted.

gsmet · 2020-04-09T08:19:38Z

@newk5 could you create two separate issues for this? Better than discussing in a closed issue :).

newk5 · 2020-04-10T17:28:09Z

@gsmet it seems like there's already an issue created: #7678
About the TimeZoneNames exception, unless this is happening on all quarkus apps, it seems to be an additional JSF config to add in the application.properties. Do you think I should create an issue for that one?

gwenneg added the kind/enhancement New feature or request label Feb 18, 2020

gwenneg self-assigned this Feb 19, 2020

gwenneg mentioned this issue Feb 19, 2020

[WIP] Support both GraalVM 19.3.1 and 20.0.0 - 20.0.0 SDK & 20.0.0 GraalVM image #7291

Closed

gwenneg changed the title ~~Support GraalVM 20.0~~ Support GraalVM 20.0.0 Feb 19, 2020

This was referenced Feb 20, 2020

[WIP] Support both GraalVM 19.3.1 and 20.0.0 - 20.0.0 SDK & 19.3.1 GraalVM image #7321

Closed

[WIP] Support both GraalVM 19.3.1 and 20.0.0 - 19.3.1 SDK & 20.0.0 GraalVM image #7320

Closed

gwenneg changed the title ~~Support GraalVM 20.0.0~~ Support both GraalVM 19.3.1 and 20.0.0 Feb 21, 2020

fmhwong mentioned this issue Mar 3, 2020

Native image build fails with unknown arguments on Windows #5675

Closed

gwenneg mentioned this issue Mar 3, 2020

Make DiagnosticPrinter compatible with Windows #7546

Merged

gwenneg mentioned this issue Mar 5, 2020

Initialize sun.nio.ch.Iocp at runtime on Windows with JDK 11 #7587

Merged

gsmet closed this as completed Mar 17, 2020

gsmet added the triage/out-of-date This issue/PR is no longer valid or relevant label Mar 17, 2020

iwangxiaodong mentioned this issue Mar 23, 2020

HttpURLConnection Caused String.getBytes() NoSuchMethodError, Quarkus 1.3.0.Final and GraalVM 20.0.0 on Windows #8067

Closed

newk5 mentioned this issue Apr 9, 2020

Extension: JSF for native mode? #6421

Closed

Support both GraalVM 19.3.1 and 20.0.0 #7269

Support both GraalVM 19.3.1 and 20.0.0 #7269

Comments

gwenneg commented Feb 18, 2020 • edited Loading

gwenneg commented Feb 19, 2020

gsmet commented Feb 19, 2020

iwangxiaodong commented Feb 20, 2020

emmanuelbernard commented Feb 20, 2020

gwenneg commented Feb 20, 2020

gwenneg commented Feb 20, 2020 • edited Loading

gwenneg commented Feb 21, 2020 • edited Loading

gwenneg commented Feb 21, 2020

iwangxiaodong commented Feb 22, 2020 • edited Loading

gwenneg commented Mar 1, 2020 • edited Loading

iwangxiaodong commented Mar 2, 2020

gwenneg commented Mar 2, 2020

iwangxiaodong commented Mar 3, 2020

gwenneg commented Mar 3, 2020 • edited Loading

gwenneg commented Mar 3, 2020

gwenneg commented Mar 3, 2020

iwangxiaodong commented Mar 3, 2020

thejibz commented Mar 4, 2020

iwangxiaodong commented Mar 6, 2020

gwenneg commented Mar 6, 2020

ctomc commented Mar 6, 2020

gwenneg commented Mar 7, 2020

iwangxiaodong commented Mar 8, 2020

Xabin commented Mar 9, 2020

ctomc commented Mar 9, 2020

Xabin commented Mar 9, 2020

iwangxiaodong commented Mar 9, 2020

ctomc commented Mar 9, 2020

iwangxiaodong commented Mar 9, 2020

iwangxiaodong commented Mar 12, 2020 • edited Loading

gwenneg commented Mar 12, 2020

geoand commented Mar 17, 2020

gwenneg commented Mar 17, 2020

newk5 commented Apr 8, 2020

gsmet commented Apr 8, 2020

newk5 commented Apr 8, 2020 • edited Loading

dmlloyd commented Apr 8, 2020

newk5 commented Apr 8, 2020

newk5 commented Apr 9, 2020

gsmet commented Apr 9, 2020

newk5 commented Apr 10, 2020

gwenneg commented Feb 18, 2020 •

edited

Loading

gwenneg commented Feb 20, 2020 •

edited

Loading

gwenneg commented Feb 21, 2020 •

edited

Loading

iwangxiaodong commented Feb 22, 2020 •

edited

Loading

gwenneg commented Mar 1, 2020 •

edited

Loading

gwenneg commented Mar 3, 2020 •

edited

Loading

iwangxiaodong commented Mar 12, 2020 •

edited

Loading

newk5 commented Apr 8, 2020 •

edited

Loading