beryx / badass-runtime-plugin

Create a custom runtime image of your non-modular application
https://badass-runtime-plugin.beryx.org
Apache License 2.0
162 stars 21 forks source link

WARNING: Unknown Module #47

Open chrisrush1 opened 4 years ago

chrisrush1 commented 4 years ago

Hello,

I've been using this plugin for a while now to build my non-modular application (I haven't had time fully modularise it yet) and it's great so thank you. In the last week I have an odd issue where the jpackage task no longer builds installable exes and when I run the bat file created by the runtime task I see lots of WARNING: Unknown module messages. The odd thing is the application still runs ok despite these warnings?

WARNING: Unknown module: javafx.graphics specified to --add-exports WARNING: Unknown module: javafx.controls specified to --add-exports WARNING: Unknown module: javafx.controls specified to --add-exports WARNING: Unknown module: javafx.controls specified to --add-exports WARNING: Unknown module: javafx.base specified to --add-exports WARNING: Unknown module: javafx.graphics specified to --add-exports WARNING: Unknown module: javafx.controls specified to --add-exports WARNING: Unknown module: javafx.base specified to --add-exports WARNING: Unknown module: javafx.controls specified to --add-exports WARNING: Unknown module: javafx.graphics specified to --add-exports WARNING: Unknown module: javafx.controls specified to --add-opens WARNING: Unknown module: javafx.graphics specified to --add-opens

I haven't changed my build.gradle so I'm slightly confused as to the cause.

Here is the build.gradle (as you can see I'm targetting Java 11 but using JavaFX 13):

plugins { id 'application' id 'org.openjfx.javafxplugin' version '0.0.8' id 'org.beryx.runtime' version '1.8.0' id "com.github.johnrengelman.shadow" version "5.1.0" id 'idea' }

repositories { mavenCentral() }

sourceCompatibility = 11 targetCompatibility = 11

dependencies { implementation 'javax.annotation:javax.annotation-api:1.3.2' implementation 'javax.inject:javax.inject:1' implementation 'org.jvnet.staxex:stax-ex:1.8.2' implementation 'javax.xml.bind:jaxb-api:2.4.0-b180830.0359' implementation 'com.sun.xml.ws:jaxws-ri:2.3.2' implementation 'org.controlsfx:controlsfx:11.0.0' }

javafx { version = "13" modules = ['javafx.base','javafx.controls', 'javafx.fxml', 'javafx.swing'] }

application { mainClassName = "org.mainapp.client.Launcher" applicationName = 'AppFX' }

def jvmArgsList = ['--add-exports', 'javafx.base/com.sun.javafx.event=ALL-UNNAMED', '--add-exports', 'javafx.base/com.sun.javafx.runtime=ALL-UNNAMED', '--add-exports', 'javafx.controls/com.sun.javafx.scene.control.inputmap=ALL-UNNAMED', '--add-exports', 'javafx.controls/com.sun.javafx.charts=ALL-UNNAMED', '--add-exports', 'javafx.controls/com.sun.javafx.scene.control.behavior=ALL-UNNAMED', '--add-exports', 'javafx.controls/com.sun.javafx.scene.control=ALL-UNNAMED', '--add-exports', 'javafx.controls/com.sun.javafx.scene.control.skin=ALL-UNNAMED', '--add-exports', 'javafx.graphics/com.sun.javafx.scene.traversal=ALL-UNNAMED', '--add-exports', 'javafx.graphics/com.sun.javafx.tk=ALL-UNNAMED', '--add-exports', 'javafx.graphics/com.sun.prism=ALL-UNNAMED', '--add-opens', 'javafx.controls/javafx.scene.control.skin=ALL-UNNAMED', '--add-opens', 'javafx.graphics/javafx.scene=ALL-UNNAMED']

runtime { options = ['--strip-debug', '--compress', '2', '--no-header-files', '--no-man-pages'] modules = [ 'java.desktop', 'jdk.unsupported', 'jdk.unsupported.desktop', 'java.scripting' ] jpackage {

    jpackageHome = 'C:\\Java\\openjdk-14-jpackage+1-49'
    resourceDir =file("$buildDir/resources")
    jvmArgs = jvmArgsList
    if(org.gradle.internal.os.OperatingSystem.current().windows) {
        installerType = 'msi'
        installerOptions = ['--win-per-user-install', '--win-dir-chooser', '--win-menu', '--win-shortcut']
    }
}

}

Any help greatfully received?

siordache commented 4 years ago

I don't know why this happens. I couldn't reproduce the problem on my machine. I also tried building with 13.0.1+9 and executing with jdk-11.0.3+7 and vice versa, but I got no errors or warnings. Can you reproduce the problem on another machine? If yes, please create a GitHub project that allows reproducing it. If no, reboot your machine (or at lest execute gradlew --stop), then execute gradlew --refresh-dependencies clean jpackage. Maybe it helps.

ylexus commented 3 years ago

Something similar happens on my project (https://github.com/ylexus/jiotty-photos-uploader/issues/118). Relatively easy to reproduce - just use JDK 16, checkout the repo above and execute ./gradlew -DCLIENT_SECRET_PATH=<path-to-any-file-whatsoever> clean jpackage -DVERSION=0.0.0. Then try to run the resulting binary from the command line with the -v argument (so that it prints the version and exits). For example, in macOS, if executed from app/build/jpackage directory: ./Jiotty\ Photos\ Uploader.app/Contents/MacOS/Jiotty\ Photos\ Uploader -v The output will be

% ./Jiotty\ Photos\ Uploader.app/Contents/MacOS/Jiotty\ Photos\ Uploader -v
WARNING: Unknown module: javafx.graphics specified to --add-exports
WARNING: Unknown module: javafx.controls specified to --add-exports
WARNING: Unknown module: javafx.graphics specified to --add-exports
WARNING: Unknown module: javafx.graphics specified to --add-exports
WARNING: Unknown module: javafx.graphics specified to --add-opens
WARNING: Unknown module: javafx.controls specified to --add-opens
Version 2.0.4

It used to not happen, then started happening after another update of a JDK or badass plugin or something else.

siordache commented 3 years ago

@ylexus What happens if you change jvmArgs in the jpackage block from:

jvmArgs = application.applicationDefaultJvmArgs + ['-Dprism.verbose=true', '-Djavafx.verbose=true']

to

jvmArgs = ['-Dprism.verbose=true', '-Djavafx.verbose=true']

Do you still get the warning? Does your application still start?

ylexus commented 3 years ago

This actually solves the issue! Must have been required at some point before, but not with JDK 16. Thanks.

chrisrush1 commented 2 years ago

Hi siordache,

I've just encountered an issue relating to TLSv1.3 in OpenjDK 11.0 that has also highlighted the --add-exports --add-opens warnings I started this ticket about again.

I've created a reprex project on Github to help you see what's going on for me.

https://github.com/chrisrush1/MVPDoExportsTLSReprex

Firstly I've left all my jvmargs in the build.gradle even though they're not all needed for this reprex project, it's just so you can see the warnings when this project is run using the bat file when beryx runtime creates the image. Do you know why these warnings are shown? The image seems to run ok in regards to these -add-exports/--add-opens params, as you can see this is non-modular project (like my real project) and if these aren't set in the real application I get plenty of warnings about access issues when compiling in the IDE. Basically they are getting set but for some reason the warnings are there?

The next issue is the reason I noticed the --add-export warnings again.

My real application uses a map tile server and requires and SSL handshake(the URL starts with https). Java 11.0 had a bug with TLSv1.3 if multiple requests are made and if you run this reprex having compiled with OpenJDK11.0 you will see each URL causes an SSL exception, if you enable the JVM param '-Djavax.net.debug=ssl:handshake' in the build.gradle you can see more info about this. It's a known bug and, in case you don't know, it's fixed at 11.02. Unfortunately I can't move to that version for the current release so the workaround for now is to force my application to use TLSv1.2. This works fine when running my code for the IDE but as soon as I use beryx runtime to make the image and then run the application using the bat file the SSL handshake exception returns as if the TLS version hasn't been changed. If I enable the'-Djavax.net.debug=ssl:handshake' param I can see it is using TLSv1.2 though so what is the difference when running from the image to running with the IDE? I also tried forcing the TLS version using the following code instead of the JVM param '-Djdk.tls.client.protocols=TLSv1.2':

       try {
            SSLContext ctx = SSLContext.getInstance("TLSv1.2");
            ctx.init(null, null, null);
            SSLContext.setDefault(ctx);
        } catch (Exception e) {
            System.out.println(e.getMessage());
        }

this also works when running the main application or reprex from the IDE but not using the bat file the runtime plugin creates in the image. So my obvious solution is to upgrade to OpenJDK 11.02 but I can't do this just yet so any help or ideas as to what could be different in the image relating to this would be appreciated? If you know why I get the warnings relating to --add-exports and --add-opens it would also be good to get rid of those even though they don't appear to affect the application?

thanks in advance for any ideas you may have and for creating this really useful plugin.

Chris