Re: JavaFX Launch Failure on Ubuntu from JNI
Just wanted to share that I sorted out all of my issues with this launcher, and I'm proud to present the result: jDeploy https://www.jdeploy.com You can now deploy your JavaFX apps as native bundles to your Mac, Linux, and Windows users without requiring a Mac/Windows/Linux box to produce the native bundle. You don't need to deal with codesigning/notarizing on Mac either. Install bundles are small (3mb compressed). When you publish updates, your users will get them automatically on next launch. Please take it for a spin and let me know what you think. Happy to answer any questions. On Mon, Jan 24, 2022 at 9:48 AM Steve Hannah wrote: > I just wanted to follow up with this in case someone comes across this > thread later. > > After thoroughly exploring the landscape, I found that the issue on Ubuntu > was caused by a conflict between the webkit2gtk-4.0 library (which I was > using to show a progress dialog in the case that the JRE or app needs to > download an update). Additionally it seemed to have a problem with just > the general gtk+-3.0 dependency, if GTK was initialized before JavaFX was > loaded. > I worked around the gtk+-3.0 issue by breaking the GTK stuff into a > separate process (calling itself with different args). This workaround was > not sufficient to resolve the webkit2gtk-4.0 conflict as, even if it wasn't > used at runtime, it would still conflict with JavaFX's webview - resulting > in a segfault. The only solution was to remove the webkit2gtk-4.0 > dependency entirely from my app, and do the progress dialog differently (I > ended up just using basic GTK widgets). > > Best regards > > Steve > > > > On Wed, Jan 19, 2022 at 9:40 AM Steve Hannah wrote: > >> The following issue only seems to occur on Linux (Ubuntu 20.04.1), and >> only when I try to launch the JVM from a custom C launcher using JNI. It >> does not occur when launching the JVM as a separate process using the >> "java" binary. It also does not occur on MacOS when using the same C >> launcher using JNI. >> >> When I call MyApplication.launch(args). (where MyApplication extends the >> JavaFX Application class), I get the following stack trace: >> >> Jan. 19, 2022 8:54:27 A.M. com.sun.javafx.application.PlatformImpl startup >> Exception in thread "Thread-5" java.lang.IllegalStateException: This >> operation is permitted on the event thread only; currentThread = Thread-5 >> at >> com.sun.glass.ui.Application.checkEventThread(Application.java:447) >> at com.sun.glass.ui.Application.setName(Application.java:200) >> at >> com.sun.javafx.application.PlatformImpl.lambda$setApplicationName$2(PlatformImpl.java:142) >> at >> com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) >> at java.base/java.security.AccessController.doPrivileged(Native >> Method) >> at >> com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) >> at >> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) >> Exception in Application start method >> Exception in thread "Thread-31" Failed to show docs >> java.lang.IllegalStateException: Not on FX application thread; currentThread >> = Thread-31 >> at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295) >> at >> com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458) >> at >> com.sun.javafx.tk.quantum.QuantumToolkit.exit(QuantumToolkit.java:828) >> at >> com.sun.javafx.application.PlatformImpl.lambda$tkExit$16(PlatformImpl.java:624) >> at >> com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484) >> at >> com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) >> at java.base/java.security.AccessController.doPrivileged(Native >> Method) >> at >> com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) >> at >> com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) >> java.lang.RuntimeException: Exception in Application start method >> at >> com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:901) >> at >> com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:196) >> at java.base/java.lang.Thread.run(Thread.java:829) >> Caused by: java.lang.IllegalStateException: Not on FX application thread; >> currentThread = Thread-6 >> at co
Re: JavaFX Launch Failure on Ubuntu from JNI
I just wanted to follow up with this in case someone comes across this thread later. After thoroughly exploring the landscape, I found that the issue on Ubuntu was caused by a conflict between the webkit2gtk-4.0 library (which I was using to show a progress dialog in the case that the JRE or app needs to download an update). Additionally it seemed to have a problem with just the general gtk+-3.0 dependency, if GTK was initialized before JavaFX was loaded. I worked around the gtk+-3.0 issue by breaking the GTK stuff into a separate process (calling itself with different args). This workaround was not sufficient to resolve the webkit2gtk-4.0 conflict as, even if it wasn't used at runtime, it would still conflict with JavaFX's webview - resulting in a segfault. The only solution was to remove the webkit2gtk-4.0 dependency entirely from my app, and do the progress dialog differently (I ended up just using basic GTK widgets). Best regards Steve On Wed, Jan 19, 2022 at 9:40 AM Steve Hannah wrote: > The following issue only seems to occur on Linux (Ubuntu 20.04.1), and > only when I try to launch the JVM from a custom C launcher using JNI. It > does not occur when launching the JVM as a separate process using the > "java" binary. It also does not occur on MacOS when using the same C > launcher using JNI. > > When I call MyApplication.launch(args). (where MyApplication extends the > JavaFX Application class), I get the following stack trace: > > Jan. 19, 2022 8:54:27 A.M. com.sun.javafx.application.PlatformImpl startup > Exception in thread "Thread-5" java.lang.IllegalStateException: This > operation is permitted on the event thread only; currentThread = Thread-5 > at com.sun.glass.ui.Application.checkEventThread(Application.java:447) > at com.sun.glass.ui.Application.setName(Application.java:200) > at > com.sun.javafx.application.PlatformImpl.lambda$setApplicationName$2(PlatformImpl.java:142) > at > com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) > at java.base/java.security.AccessController.doPrivileged(Native > Method) > at > com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) > at > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > Exception in Application start method > Exception in thread "Thread-31" Failed to show docs > java.lang.IllegalStateException: Not on FX application thread; currentThread > = Thread-31 > at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295) > at > com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458) > at > com.sun.javafx.tk.quantum.QuantumToolkit.exit(QuantumToolkit.java:828) > at > com.sun.javafx.application.PlatformImpl.lambda$tkExit$16(PlatformImpl.java:624) > at > com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484) > at > com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) > at java.base/java.security.AccessController.doPrivileged(Native > Method) > at > com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) > at > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > java.lang.RuntimeException: Exception in Application start method > at > com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:901) > at > com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:196) > at java.base/java.lang.Thread.run(Thread.java:829) > Caused by: java.lang.IllegalStateException: Not on FX application thread; > currentThread = Thread-6 > at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295) > at > com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458) > at javafx.stage.Stage.(Stage.java:254) > at javafx.stage.Stage.(Stage.java:240) > at > com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:845) > at > com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484) > at > com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) > at java.base/java.security.AccessController.doPrivileged(Native > Method) > at > com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) > at > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > > > I have tried a few different versions of JavaFX (11, 11.0.2, 17.0.1), > running on a
Re: JavaFX Launch Failure on Ubuntu from JNI
> > I’m not sure jpackage handles the notarization. I had done it for a > jpackage application and posted something on how to do it on my site. My > builds are currently throwing some sort of error on that I haven’t looked > at yet. The code signing and packaging I think all invoke native OS/X > commands. Not trivial but that could also probably be done on your own. It > appeared tricky with an already signed embedded jdk. It took jpackage a few > releases to get it right. > The way that I'm getting around this is by generating a platform-specific "Installer" which can be distributed. The installer itself is notarized, so it can be distributed to users outside the app store, and run without the Gatekeeper restrictions. Since the installer app bundle itself is the same for every app, it needs to look up the metadata for the specific app being installed using a naming convention of the app. I have the codesigning and notarization of this installer set up in github actions. It's not that complicated, but it's enough of a hassle that I would rather do this once, and never worry about it again. Here is the bit of my github action that deals with signing and notarization: https://github.com/shannah/jdeploy/blob/64bf78a9c3f1f526a7361c10cfa0e6f42da430a5/release.sh#L33-L50 When the end-user downloads and runs the installer, it will then install the app itself locally. The final, resulting app won't be signed or notarized, but that is OK because it isn't subject to the notarization restriction like it would be if you had downloaded it directly. This is similar to the way that Chrome creates Chrome apps from a PWA. Apps distributed in this way would not be acceptable in the Mac App Store. For that you would need jpackage. But it solves the problem of "I just built a Java app that I want to distribute to my users, and I don't want to get bogged down in creating native bundles for each platform, or worrying about distribution/updates". Best regards Steve > > > On Thu, Jan 20, 2022 at 7:13 AM Michael Hall wrote: > >> >> >> > On Jan 20, 2022, at 9:08 AM, Steve Hannah wrote: >> > >> > I just wanted to post an update on this in case it helps some future dev >> > who gets stuck on the same issue. >> > >> >> You probably have good reasons for having your own launcher but you might >> want to consider if jpackage could be an alternative and let that handle >> these cross-platform application details. >> >> > > > -- Steve Hannah Web Lite Solutions Corp.
Re: JavaFX Launch Failure on Ubuntu from JNI
My reason for a launcher is that I'm building an alternative to jpackage that uses npm for deployment/versioning/updates and allows you to build native bundles for all platforms (Mac/Linux/Windows) on any platform. I.e. You don't need to be building on a Windows box to create a native windows exe. You don't need to worry about Mac codesigning and notarization, etc... It just takes care of all that for you on whatever system you're developing on. I already had it working well but it currently launches JVM in a separate process which wasn't optimal - so I'm working on improving it to be able to run in the same process as the launcher. This (I think) was the last obstacle. Best regards Steve On Thu, Jan 20, 2022 at 7:13 AM Michael Hall wrote: > > > > On Jan 20, 2022, at 9:08 AM, Steve Hannah wrote: > > > > I just wanted to post an update on this in case it helps some future dev > > who gets stuck on the same issue. > > > > You probably have good reasons for having your own launcher but you might > want to consider if jpackage could be an alternative and let that handle > these cross-platform application details. > > -- Steve Hannah Web Lite Solutions Corp.
Re: JavaFX Launch Failure on Ubuntu from JNI
I just wanted to post an update on this in case it helps some future dev who gets stuck on the same issue. It seems that on Mac OS you can't use JNI_CreateJavaVM() to launch the JVM if you hope to use any GUI stuff.This issue is described in this issue: https://bugs.openjdk.java.net/browse/JDK-8265755 This is because the initialising the Frame class initialises the Toolkit > class which > in turn has to start the macos AppKit loop on this main thread of the > application. > This is a "hard" macOS requirement and there's no getting around it. > So it blocks and never returns. When running a Java app in the usual way > this > initial thread is reserved for the UI and the thread on which the Java app > is run > is a different one created by the VM. > ... > The only workaround is not a complete workaround. So far, the appbundler > has to use the JLI_Launch function but that function does provide any > feedback if, say, the class loader fails. By changing my launcher to use JLI_Launch() it resolves the simple test case on Mac OS. I expect that it will probably solve my other problems on Ubuntu also. It also comes with the added benefit of accepting arguments at the same level of abstraction as the "java" binary itself. E.g. When using JNI_CreateJavaVM(), I couldn't just pass "-jar MyApplication.jar" because it doesn't know how to parse the Main class and classpath from the jar. With JNI_Launch(), however, it will handle such arguments. Here is the basic test case I built using JLI_Launch, which seems to work. https://gist.github.com/shannah/57fc4bf4be42cac4e2ab4475f1d308a6 Anyways, thank you for all of the input you guys have provided. Best regards Steve On Thu, Jan 20, 2022 at 5:00 AM Steve Hannah wrote: > 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
Re: JavaFX Launch Failure on Ubuntu from JNI
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
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(, (void **), _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
Re: JavaFX Launch Failure on Ubuntu from JNI
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(, (void **), _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 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.
Re: JavaFX Launch Failure on Ubuntu from JNI
Thanks for all the replies on this. I'm working on getting a minimal example. Sadly I'm reduced to a hello-world JavaFX application that I can't get running using Maven dependencies, even just doing it the plain old way with "java -jar target/hello-world-1.0-SNAPSHOT.jar". I get: "Error: JavaFX runtime components are missing, and are required to run this application", even though all the jars should be findable on the classpath via the executable jar's Class-Path entry. I have been resisting using modules for a long time because it just makes things more complicated, but I'm getting the feeling (both from replies on this thread, and from the quirks I'm hitting here) that I'll need to use modules if I want to use JavaFX. Currently the hello world project is just a plain maven project where I add the javafx dependencies (i.e. I'm not using the javafx archetype). This works in my real projects, but not in the hello-world - perhaps because the hello world project extends Application in its main class, and the real-world project does not. I'll have to dissect the javafx archetype to see what kind of magic sauce it adds over and above just the dependencies. Steve On Wed, Jan 19, 2022 at 1:49 PM Kevin Rushforth wrote: > > > On 1/19/2022 1:46 PM, Michael Hall wrote: > > > >> On Jan 19, 2022, at 2:13 PM, Matthias Bläsing < > mblaes...@doppel-helix.eu> wrote: > >> > >> Unsupported != does not work! > > But it might mean less tested. So you might have to worry about things > like it works here but does it work on Linux? It works with version x but > does it work with y? > > > >> At this point in time Apache NetBeans loads JavaFX from classpath and > >> it works. > > Probably means it’s pretty thoroughly tested though. > > > >> FWIW, in a draft of my earlier reply, I had written a comment pointing > out that JavaFX is only supported with modules. I didn't include it, > because I think it very unlikely that that's related to the problem. > >> > >> I think a simple reproducer will be most helpful in tracking this down. > >> > >> — Kevin > > It probably isn’t the cause but since the OP indicated he was looking > for suggestions, and not necessarily a bug fix at this point, I thought it > might be worth a mention. If he wasn’t aware of this he might want to > consider it on future updates. > > Yes, it was worth a mention, and might even be something he could test > locally to see if it makes a difference. > > -- Kevin > > -- Steve Hannah Web Lite Solutions Corp.
Re: JavaFX Launch Failure on Ubuntu from JNI
Thanks for the reply. > What are the JVM args you use for launching? vm_args.version = JNI_VERSION_1_6; vm_args.options = options; vm_args.nOptions = numOptions; vm_args.ignoreUnrecognized = 1; For options, I'm just using -Djava.class.path, though I have experimented using -Djavafx.verbose=true, which doesn't tell me much more. It just logs warnings when it can't find the javafx nativelibs, in the JDK libs directory - and reports that they are loaded from resource. > Are the JavaFX modules jlink'ed into the JDK or loaded via --module-path? They are included in the classpath. I'm not using modules. Best regards Steve On Wed, Jan 19, 2022 at 10:35 AM Kevin Rushforth wrote: > Hard to say what's going on without more information. What are the JVM > args you use for launching? Are the JavaFX modules jlink'ed into the JDK > or loaded via --module-path? As a debugging aid, you might try setting > the system property "javafx.verbose" to "true" before loading your > MyApplication class. > > -- Kevin > > > On 1/19/2022 9:40 AM, Steve Hannah wrote: > > The following issue only seems to occur on Linux (Ubuntu 20.04.1), and > only > > when I try to launch the JVM from a custom C launcher using JNI. It does > > not occur when launching the JVM as a separate process using the "java" > > binary. It also does not occur on MacOS when using the same C launcher > > using JNI. > > > > When I call MyApplication.launch(args). (where MyApplication extends the > > JavaFX Application class), I get the following stack trace: > > > > Jan. 19, 2022 8:54:27 A.M. com.sun.javafx.application.PlatformImpl > startup > > Exception in thread "Thread-5" java.lang.IllegalStateException: This > > operation is permitted on the event thread only; currentThread = > > Thread-5 > > at > com.sun.glass.ui.Application.checkEventThread(Application.java:447) > > at com.sun.glass.ui.Application.setName(Application.java:200) > > at > com.sun.javafx.application.PlatformImpl.lambda$setApplicationName$2(PlatformImpl.java:142) > > at > com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) > > at java.base/java.security.AccessController.doPrivileged(Native > Method) > > at > com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) > > at > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > > Exception in Application start method > > Exception in thread "Thread-31" Failed to show docs > > java.lang.IllegalStateException: Not on FX application thread; > > currentThread = Thread-31 > > at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295) > > at > com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458) > > at > com.sun.javafx.tk.quantum.QuantumToolkit.exit(QuantumToolkit.java:828) > > at > com.sun.javafx.application.PlatformImpl.lambda$tkExit$16(PlatformImpl.java:624) > > at > com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484) > > at > com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) > > at java.base/java.security.AccessController.doPrivileged(Native > Method) > > at > com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) > > at > com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) > > java.lang.RuntimeException: Exception in Application start method > > at > com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:901) > > at > com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:196) > > at java.base/java.lang.Thread.run(Thread.java:829) > > Caused by: java.lang.IllegalStateException: Not on FX application > > thread; currentThread = Thread-6 > > at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295) > > at > com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458) > > at javafx.stage.Stage.(Stage.java:254) > > at javafx.stage.Stage.(Stage.java:240) > > at > com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:845) > > at > com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484) > > at > com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) > > at java.base/j
JavaFX Launch Failure on Ubuntu from JNI
The following issue only seems to occur on Linux (Ubuntu 20.04.1), and only when I try to launch the JVM from a custom C launcher using JNI. It does not occur when launching the JVM as a separate process using the "java" binary. It also does not occur on MacOS when using the same C launcher using JNI. When I call MyApplication.launch(args). (where MyApplication extends the JavaFX Application class), I get the following stack trace: Jan. 19, 2022 8:54:27 A.M. com.sun.javafx.application.PlatformImpl startup Exception in thread "Thread-5" java.lang.IllegalStateException: This operation is permitted on the event thread only; currentThread = Thread-5 at com.sun.glass.ui.Application.checkEventThread(Application.java:447) at com.sun.glass.ui.Application.setName(Application.java:200) at com.sun.javafx.application.PlatformImpl.lambda$setApplicationName$2(PlatformImpl.java:142) at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) at java.base/java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) Exception in Application start method Exception in thread "Thread-31" Failed to show docs java.lang.IllegalStateException: Not on FX application thread; currentThread = Thread-31 at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295) at com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458) at com.sun.javafx.tk.quantum.QuantumToolkit.exit(QuantumToolkit.java:828) at com.sun.javafx.application.PlatformImpl.lambda$tkExit$16(PlatformImpl.java:624) at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484) at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) at java.base/java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) java.lang.RuntimeException: Exception in Application start method at com.sun.javafx.application.LauncherImpl.launchApplication1(LauncherImpl.java:901) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication$2(LauncherImpl.java:196) at java.base/java.lang.Thread.run(Thread.java:829) Caused by: java.lang.IllegalStateException: Not on FX application thread; currentThread = Thread-6 at com.sun.javafx.tk.Toolkit.checkFxUserThread(Toolkit.java:295) at com.sun.javafx.tk.quantum.QuantumToolkit.checkFxUserThread(QuantumToolkit.java:458) at javafx.stage.Stage.(Stage.java:254) at javafx.stage.Stage.(Stage.java:240) at com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(LauncherImpl.java:845) at com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(PlatformImpl.java:484) at com.sun.javafx.application.PlatformImpl.lambda$runLater$10(PlatformImpl.java:457) at java.base/java.security.AccessController.doPrivileged(Native Method) at com.sun.javafx.application.PlatformImpl.lambda$runLater$11(PlatformImpl.java:456) at com.sun.glass.ui.InvokeLaterDispatcher$Future.run(InvokeLaterDispatcher.java:96) I have tried a few different versions of JavaFX (11, 11.0.2, 17.0.1), running on a few different JDK installs (all JDK11). Above stacktrace is from 17.0.1. >From the C application that launches the JVM, I have tried running directly on the main thread, and also launching it in a fresh thread using pthreads - but same issue. I am running this inside an application written in Go but the JNI code is all in C. It appears as though JavaFX is unable to create its application thread for some reason. Does anyone have any suggestions on reasons why this would be the case? Are there some system properties that need to be there which would have been bootstrapped by the "java" binary, but would not when the JVM is launched via JNI? Any suggestions appreciated. I've been banging my head on this for a while now. Best regards Steve
Re: Re: Remove JavaFX JPMS enforcement
only two questions. > > > 1. Is there any proof of a technical reason why JavaFX could not run > > > correctly on the classpath? > > > 2. If there is no such reason, then why do we torture all the newbies > with > > > the "intricacies" of the > > > module system instead of just removing this barrier? > > > > > > As I said before, I have not found any such problem in all the time > since > > > JavaFX was separated > > > from the JDK, so this test seems to be quite artificial to me but of > > > course I may be wrong. That's > > > why I asked here. > > > > > > Am 20.04.20 um 17:25 schrieb Ty Young: > > > > > > I'm a bit confused here. if you don't want JPMS then you should be > able to > > > run everything on the classpath like normal. Netbeans at least doesn't > > > force modules wtih Maven. Or is reflection disabled on classpath as of > Java > > > 9 too unless you have a module-info? > > > > > > Michael > > > > > > Am 18.04.20 um 12:58 schrieb Ty Young: > > > > > > On 4/18/20 5:01 AM, Michael Paus wrote: > > > > > > Getting started with JavaFX is made overly complicated by the fact that > > > the use of the > > > module system is enforced by some code in the JDK. Especially for > > > beginners, who just > > > want to get some small program running, this is almost always a big > source > > > of frustration. > > > It is not very good marketing for JavaFX to make these initial steps > such > > > a pain. If you > > > need some evidence for this statement, then just follow JavaFX on > > > Stackoverflow or similar > > > sites (and also this mailing list). Almost every day you can read > > > frustrated posts from > > > helpless people who would just like to get some JavaFX project running > but > > > are failing > > > because they get lost in the module system jungle. > > > > > > Speaking as a long time JavaFX user(literally since Java 8), I have > mostly > > > disagree that the JPMS is hurting JavaFX. > > > > > > That said, I don't think the frustration is misplaced. What you say is > > > true(Netbeans mailing list is fill of JavaFX issues) and the end user > is > > > *NOT* to be blamed here. > > > > > > Rather, I think what's to blame is poor documentation, JavaFX requiring > > > absurd runtime module VM arguments, and poor/buggy IDE support. > > > > > > Starting with documentation, JavaFX uses reflection for things like > > > TableView(everyone's favorite) and CSS style sheets. While this may be > > > obvious for people who are more experienced, those who are not may be > very > > > confused when they get an onslaught of error messages regarding > reflection. > > > Better documentation on what requires reflection, why, and how to > enable it > > > would be useful. > > > > > > Likewise, the notice about having to include javafx.graphics to the > > > runtime module arguments here: > > > > > > https://openjfx.io/openjfx-docs/#IDE-NetBeans > > > > > > Apply to Maven as well, but it's under Ant for some reason. I don't > know > > > what was changed in JavaFX 14 that now suddenly requires a runtime VM > > > argument, but it's a PITA and BS. End users are going to struggle with > > > this, and it prevents JavaFX runtime from being purely managed by > Maven. No > > > other JavaFX version requires this, so it's mind boggling that all of a > > > sudden JavaFX needs this. > > > > > > Poor/buggy IDE support is really the big one here. I don't know about > > > other IDEs but Netbeans DOES NOT provide a project template for > creating a > > > JavaFX application with setup dependencies. Netbeans, when setup with a > > > Maven project, allows you to select an entire project(pom) rather than > the > > > individual dependencies(jar) which doesn't work. What you search for > also > > > matters: if you search for "JavaFX" you will get the wrong search > results. > > > You need to search for "openjfx" which can be confusing. > > > > > > Anyway, yeah, it's a PITA. There is also an issue with Ant based > projects > > > and Netbeans because JavaFX puts its src.zip in a folder that is > supposed > > > to only include the runtime library that has existed for > years(literally a > > > 1 line fix too). No one really uses Ant anymore so it's probably not a > big > > > deal now but yeah, getting JavaFX working hasn't been "include and > done" > > > when it could potentially be that way. > > > > > > > -- Steve Hannah Web Lite Solutions Corp.
Re: Why cannot run compiled JavaFX 11 class?
The "java" command expects a fully-qualified class name, not a file path as its argument. E.g. cd /Users/me/Documents/java java --module-path $PATH_TO_FX --add-modules=javafx.controls HelloFX On Tue, Oct 30, 2018 at 2:06 PM Murray Eisenberg wrote: > This is under macOS Mojave (10.14). > > Following instructions at https://openjfx.io/openjfx-docs/#install-javafx, > I compiled the sample HelloFX.java via: > > javac --module-path $PATH_TO_FX --add-modules=javafx.controls > /Users/me/Documents/java/HelloFX.java > > But now if I attempt to run that... > > java --module-path $PATH_TO_FX --add-modules=javafx.controls > /Users/me/Documents/java/HelloFX > > ... I get error: > > Error: Could not find or load main class > .Users.me.Documents.java.HelloFX > Caused by: java.lang.ClassNotFoundException: > /Users/me/Documents/java/HelloFX > > Yet the file reported as not found is there: > > ls -l /Users/me/Documents/java/HelloFX.class > -rwxr--r-- 1 me staff 1336 Oct 30 16:01 > /Users/murray/Documents/java/HelloFX.class > > (I had already changed permissions to add `u+x` in case that was the > issue, but apparently that was not the trouble. > > What's wrong? > > (Yes, `$PATH_TO_FX` does point to `javafx-sdk-11/lib`.) > > —— > Murray Eisenberg mur...@math.umass.edu > Mathematics & Statistics Dept. > University of Massachusetts Amherst > > > > > -- Steve Hannah Web Lite Solutions Corp.
Re: Packaging DMG with Ant fails on OS-X 10.13.3
I tried that one, but it didn't seem to correct the problem for us. On Tue, Feb 13, 2018 at 1:44 PM, Kevin Rushforth <kevin.rushfo...@oracle.com > wrote: > The bug is also fixed in the recently released JDK 8u162. > > -- Kevin > > > Steve Hannah wrote: > > No, didn't try Java 10. It was a production server that is running Java 8 > - and changing that would have been a can of worms I wasn't ready to open. > > > On Tue, Feb 13, 2018 at 1:41 PM, Kevin Rushforth < > kevin.rushfo...@oracle.com> wrote: > >> Have you tried with JDK 10 yet? The bug you reference is fixed in 10. >> >> -- Kevin >> >> >> Steve Hannah wrote: >> >> I ran into this bug a couple months ago with javafx packager on High >> Sierra.https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190758 >> >> The problem is basically that hdiutil changed its default file system to >> APFS, which breaks many things. Ultimately I wasn't able to get javafx >> packager to work even with the workarounds listed on that bug so just >> generated the DMG using a 3rd party script >> (https://github.com/andreyvit/create-dmg) to work around it. >> >> Steve >> >> On Tue, Feb 13, 2018 at 12:05 PM, Tom Schindl <tom.schi...@bestsolution.at> >> <tom.schi...@bestsolution.at> >> wrote: >> >> >> >> Hi, >> >> It looks like the packaging of JavaFX-DMGs is broken on the latest OS-X >> System. Has anyone ancountered the same? >> >> Tom >> >> >> >> > > > -- > Steve Hannah > Web Lite Solutions Corp. > > -- Steve Hannah Web Lite Solutions Corp.
Re: Packaging DMG with Ant fails on OS-X 10.13.3
No, didn't try Java 10. It was a production server that is running Java 8 - and changing that would have been a can of worms I wasn't ready to open. On Tue, Feb 13, 2018 at 1:41 PM, Kevin Rushforth <kevin.rushfo...@oracle.com > wrote: > Have you tried with JDK 10 yet? The bug you reference is fixed in 10. > > -- Kevin > > > Steve Hannah wrote: > > I ran into this bug a couple months ago with javafx packager on High > Sierra.https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190758 > > The problem is basically that hdiutil changed its default file system to > APFS, which breaks many things. Ultimately I wasn't able to get javafx > packager to work even with the workarounds listed on that bug so just > generated the DMG using a 3rd party script > (https://github.com/andreyvit/create-dmg) to work around it. > > Steve > > On Tue, Feb 13, 2018 at 12:05 PM, Tom Schindl <tom.schi...@bestsolution.at> > <tom.schi...@bestsolution.at> > wrote: > > > > Hi, > > It looks like the packaging of JavaFX-DMGs is broken on the latest OS-X > System. Has anyone ancountered the same? > > Tom > > > > > > -- Steve Hannah Web Lite Solutions Corp.
Re: Packaging DMG with Ant fails on OS-X 10.13.3
I ran into this bug a couple months ago with javafx packager on High Sierra. https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8190758 The problem is basically that hdiutil changed its default file system to APFS, which breaks many things. Ultimately I wasn't able to get javafx packager to work even with the workarounds listed on that bug so just generated the DMG using a 3rd party script ( https://github.com/andreyvit/create-dmg) to work around it. Steve On Tue, Feb 13, 2018 at 12:05 PM, Tom Schindl <tom.schi...@bestsolution.at> wrote: > Hi, > > It looks like the packaging of JavaFX-DMGs is broken on the latest OS-X > System. Has anyone ancountered the same? > > Tom > -- Steve Hannah Web Lite Solutions Corp.
Re: What does this mean for the future of JavaFX on iOS?
https://twitter.com/GluonHQ/status/721784242565357568 The Gluon blog post from a few months ago (when @robovm was acquired by > @xamarin) is still almost entirely relevant > http://gluonhq.com/gluon-supports-multiple-jvms/ On Mon, Apr 18, 2016 at 10:07 AM, Felix Bembrick <felix.bembr...@gmail.com> wrote: > So what do they use instead? > > > On 19 Apr 2016, at 02:52, Steve Hannah <st...@weblite.ca> wrote: > > > > According to Gluon, they're not impacted by this. > > https://twitter.com/GluonHQ/status/721784161728471041 > > > > > > > > On Mon, Apr 18, 2016 at 9:36 AM, Felix Bembrick < > felix.bembr...@gmail.com> > > wrote: > > > >> I just read this article which states that RoboVM is effectively > "shutting > >> down". > >> > >> https://www.voxxed.com/blog/2016/04/robovm/ > >> > >> Given that they seem to be a critical part of the puzzle that is making > >> JavaFX viable on mobile platforms, what does this actually mean for that > >> goal? > >> > >> Is there an alternative technology or product that can fill this void? > Or > >> is the final nail in the coffin for JavaFX to ever be a truly viable > cross > >> platform technology? > >> > >> Thanks, > >> > >> Felix > > > > > > > > > > -- > > Steve Hannah > > Web Lite Solutions Corp. > > > > --94eb2c0561622831410530c52f17 > > Content-Type: text/html; charset=UTF-8 > > Content-Transfer-Encoding: quoted-printable > > > > According to Gluon, theyre not impacted by > this.= > > https://twitter.com/GluonHQ/status/721784161728471041;> > https://t= > > witter.com/GluonHQ/status/721784161728471041 >
Re: What does this mean for the future of JavaFX on iOS?
According to Gluon, they're not impacted by this. https://twitter.com/GluonHQ/status/721784161728471041 On Mon, Apr 18, 2016 at 9:36 AM, Felix Bembrick <felix.bembr...@gmail.com> wrote: > I just read this article which states that RoboVM is effectively "shutting > down". > > https://www.voxxed.com/blog/2016/04/robovm/ > > Given that they seem to be a critical part of the puzzle that is making > JavaFX viable on mobile platforms, what does this actually mean for that > goal? > > Is there an alternative technology or product that can fill this void? Or > is the final nail in the coffin for JavaFX to ever be a truly viable cross > platform technology? > > Thanks, > > Felix -- Steve Hannah Web Lite Solutions Corp.
Re: Fx questions
There are some missing javascript APIs in the JavaFX web view. Here is a blog post I wrote a while back on some of my experiments with it. http://sjhannah.com/blog/?p=404 Steve On Thu, Oct 29, 2015 at 3:27 PM, Kevin Rushforth <kevin.rushfo...@oracle.com > wrote: > One correction. We do not use Nashorn as the JS engine for WebView. There > is an RFE to switch to Nashorn, but it is untargeted. See > https://bugs.openjdk.java.net/browse/JDK-8091505 > > Also, the roadmap is a bit out of date. We'll update it in the next few > days with the information we presented at JavaOne. > > -- Kevin > > > > Benjamin Gudehus wrote: > >> Hi Brian! >> >> >> >>> for unit testing on Linux servers, is monocle a good bet? >>> >>> >> >> In case you simulate user input (mouse, keyboard, touch) you need to use >> the Glass robot instead of AWT robot when using Monocle. I observed some >> different behaviour and timing problems in my tests with Glass robot. >> >> >> >>> when embedding html5 pages into fx apps, should we expect it to >>> >>> >> render/behave similar to popular browsers like chrome? >> >> AFAIK JavaFX just uses the Webkit rendering engine, so rendering should be >> more or less exactly like Chrome (they use their fork Blink, but there are >> not that much differences, yet). For JavaScript execution the Nashorn JS >> engine is used. >> >> >> >>> do you have a public roadmap for fx? >>> >>> >> >> I guess there is some information on the OpenJFX project page. >> >> >> >>> what is status of scenebuilder? Is it supported, and still worked on? >>> >>> >> >> I saw some commits in the SceneBuilder repository in the last few days. >> Binaries are provided by Gluon. >> >> Regards, >> Benjamin >> >> >> >> >> On Thu, Oct 29, 2015 at 10:58 PM, Brian Harris <brianfromore...@gmail.com >> > >> wrote: >> >> >> >>> Hi fx devs, a few questions. >>> >>> - for unit testing on Linux servers, is monocle a good bet? I got it >>> working by adding monocle jar to ext classpath >>> >>> - when embedding html5 pages into fx apps, should we expect it to >>> render/behave similar to popular browsers like chrome? I'm wondering if >>> we >>> can expect this to just work or if things may be a bit wonky. >>> >>> - do you have a public roadmap for fx? >>> >>> - what is your recommendation for lifecycle management, ie creating >>> controllers with injected dependencies. I saw afterburner looked nice, we >>> have spring working too. >>> >>> - what is status of scenebuilder? Is it supported, and still worked on? >>> >>> Thanks, >>> Brian >>> >>> >>> >> -- Steve Hannah Web Lite Solutions Corp.
Re: Java & JavaFX on mobiles
I recall reading that these JDKs won't include any UI components. Since iOS doesn't support JIT, the iOS port of JDK will certainly be AOT compiling. On Wed, Oct 7, 2015 at 2:11 PM, Felix Bembrick <felix.bembr...@gmail.com> wrote: > The world of Java and JavaFX is growing more confusing than ever it seems. > > Some say Oracle is cutting back on funding for Java because it is > effectively helping its competitors. Sounds similar to Google forking > WebKit so they weren't writing code for Apple. > > But now we hear of the looming release of official JDKs for iOS and > Android from Oracle. > > Will these JDKs be the best and simplest way of running JavaFX on those > platforms? Without JIT support, will these JDKs support AOT compiling? > > Do the proposed JDKs for mobiles even include JavaFX? > > Felix -- Steve Hannah Web Lite Solutions Corp.
Re: Differences between WebView and Webkit
To sort of answer my own question, I found out that the JavaFX webview is missing quite a few APIs that are present in Webkit. This is the result of the HTML test I ran: https://html5test.com/s/71bdbe284015d02b.html This gives me a starting point so I can create polyfills if I want to move forward. Steve On Wed, Jun 24, 2015 at 8:41 AM, Steve Hannah st...@weblite.ca wrote: I have a javascript app that is not loading in the JavaFX webview (JDK8). User agent string indicates WebKit 537.44, so I downloaded the nightly build for WebKit 537.44 to test, and the app works in that. No errors are reported in the webview (I've hooked up change listeners, error listeners, etc...), and I hooked up Firebug lite - but it also doesn't report any errors -- likely either errors are occurring before the page is loaded (i.e. before Firebug lite is added). Does WebKit 537.44 use the exact same Javascript engine as the WebView that reports 537.44 as the webkit version - or are there some differences? -- Steve Hannah Web Lite Solutions Corp. -- Steve Hannah Web Lite Solutions Corp.
Differences between WebView and Webkit
I have a javascript app that is not loading in the JavaFX webview (JDK8). User agent string indicates WebKit 537.44, so I downloaded the nightly build for WebKit 537.44 to test, and the app works in that. No errors are reported in the webview (I've hooked up change listeners, error listeners, etc...), and I hooked up Firebug lite - but it also doesn't report any errors -- likely either errors are occurring before the page is loaded (i.e. before Firebug lite is added). Does WebKit 537.44 use the exact same Javascript engine as the WebView that reports 537.44 as the webkit version - or are there some differences? -- Steve Hannah Web Lite Solutions Corp.
Re: IOS support?
I've been using Codename One for almost two years. I have been quite happy with it for mobile dev projects. It's all Java though.. No Objective-C unless you need to implement a native interface. Its UI API is similar to Swing -- very different than JavaFX. Steve On Tue, Sep 9, 2014 at 3:38 PM, Chris Bensen chris.ben...@oracle.com wrote: I know of a couple people that have dabbled with codename one. I think he liked it, but he didn’t like working in Objective-C. Chris On Sep 9, 2014, at 1:50 PM, Tony Anecito adanec...@yahoo.com wrote: Thanks Danno I have heard of that one. Also, I am looking at codename one have you or anyone else heard about that solution? Best Regards, -Tony On Tuesday, September 9, 2014 2:10 PM, Danno Ferrin danno.fer...@oracle.com wrote: There's a JavaOne session for that: Java on iOS? Yes, You Can! [CON3698] • Henric Müller - CEO, Trillian Mobile AB • Niklas Therning - Head Geek, RoboVM / Trillian Mobile AB Tuesday, Sep 30, 11:00 AM - 12:00 PM - Hilton - Yosemite B/C https://oracleus.activeevents.com/2014/connect/sessionDetail.ww?SESSION_ID=3698 On Sep 9, 2014, at 12:59 PM, Tony Anecito adanec...@yahoo.com wrote: Hi All, Does someone plan to support Java on IOS? Be great with the inroads openjfx has made with Apple to get java running on IOS so developers do not have to use ObjectiveC. Perhaps someone has a swing/jfx jvm running on IOS or something close to supporting both? Thanks! -Tony -- Steve Hannah Web Lite Solutions Corp.
Re: Canvas initial delay issue
My guess is that the first time this runs, it is rasterizing the ovals and
caching them as textures on the GPU - then subsequent runs are just using
the pre-cached textures. If this is the case, I'm not sure there is a
simple solution for speeding up the first run.
On Mon, May 12, 2014 at 8:40 AM, Renato Rodrigues r...@icmc.usp.br wrote:
Hi all,
I'm trying to convert some Java2D code to JavaFX and I'm stuck with an
issue regarding the performance of the JavaFX Canvas. At some point, I'll
have to draw thousands of small circles on the screen.
My problem is on the first drawing, on which my code takes a lot of time to
execute. But if I have to perform a second drawing, it takes only a
fraction of the time to draw (it is at least 10 times faster).
Is there anything I'm doing wrong? Is there any way to prevent that initial
delay?
I wrote this code to test it. In this code I draw 500,000 circles at random
positions on a 1000 x 1000 canvas (built previously). I linked this code to
a button click event, and on the first time I click it takes 10 seconds to
execute. But if I just click again, it takes only 0.025 seconds.
private void paintCanvas() {
long initTime = System.currentTimeMillis();
GraphicsContext cg = canvas.getGraphicsContext2D();
cg.setFill(Color.WHITE);
cg.fillRect(0, 0, canvas.getWidth(), canvas.getHeight());
cg.setFill(Color.rgb(0, 0, 0, 0.1));
Random rand = new Random();
for (int i = 0; i 50; i++) {
cg.fillOval(1000 * rand.nextFloat(), 1000 * rand.nextFloat(), 2,
2);
}
long endTime = System.currentTimeMillis();
System.out.println(Time spent on drawing: + (endTime -
initTime)/1000.0f);}
Can anyone help me to understand the reason of this initial paint delay?
Thanks in advance,
Renato.
--
*Renato Rodrigues Oliveira da Silva*
VICG - Visualization, Imaging and Computer Graphics - ICMC - USP São Carlos
--
Steve Hannah
Web Lite Solutions Corp.
Re: JavaFX versus AWT/Swing Hardware Acceleration
Prism. We do mix HW and SW in that we generate masks from a path in SW, but we cache that on the card and render it using shaders. Can you describe roughly how the caching works? I understand that the alpha mask is stored in OGL as a texture, but there are an infinite number of possible paths to be masked. How many textures can be stored at once (on say an iPhone)? I'm guessing JavaFX uses some sort of LRU caching algorithm for these textures? I ask this because I've been playing around directly with the Pisces C library directly to generate alpha masks and render them using shaders. I can see a performance increase of 4x in using alpha masks rather than full argb pixels (due to 1 byte per pixel instead of 4), but I'm curious about other savings that JavaFX makes with this method. (Hopefully this question doesn't take this thread too far off topic... my hope is that the answer to this question will help shed light on the original poster's question also). Steve
Re: JavaFX versus AWT/Swing Hardware Acceleration
Are you referring to the C version of Pisces in the FX sources? Actually, there are 2 currently in the FX source base. I'm working with the native Pisces code located in modules/graphics/src/main/native-prism/* I'm just making a 2D graphics API similar in functionality to java.awt.Graphics2D, but using Open GL ES2 to do the rendering. That pisces code is nice because it is self-contained, and hence very portable. My target platform is iOS --- I've been spending quite a bit of time lately going through the JavaFX code to try to wrap my head around how it works. Your description of the caching mechanisms here is very helpful. It confirms some of my assumptions and sheds a little bit of new light for me on the subject. Best regards Steve
