Thanks for all the help on this.
I have done some further digging and I think the current problem (with the
minimal test case) may not be JavaFX specific, but rather something related
to GUI in general on Mac OS. I changed the test to just use Swing but it
also hangs as soon as it tries to create a JFrame. I'm guessing that this
is something related to gatekeeper, or perhaps I need some special compile
flags on MacOS to allow a binary to do GUI stuff.
I find this absolutely bizarre since I had "real-world" test cases working
earlier with almost identical code. I must have done something in those
real world apps that "enabled" GUI as a byproduct. I'm just not sure what.
Best regards
Steve
On Wed, Jan 19, 2022 at 5:04 PM Kevin Rushforth <kevin.rushfo...@oracle.com>
wrote:
> Point #1 is one of the known limitations of using javafx modules on the
> classpath (and is one of the reasons we recommend against it), so that's
> not surprising. And I see you found the workaround.
>
> I wonder if it might have something to do with a shared library that is
> being loaded in one case and not the other, but that's just a vague
> guess. Maybe someone else will spot something.
>
> Since you have something minimal that reproduces the problem for you,
> can you file a bug?
>
> -- Kevin
>
>
> On 1/19/2022 4:07 PM, Steve Hannah wrote:
> > I've reduced the problem down to something minimal and have found that:
> >
> > 1. If your main class extends Application, and you try to run it like:
> > java -jar MyApplication.jar
> >
> > It will fail immediately with:
> > Error: JavaFX runtime components are missing, and are required to run
> this
> > application
> >
> > 2. If you "trick" it, by making your Application class a separate class
> > that you call from your main class, it will run fine using:
> > java -jar MyApplication.jar
> >
> > 3. It will also run fine in this scenario using
> > -Djava.class.path=MyApplication.jar instead of -jar:
> > java -Djava.class.path=MyApplication.jar Main
> >
> > 3. If I try to simulate the exact same thing with my own launcher, it
> will
> > hang somewhere in the JavaFX initialization:
> >
> > with javafx.verbose=true, the output is:
> >
> > System.loadLibrary(prism_es2) succeeded
> > JavaFX: using com.sun.javafx.tk.quantum.QuantumToolkit
> > System.loadLibrary(glass) succeeded
> >
> > But it hangs there, and never displays the screen.
> >
> > The C code for this launcher is:
> >
> > char *mainClass;
> >
> > JavaVM *vm;
> > JNIEnv *env;
> > JavaVMInitArgs vm_args;
> > JavaVMOption options[2];
> > mainClass = "Main";
> > options[0].optionString = "-Djava.class.path=MyApplication.jar";
> > options[1].optionString = "-Djavafx.verbose=true";
> > vm_args.version = JNI_VERSION_1_2;
> > vm_args.options = options;
> > vm_args.nOptions = 2;
> > vm_args.ignoreUnrecognized = 0;
> >
> > jobjectArray args;
> > jint res = JNI_CreateJavaVM(&vm, (void **)&env, &vm_args);
> > if (res < 0) {
> > printf("Can't create Java VM\n");
> > exit(1);
> > }
> > jclass cls = (*env)->FindClass(env, mainClass);
> > if (cls == 0) {
> >
> > printf("Main class %s class not found\n", mainClass);
> > exit(1);
> > }
> > jmethodID mid =
> > (*env)->GetStaticMethodID(env, cls, "main", "([Ljava/lang/String;)V");
> > if (mid == 0) {
> > printf("main() method not found\n");
> > exit(1);
> > }
> > //jstring argString = (*env)->NewStringUTF(env, ""); //empty arg list
> > args =
> > (*env)->NewObjectArray(env, 0, (*env)->FindClass(env,
> > "java/lang/String"), NULL);
> > if (args == 0) {
> > printf("Out of memory\n");
> > exit(1);
> > }
> >
> > (*env)->CallStaticVoidMethod(env, cls, mid, args);
> >
> >
> >
> > Can anyone spot any differences between that and running with the "java"
> > binary:?
> > java -Djava.class.path=MyApplication.jar Main
> >
> > I have experimented both with JDKs that include JavaFX (e.g. Zulu) and
> ones
> > that do not (e.g. AdoptOpenJDK). Both exhibit the same behaviour (except
> > with AdoptOpenJDK, I also add the javafx jars to the classpath).
> >
> > For this test I'm using JDK 11 on Mac OS Mojave, but it is consistent
> with
> > my earlier troubles on Ubuntu (also JDK11).
> >
> >
> > Best regards
> >
> > Steve
> >
> >
> > On Wed, Jan 19, 2022 at 3:06 PM John Neffenger <j...@status6.com> wrote:
> >
> >> On 1/19/22 2:12 PM, Steve Hannah wrote:
> >>> I have been resisting using modules for a long time because it just
> makes
> >>> things more complicated, ...
> >> It also makes some things easier, though, and certainly smaller. It's
> >> easier to use an old-school Makefile with modules, and using 'jlink' can
> >> get a simple Hello World JavaFX application and Java runtime down to
> >> just 31 megabytes.
> >>
> >> Here's my minimal, no-magic example:
> >>
> >> https://github.com/jgneff/hello-javafx
> >>
> >> with a simple Makefile:
> >>
> >> https://github.com/jgneff/hello-javafx/blob/main/Makefile
> >>
> >> and a Maven POM for use online with Maven Central or offline with a
> >> local Debian- or Ubuntu-built Maven repository:
> >>
> >> https://github.com/jgneff/hello-javafx/blob/main/pom.xml
> >>
> >> John
> >>
> >
>
>
--
Steve Hannah
Web Lite Solutions Corp.
