P4
If I run a minimal, "headless" JavaFX Script application, e.g.:
println("Hello!");
...I can see, with -verbose:class, that the VM loads 1008 classes (JDK 6u14, JavaFX 1.2). This includes Swing, Scene Graph, AWT, Java2D, font support, etc. By removing from the log only the classes that I'm sure to be GUI-specific, it's down to 566 classes. A similar Java HelloWorld (same VM) loads 300 classes. I understand that JavaFX Script's language support requires many additional classes (FXObject, Locations etc. and their depends), so the jump from 300 to 566 is something I understand; but the jump from there to 1008 with several hundreds of GUI classes is a different story.
I know that right now, it's not priority or even a plan to support JavaFX Script as a general-purpose programming language or scripting language, although I champion this idea (see http://weblogs.java.net/blog/opinali/archive/2009/06/javafx_script_a.html), and there are some valid use cases like unit testing of non-graphic classes of a JavaFX app. Anyway it would be very nice to be able to run headless programs without any dependency from the GUI toolkit support. Current status shows some unnecessary tight coupling between runtime libs from javafxc and the rest of JavaFX. Perhaps some of these classes could be loaded more lazily even by simple JavaFX programs with a GUI? Evidence from my HelloWorld experiment certainly doesn't support the idea that JavaFX makes enough effort to trim runtime dependencies, in order to optimize loading time.
println("Hello!");
...I can see, with -verbose:class, that the VM loads 1008 classes (JDK 6u14, JavaFX 1.2). This includes Swing, Scene Graph, AWT, Java2D, font support, etc. By removing from the log only the classes that I'm sure to be GUI-specific, it's down to 566 classes. A similar Java HelloWorld (same VM) loads 300 classes. I understand that JavaFX Script's language support requires many additional classes (FXObject, Locations etc. and their depends), so the jump from 300 to 566 is something I understand; but the jump from there to 1008 with several hundreds of GUI classes is a different story.
I know that right now, it's not priority or even a plan to support JavaFX Script as a general-purpose programming language or scripting language, although I champion this idea (see http://weblogs.java.net/blog/opinali/archive/2009/06/javafx_script_a.html), and there are some valid use cases like unit testing of non-graphic classes of a JavaFX app. Anyway it would be very nice to be able to run headless programs without any dependency from the GUI toolkit support. Current status shows some unnecessary tight coupling between runtime libs from javafxc and the rest of JavaFX. Perhaps some of these classes could be loaded more lazily even by simple JavaFX programs with a GUI? Evidence from my HelloWorld experiment certainly doesn't support the idea that JavaFX makes enough effort to trim runtime dependencies, in order to optimize loading time.