quarkus: Native Image Compilation Stack Trace Not Showing Underlying Error related to --initialize-at-run-time using Gradle

Describe the bug

This is using Gradle quarkusBuild, but may be present in Maven as well.

I am working with a team at AWS to get their Deep Java Learning (DJL) library working in Quarkus native. I ran into a native compilation error.

Here is the strack trace from the error: https://github.com/awslabs/djl/issues/67#issuecomment-628755945

Expected behavior

The stack trace should state what the underlying error is that is elevated by using --initialize-at-run-time.

Actual behavior

Stack trace has no real error message.

To Reproduce

Reproducer coming.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Reactions: 1
  • Comments: 15 (7 by maintainers)

Most upvoted comments

Now that I have seen/tried this fix against some real application, I’m going to mark this issue as fixed for (upcoming) 1.6 version of Quarkus.

I have never used Gradle before, but I have recently seen many users complaining about the lack of log messages (especially) when building native images with Quarkus. So I decided to take a look at this. To be honest, I am really surprised by the complete lack of logs that show up during a normal gradle build process of Quarkus application as compared to Maven, which prints out useful log messages during the same application build. To give others an idea, during native-image generation of a Quarkus application using Maven, we are used to seeing helpful messages like:

[code-with-quarkus-1.0.0-SNAPSHOT-runner:91144]        (cap):   2,147.75 ms,  0.94 GB
[code-with-quarkus-1.0.0-SNAPSHOT-runner:91144]        setup:   4,427.79 ms,  0.94 GB
17:27:50,236 INFO  [org.jbo.threads] JBoss Threads version 3.1.1.Final
[code-with-quarkus-1.0.0-SNAPSHOT-runner:91144]     (clinit):     725.16 ms,  2.80 GB
[code-with-quarkus-1.0.0-SNAPSHOT-runner:91144]   (typeflow):  14,309.93 ms,  2.80 GB
[code-with-quarkus-1.0.0-SNAPSHOT-runner:91144]    (objects):  14,660.82 ms,  2.80 GB
[code-with-quarkus-1.0.0-SNAPSHOT-runner:91144]   (features):     636.42 ms,  2.80 GB
[code-with-quarkus-1.0.0-SNAPSHOT-runner:91144]     analysis:  31,663.79 ms,  2.80 GB
[code-with-quarkus-1.0.0-SNAPSHOT-runner:91144]     universe:   1,404.90 ms,  2.80 GB
[code-with-quarkus-1.0.0-SNAPSHOT-runner:91144]      (parse):   3,699.44 ms,  2.80 GB
[code-with-quarkus-1.0.0-SNAPSHOT-runner:91144]     (inline):  10,452.02 ms,  3.50 GB
[code-with-quarkus-1.0.0-SNAPSHOT-runner:91144]    (compile):  36,515.61 ms,  4.56 GB
[code-with-quarkus-1.0.0-SNAPSHOT-runner:91144]      compile:  53,489.95 ms,  4.56 GB
[code-with-quarkus-1.0.0-SNAPSHOT-runner:91144]        image:   4,579.45 ms,  4.63 GB
[code-with-quarkus-1.0.0-SNAPSHOT-runner:91144]        write:   2,070.25 ms,  4.63 GB
[code-with-quarkus-1.0.0-SNAPSHOT-runner:91144]      [total]: 291,590.58 ms,  4.63 GB

To my surprise, none of this shows up in Gradle builds. It’s like watching a blank console which shows a progress bar without any of these details.

So I looked into the Gradle code a bit more (well it turned out to be a mammoth exercise with all the logging wrappers/delegates/listeners/libraries spaghetti that we are used to seeing in the Java logging world 😃). I ultimately found 2-3 issues that are stopping us from having a more informative build process for a Quarkus application. One such issue is within the Gradle tool itself which I have logged here https://github.com/gradle/gradle/issues/13522. The other two issues have to do with certain configurations which I think we (Quarkus) can improve ourselves for the Gradle builds. I’ll open a separate issue or a PR within this Quarkus repo for that, later.

As for whether or not the fix for https://github.com/gradle/gradle/issues/13522 will show up the real root cause of the native image generation failures in this issue, we can verify it by running it against a patched version of Gradle with the fix I’ve in mind. If one of you is interested in testing this fix, I’ll share a Gradle forked repo which perhaps you can build yourself and use it to test against Quarkus app? Or maybe one of you can share an application (as a github repo) which reproduces this issue (preferably against 1.5.2.Final series of Quarkus) and I’ll run it locally when I get a chance.