Quarkus: Simplest generated project fails with quarkus:dev with JDK 13 on Windows 10

Created on 10 Nov 2019  Â·  7Comments  Â·  Source: quarkusio/quarkus

Describe the bug
Generated project doesn't run with quarkus:dev on Windows 10. The same project run seamlessly on macOS Catalina.

Expected behavior
Runs without any error.

Actual behavior
Fails at run with error message:

[INFO] --- quarkus-maven-plugin:1.0.0.CR1:dev (default-cli) @ code-with-quarkus ---
Java HotSpot(TM) 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release.
Listening for transport dt_socket at address: 5005
Error: Could not find or load main class io.quarkus.dev.DevModeMain
Caused by: java.lang.ClassNotFoundException: io.quarkus.dev.DevModeMain

To Reproduce
Steps to reproduce the behavior:

  1. Generate the simplest app on code.quarkus.io (whithout extensions)
  2. Run mvn compile quarkus:dev

Environment:

  • OS: Windows 10 (KO) and macOS Catalina (OK)
  • JDK: tested with Oracle JDK 13

Additional context
I found a similar issue:
https://github.com/apache/camel-quarkus/issues/263
but this one seems related to camel and I am not using it.

enwindows kinbug

Most helpful comment

The JDK 13 Class-Path details in the jar spec[1] has additional details explaining what constitutes as valid Class-Path entries. Plus the linked mailing list thread makes it clear that this change is intentional. So I will try and come up with a fix to our Class-Path value generation to make it work against Java 13 as well as previous versions of Java.

[1] https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#class-path-attribute

All 7 comments

Hello @bdesemb, does this only happen with Java 13?
Can you try with Java 8 and see if it works? Also, can you post the output of the directory listing of the "target" directory when this fails against Java 13? If its easier, you can just zip/tar the contents of your target dir and upload it as an attachment to this issue.

Hi @jaikiran, I tested with Java 11 and Java 8 and both are working well.

Here is all the generated files in target with Java 13

├───classes
│   │   application.properties
│   │
│   ├───be
│   │   └───devoxx
│   │           ExampleResource.class
│   │
│   └───META-INF
│       └───resources
│               index.html
│
├───generated-sources
│   └───annotations
├───maven-status
│   └───maven-compiler-plugin
│       └───compile
│           └───default-compile
│                   createdFiles.lst
│                   inputFiles.lst
│
└───wiring-devmode

FYI, mvn package passes in Java 13. It builds the 'runner' jar that I can run and see the result on http://localhost:8080

EDIT:
I checked your PR linked to this issue.
Here is the JVM command line in dev mode (and the error again):

[DEBUG] Launching JVM with command line: [C:\Program Files\Java\jdk-13\bin\java.EXE, -XX:TieredStopAtLevel=1, -Xverify:none, -Xdebug, -Xrunjdwp:transport=dt_socket,address=5005,server=y,suspend=n, -Djava.util.logging.manager=org.jboss.logmanager.LogManager, -jar, C:\Users\bdese\workspace\code-with-quarkus\target\code-with-quarkus-dev.jar]
Java HotSpot(TM) 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release.
Listening for transport dt_socket at address: 5005
Error: Could not find or load main class io.quarkus.dev.DevModeMain
Caused by: java.lang.ClassNotFoundException: io.quarkus.dev.DevModeMain

I hope this will help.

@bdesemb, thank you for these additional details. So it looks like this is specific to Java 13 on Windows. I'll try and find a Windows machine later this week to see what's going on.

@bdesemb I was able to reproduce this issue. Looks like the Class-Path parsing of jar MANIFEST has gone wrong again (within the JDK). I need to understand why/how this has regressed before I bring this up with the JDK team. For now, this isn't really something Quarkus can fix reliably across JDK versions (unless, there's some workaround I'll stumble upon during investigation). I'll keep this issue updated.

I've brought this up on OpenJDK mailing list to ask for their inputs https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-November/063491.html

The JDK 13 Class-Path details in the jar spec[1] has additional details explaining what constitutes as valid Class-Path entries. Plus the linked mailing list thread makes it clear that this change is intentional. So I will try and come up with a fix to our Class-Path value generation to make it work against Java 13 as well as previous versions of Java.

[1] https://docs.oracle.com/en/java/javase/13/docs/specs/jar/jar.html#class-path-attribute

I've proposed https://github.com/quarkusio/quarkus/pull/5808 to see if we would like to go with the approach suggested in that PR.

Was this page helpful?
0 / 5 - 0 ratings