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).

gwenneg on 19 Feb 2020

FYI https://github.com/quarkusio/quarkus-images/pull/55

gsmet on 19 Feb 2020

👍4

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 })

iwangxiaodong on 20 Feb 2020

@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.

emmanuelbernard on 20 Feb 2020

@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 on 20 Feb 2020

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

gwenneg on 20 Feb 2020

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 on 21 Feb 2020

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.

gwenneg on 22 Feb 2020

😄1

@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

iwangxiaodong on 22 Feb 2020

👍1

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.

gwenneg on 1 Mar 2020

@gwenneg

Write text file can fix missing unistd.h :

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

ifndef _UNISTD_H

define _UNISTD_H

include

endif /* _UNISTD_H */

iwangxiaodong on 2 Mar 2020

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.

gwenneg on 2 Mar 2020

@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.

iwangxiaodong on 3 Mar 2020

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

https://github.com/quarkusio/quarkus/blob/3fbdbc399f4c274054bed23d70061c028e7a59c7/core/runtime/src/main/java/io/quarkus/runtime/graal/DiagnosticPrinter.java#L46-L50

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

gwenneg on 3 Mar 2020

😕1

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 on 3 Mar 2020

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 on 4 Mar 2020

@gwenneg

Congratulations!

iwangxiaodong on 4 Mar 2020

👍1

@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 !

thejibz on 4 Mar 2020

👍1

@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)

iwangxiaodong on 6 Mar 2020

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

gwenneg on 6 Mar 2020

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

ctomc on 6 Mar 2020

👍2

@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?

gwenneg on 7 Mar 2020

@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

iwangxiaodong on 8 Mar 2020

@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.

Xabin on 9 Mar 2020

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.

ctomc on 9 Mar 2020

@ctomc Ah, I see you already fixed that. Good job :) https://github.com/quarkusio/quarkus/pull/7663

Xabin on 9 Mar 2020

@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

iwangxiaodong on 9 Mar 2020

For same code that that works under jvm?

ctomc on 9 Mar 2020

@ctomc yes!

jvm is Successful

iwangxiaodong on 9 Mar 2020

@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

iwangxiaodong on 12 Mar 2020

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.

gwenneg on 12 Mar 2020

Hasn't this one been implemented already?

geoand on 17 Mar 2020

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

gwenneg on 17 Mar 2020

👍2

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.

newk5 on 8 Apr 2020

@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 on 8 Apr 2020

@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)

newk5 on 8 Apr 2020

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

dmlloyd on 8 Apr 2020

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 on 8 Apr 2020

@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\Tempvertx-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.

newk5 on 9 Apr 2020

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

gsmet on 9 Apr 2020

@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?

newk5 on 10 Apr 2020

Quarkus: Support both GraalVM 19.3.1 and 20.0.0

Most helpful comment

All 41 comments

ifndef _UNISTD_H

define _UNISTD_H

include

include

endif /* _UNISTD_H */

Related issues