First attempt at zero-install JavaFX

[subscribe] Recent blog entries

• Simple prototypal inheritance new!
• Adventures in Rhino - setters and getters
• Site improvements - fighting with Disqus
• JavaScript task chaining
• JavaScript string building benchmarks
• Efficient JavaScript string building
• Alternative JavaScript worker thread API
• Implementing JavaScript worker threads
• Thread safe DOM manipulation
• Site improvements - CSS sprites
• Trephine worker threads made easy
• Pitfalls of multithreaded browser development
• Site improvements - reducing dependencies
• The unsplittability of XML

Live Demos

• Executing arbitrary script
• Shell commands
• File browser
• Excel data extractor new!
• Persistent client side database
• Groovy demo
• JavaFX demo
• Ruby demo

First attempt at zero-install JavaFX

The JavaFX demo is now open for business. Like the ruby demo and the JavaScript demo, this demo allows the user to specify arbitrary JavaFX code, which is then compiled and run.

The one glaring problem is that even though the demo will download javafxgui.jar, the javafx.stage package is inexplicably missing at compile time, despite being loadable at runtime.

Consider this fragment:

import javafx.stage.Stage;

Running this will result in a compile error stating that the javafx.stage package is not found. However, the following runs just fine:

java.lang.Thread.currentThread().getContextClassLoader().loadClass("javafx.stage.Stage");

One blog entry that I found while researching seemed to indicate that the javafxc.jar needed to be available to the boot classpath. This is going to be very hard to pull off since the business logic that loads the Jar is powered by Java in the same JVM where we want to run the JavaFX.

I'm hopeful that there is a way to trick the JavaFX compiler into seeing non-boot Jar loaded packages, but if not, I can always startup a JVM on the side specifically for compiling and running the JavaFX side of things. This has a number of downsides though, so I'd much prefer to not have to do this. For example, running the code in a separate JVM really complicates DOM/script interaction and threadding to name just two.

If anyone has information about how to correct this problem without altering the boot classpath, please leave a comment!

Much thanks to jgran who commented on my rant about javax.stage.Stage to point out that this is indeed in javafxgui.jar despite my indication to the contrary. I thought I had looked in there, but apparently not closely enough. Thanks again!