Deploying Standalone JavaFX Applications Without Runtime Dependencies

Update 20-Sep-2015: We are about to release Excelsior JET 11 that will fully support Java SE 8 and JavaFX 8. A public beta is already available. This post is only kept for historical reasons.

Notice: This post concerns JavaFX 1.3. For JavaFX 2, please refer to the newer post.

JavaFX has slashed multiple layers of complexity off the process of development of rich client applications for the JVM. However, at the same time it has added another layer of complexity to their deployment, especially deployment of standalone applications. Now, not only (the right version of) the JRE must be already present on enduser systems, downloaded at install time, or bundled with the application, but also the JavaFX Runtime, and it better be the right version too!

One of the key selling points of Excelsior JET is streamlining of the Java application deployment process through the elimination of JRE dependency. Starting from version 7.0, the removal of JavaFX dependency will be nearly as straightforward, and you will also have your code protected against reverse engineering.

A public beta of Excelsior JET 7.0 is already available, so I have put together a JavaFX Knowledge Base article and then followed it myself to create a zero-dependency Windows setup package for JavaFX 1.2 SDK samples. (The InterestingPhotos sample is missing as I have no Flickr API key and had no time to figure it out.)

Do you develop standalone JavaFX applications? What do you think of the above?

P.S. It is possible to compile JavaFX apps with the current Excelsior JET 6.5, but you have to pack the application jar into the executable with classes, otherwise the application won’t find its own resources. This workaround will not be required in 7.0, thanks to a new feature.

Categories: Excelsior JET, Java

Tags: ,

5 Responses

  1. lukaszb Says:

    This would be what I was looking for, for a long time. But how is the licensing of javafx jars handled? As far as I know, you cannot redistribute javafx jar(s), so the only option is to let them be downloaded on application start, via JNLP preferably. I run Mac OS X so I cannot see Excelsior JET at work my self.

  2. Ole Lensmar Says:

    Sounds great! But I wonder the same as lukaszb; how is the javafx redistribution licensing handled?



  3. viktorn Says:

    That’s cool!

    Any idea why the DisplayShelf sample is so sluggish? The other samples run very smoothly (for being JavaFX)..

  4. Dmitry Leskov Says:

    @lukazb, Ole: That’s a very good question. It seems that I was a bit ahead-of-time (pun intended) with this announcement. For some reason, I assumed that the JavaFX Runtime license allows redistribution, just like the JRE binary license, especially given the Sun’s promises to open-source it. Now I see that it is not the case, in particular due to third-party code such as media codecs, and Sun has other things to do at the moment, so I do not see this resolving any time soon. 🙁

  5. Dmitry Leskov Says:

    @viktorn: No idea really. I have just run it on a legacy system (Celeron 2GHz/512MB RAM/Radeon 9550) with commit charge exceeding the physical memory size thanks to the memory pig called Firefox, and although it took almost forever to start it was responsive after that.

    My only guess it that it may be JITting some classes on your system. You can check that as follows:

    Modify the executable header to enable console. If you have Excelsior JET installed, just run
    gui - JavaFX-1.2-samples.exe in the samples installation directory.

    Run the sample using a bat file:
    set JETVMPROP=-Djet.jit.loud
    JavaFX-1.2-samples.exe displayshelf.Main

    On my system, it says:
    JITCompiler: compile $Proxy0
    JITCompiler: compilation finished in 31ms, classes: 1
    *** JIT: $Proxy1
    JITCompiler: compile $Proxy1
    JITCompiler: compilation finished in 31ms, classes: 1
    *** JIT: $Proxy2
    JITCompiler: compile $Proxy2
    JITCompiler: compilation finished in 16ms, classes: 1
    *** JIT: $Proxy3
    JITCompiler: compile $Proxy3
    JITCompiler: compilation finished in 31ms, classes: 1
    *** JIT: $Proxy4
    JITCompiler: compile $Proxy4
    JITCompiler: compilation finished in 32ms, classes: 1
    JITCompiler: total compilation time: 141ms, classes: 5

    I would say 141 ms is negligible.