• Aug
    • 01
    • 2013

JavaFX on iOS using RoboVM and Maven

Posted by In JavaFX, RoboVM

A bit of background

Oracle have open sourced JavaFX and included in it code that allows JavaFX to run on iOS. The only problem is they haven’t provided a way to actually run Java on iOS, which, as you can imagine, is something of a necessary first step. It’s a little bit like giving us an awesome new type of high speed rail engine – we just have to build the train that the engine goes in, and lay the tracks, and build the stations, and provide the fuel, and …

For reasons many of us don’t understand and certainly don’t agree with, Oracle have decided that the huge, complex and difficult task of getting a Java VM running on iOS is something the community should do. While there have been many loud and, let’s say, “passionate” responses and objections to this, there’s not likely to be any change on this from Oracle anytime soon.

So the community are doing what they can. Niklas Therning, from Trillian AB, has been working hard on a Java VM that runs on iOS and has released a very early access version of RoboVM. This is not the only Java iOS option but it is the one that is most ready to use with JavaFX. RoboVM compiles Java bytecode into native code that can be run on iOS. It is based on the Android Java Runtime so it doesn’t support all Java features but it comes close enough for our purposes.

Unfortunately the version of JavaFX that has been open sourced runs only on Java8 (not yet released) and RoboVM currently only runs on Java7.  To solve this part of the problem Danno Ferrin has created a backport of the Java8 version of JavaFX to run on Java7. In turn, I’ve taken the awesome work done by Niklas and Danno and combined this into a Maven plugin for RoboVM, that has special support for JavaFX in it to ease the developer workflow.

The end result has just been released and below I give you the (hopefully simple) steps to get your own JavaFX app running on iOS!

A word of warning: this is at best an alpha release! It is slow, it is buggy and the process is still clunky in places. The good news however is that there is plenty of room for things to be optimised, cleaned up and improved. Things can only get better – so don’t judge the platform by what you see now, judge the potential.

Business Time

Before getting started:

You need to have JavaFX on your classpath, so use the JavaFX Maven plugin to do this by running the following command line:

  • mvn com.zenjava:javafx-maven-plugin:2.0:fix-classpath

On mac you will probably have to run this using sudo.

Then simply check out the sample JavaFX RoboVM app:

And from the command line run your choice of:

  • mvn robovm:iphone-sim  (runs the app in the iphone simulator ) 
  • mvn robovm:ipad-sim  (runs the app in the ipad simulator)
  • mvn robovm:ios-device  (runs the app on whatever iOS device is plugged in)

That’s it!

Note: the sample app will only run on the latest iOS so make sure your device is fully updated. This is an aspect of the sample app, not RoboVM, eventually we will provide docco on how to run on older versions of iOS.

Currently there’s no automated way to generate an app bundle for the app store. The focus is on improving the performance and functionality at this stage, and commands for building App Store bundles will be added.

A little more detail

The sample app is a very simple JavaFX “Hello World” app that is setup to build and run with RoboVM. It’s designed to be a kickstarter template – take this code, copy it into your own project, and then expand on it to build whatever you want.

RoboVMSampleJFXApp.java is the entry point for the JavaFX app. From here down you can insert your own JavaFX app and make whatever you want.  In theory you should be able to more or less ignore the fact that you are in a iOS app and just build a JavaFX app. In practice, especially in this alpha release, there will be areas where things fall down but you should be able to do most of the standard JavaFX stuff.

RoboVMJFXLauncher.java is a special wrapper for your App and is the main entry point for RoboVM. It simply sets up your JavaFX application so it can run on iOS. Take a straight copy and paste of this into your own project and just change the name to be whatever you want, etc. Future versions of the Maven plugin will likely generate this class for you so you won’t have to include it, but for now just copy it in.

The project’s POM has a couple of RoboVM specifics but it is not too bad. The RoboVM Maven plugin is included and configured, and there are some dependencies onto the RoboVM runtime libraries, which you need at this stage. These dependencies may not be necessary in future versions of the plugin if we can find a way to cleanly hide them.

There are many configuration options for the RoboVM Maven plugin, letting you do things like modify your plists or set the signing agent, etc. Currently these are not well documented and you’ll have to work off the code. Documentation is on the todo list.

Where to from here

No doubt there will be many teething problems and issues. Be gentle with it, feedback is probably best first discussed on the openjfx mailing lists: http://mail.openjdk.java.net/mailman/listinfo/openjfx-dev as it will be hard at first to know what is a JavaFX issues and what is a RoboVM issue. It will be good for the Oracle JavaFX guys to see what problems are coming up anyway.

As I mentioned at the start, this is a rough, early-access, alpha release. We know it is not performant, we know it has rendering and layout issues, we know it’s a long way from perfect. Things will improve massively from here. How fast it improves depends on how much time those working on it can contribute – this is currently a completely unfunded community effort by volunteers in their free time.

If you want a robust, production-ready version of all this then you have two choices:

  • 1. Wait for it to happen
  • 2. Contribute – either time/code or talk to Niklas about how you can help sponsor his work financially

Continue Reading→
    • Jul
    • 01
    • 2013

JavaFX Maven Plugin 2.0 Released

Posted by In JavaFX

I’ve just released version 2.0 of the JavaFX Maven Plugin. The details of what’s changed in this release (a lot) are mostly covered in my previous post on the topic.

The really great news with this version of the plugin is that I’ve now got everything fully documented and the documentation is released as part of the normal release process now. You can (hopefully) find everything you need to know about the plugin at: http://zenjava.com/javafx/maven.

A big thanks to everyone who tested the plugin and gave feedback! Much appreciated!

I hope you guys find this plugin useful. As usual, post issues to the GitHub issues area: https://github.com/zonski/javafx-maven-plugin/issues

Continue Reading→
    • Jun
    • 09
    • 2013

RoboVM Maven Plugin (beta release)

Posted by In JavaFX, RoboVM

RoboVM is currently one of the biggest contenders for getting JavaFX running on iOS. As such, I’ve been working with Niklas (the guy behind RoboVM) to develop a Maven plugin for it so it’s easier to get started and build RoboVM platforms.

The plugin is now in beta release and pretty much ready to go live. It does not yet include JavaFX support as we are waiting on the final parts of JavaFX to be open sourced. Once this is done however, the intent is to extend this plugin to allow easy building of JavaFX apps for iOS running with RoboVM.

If anyone wants to have a play with the current (non JavaFX version of the plugin) and test and feedback that would be much appreciated. You need to be on a Mac and have XCode and LLVM installed (as per these steps), but you do not need to install any RoboVM components, the plugin will take care of this.

There is a very simple sample project you can copy here: https://github.com/robovm/robovm-sample-ios-app. Which is basically a Mavenized version of the RoboVM starter tutorial.

The interesting bit is, of course, the POM: https://github.com/robovm/robovm-sample-ios-app/blob/master/pom.xml

Once you have your project setup locally, simply run mvn robovm:robovm and your files will be found in target/robovm

I’m aiming to push this live before the end of the week, so any testing before then would be great.

Continue Reading→
    • May
    • 26
    • 2013

JavaFX Maven Plugin 2.0 alpha – Feedback needed

Posted by In JavaFX

It’s fair to say my existing JavaFX Maven plugin code is downright ugly. A combination of trying to cover too much ground, knowing too little about Maven at the time, and having to work around all the horrible nasties in the current packaging tools led to a code base that was pretty much unusable. I’m pretty impressed that a few of you managed to contribute fixes and enhancements!

I’ve been holding off fixing things however, as there were rumours that the JavaFX packaging guys were planning to significantly rework their tools, finally giving it the attention it desperately needs. Sadly, it seems that the packaging guys have again been dragged off into the land of tedious bug fixing. So I’ve given up waiting, and I’m now a good way through overhauling the JavaFX Maven plugin.

I’ve just put up a a 2.0 alpha-release of the plugin. This is a complete re-write from the ground up and it takes some radically different approaches. Given these changes I’m looking for two things: I need people to test this new code (especially on multiple OS’s), and I need feedback on some of the more significant changes as to whether people think these are good or not. It’s not too late to change things if needed.

Below are the steps to needed to use the 2.0 snapshot release. Further down, I list some of the more significant changes to the code – if anyone is a previous contributor, or wants to be a future contributor, you may want to read through this.

One of the good things about the new code base is that I can now generate the standard Maven docco for it (although I still need to actually document a lot of things). I’ve uploaded the current version to here: http://zenjava.com/javafx-maven-plugin/plugin-info.html

Using the 2.0 Snapshot Release

Add the Sonatype Snapshot repository to your POM:


Change your POM to use version 2.0-SNAPSHOT of the JavaFX Maven Plugin. In general most of the configuration options are unchanged, but if you’re using signed web-based deployments, you also need to change the ‘permissions’ element to ‘allPermission’. This is more inline with the way the JavaFX Packaging tools need it to be.


Additionally the commands for building things have changed. Partly this is to be more in-line with Maven’s naming conventions but also some commands have merged or been significantly changed. Here’s the list of commands:

mvn jfx:jar — this replaces build-jar, unlike before it does not merge everything into one uber-jar, instead it creates a ‘lib’ directory for dependencies and the manifest references these
mvn jfx:native — this replaces build-native and will build a native installer based on the settings
mvn jfx:web — this replaces build-webstart and it now uses the JFX packaging tools directly instead of templates, it build both a webstart and applet output
mvn jfx:fix-classpath — puts jfxrt.jar on your JVM’s classpath, same as before
mvn jfx:generate-key-store — generates a testing key store for you, same as before
mvn jfx:run — starts your app, same as before

That’s it at this stage. From a user’s perspective, the main thing is we don’t bundle everything into an uber-jar anymore (this was the root cause of many problems for many people).

Additionally I am now using the JavaFX Packaging tools directly for the web stuff, which is both good in that you get more features (like applets, etc) but bad in that you lose the powerful templating system that I had before. I’ve done this mostly for ease, and if people really want the templating system back in, let me know and we can look into it.

What I really need is for you guys to have a crack at using this new plugin and the new commands and tell me firstly if it works or blows up, and secondly if you like it or hate it. You can either comment on this post, or raise issues in GitHub.

Changes in the 2.0 Codebase

If you were one of those brave few who managed to work out the old codebase, the good news is, the new stuff is MASSIVELY simpler. The new codebase is now down to a few, nice, self-contained classes: https://github.com/zonski/javafx-maven-plugin/tree/master/src/main/java/com/zenjava/javafx/maven/plugin

Firstly, I’ve done the reflection completely differently. So now the code all makes direct calls onto the JavaFX packager library, instead of using the script-style invoke(target, “method”, param1, param2). This alone should make it significantly easier to work with the code, and people should be able to make contributions much more easily.

The next big change is that I’ve ditched the idea of using the javafx-deploy-lib. The point of this was to allow re-use between multiple build tools so others (such as those writing the Gradle plugins, etc) could try and use it. Turns out no one was too interested in doing this, and since it just complicated things for us in Maven land, I’m dropping it. Any code that was needed from this has now been brought into the plugin code base and references to the deploy lib are gone.

Additionally, I’ve also improved the inheritance hierarchy between the different Mojos. So each one now defines it’s own parameters instead of them all being defined in a common base class. This means each Mojo now only lists the parameters that are relevant to it, and the generated documentation now starts to be useful (before it looked like every param could be used everywhere).

Finally, I’ve done away with the uber-jar code. This previously unpacked and re-jarred all the dependencies into one big, executable jar. It seemed like a good idea at the time but turns out there are libraries out there that have files named the same way in them, and things like manifests get quickly trashed. All in all, this approach was a pain. The new approach now just uses an external ‘lib’ directory where all the runtime jars are copied to, and the manifest in the main app jar points to this.

There’s a few other minor changes and fix-ups that I’ve done on the way, but these are the main things. It would be great to get some feedback on the updated code. I’m also hoping that this will open up the door to more people contributing, as it is now quite trivial to wire in a parameter or setting that’s not done yet. If you need it, add it.

Continue Reading→
    • Feb
    • 21
    • 2013

JavaFX Maven Plugin 1.5

Posted by In JavaFX

I’ve released version 1.5 of the JavaFX Maven Plugin:

The two big fixes in this one are:

  • The ‘app name’ is now being set correctly. Previously this was causing the build to fail when generating native bundles for Mac.
  • ‘src/main/deploy’ is now included in the classpath for the build tool, meaning you can add anything in there that the JFX packaging tools need. Among other things, this allows you to provide your own custom icons for native bundles (see the JFX deployment tools for details on how to do this).

Thanks to everyone who made contributions for version 1.4 and 1.5 – most of these fixes have come from the community or as  a result of community feedback and input.

As I mentioned in my last post, I’m off travelling for a couple of months and won’t be doing anything on this plugin during that time. I am intending to integrate it with the work the JavaFX deployment guys are doing when I get back though. So keep raising issues and requests and we’ll see what we can do with them in a few months time.

I’ll be blogging my travels a little bit too, so if you’re after a distraction check out:



Continue Reading→
    • Feb
    • 15
    • 2013

JavaFX Maven Plugin 1.4

Posted by In JavaFX

I’ve just merged in contributions from the community on the JavaFX Maven plugin and released these as version 1.4.

Nothing else was changed apart from these contributions. I have been working with the JavaFX deployment guys trying to integrate and improve things using their recently open sourced packaging tools but the build setup for this is a mess, slowing everything down to a crawl. This work has also sucked up the small amount of free time I had available to put into this project recently.

I’m soon to be off travelling and will be offline for a good few months. If you wanted something fixed that didn’t make it into this build, there’s about a week left to make that happen. In particular, I think there is still an issue on Mac native builds. If someone wants to contribute a fix for this I will merge it, otherwise there’s a 50-50 chance I’ll put a fix in myself before I go.

If you have anything else you want fixed, raise it as an issue on the GitHub project. If you provide a fix you have a much higher chance of it getting sorted.

Continue Reading→
    • Dec
    • 04
    • 2012

JavaFX with a SpringMVC REST server in 5 minutes

Posted by In Enterprise, JavaFX

Creating a simple JavaFX application in 5 minutes was pretty fun, but we can do better. This post shows you how to use the javafx-rest-archetype to create a skeleton project that includes both a REST server (based on SpringMVC) and a JavaFX client that talks to that REST server.

As before you need to have already installed JDK 7 (update 6) or later, and Maven 3.0 or later (make sure you set the JAVA_HOME environment variable when doing this).

Step 1: Fix your classpath

If you did this last time then you do not need to do it again!

When you install the JDK currently, it includes JavaFX but does not put it on the classpath (yes this is weird – it will be fixed in Java 8). To fix this, open a Command Prompt and type:

mvn com.zenjava:javafx-maven-plugin:1.3:fix-classpath

This will ask you to confirm that you want to do this, type “y”.

Step 2: Create a New Project

Open a command prompt and go to a new workspace area (i.e. create a new directory to house your code), then type:

mvn archetype:generate -DarchetypeGroupId=com.zenjava 
    -DarchetypeArtifactId=javafx-rest-archetype -DarchetypeVersion=1.1

You will be prompted for some parameters:

  • groupId: com.mycompany
  • artifactId: my-rest-app
  • version: leave as default
  • package: com.mycompany.myrest

This will create a new directory called “my-rest-project” with some basic source code which you can use as a skeleton to get you up and running quickly.

Step 3: Build the project

Change directory into your newly created project and use Maven to build your application – this will build both the client and server:

cd my-rest-app
mvn clean install

Step 4: Start the server

Change directory into the server sub-directory and start a Jetty server to run your REST web server:

cd my-rest-app-server
mvn jetty:run

You do not have to have Jetty installed, Maven will take care of this for you. Jetty is very useful for getting up and running quickly like this, however you don’t have to use Jetty. Maven builds a standard WAR file that you can deploy into any JEE web server, such as Tomact, JBoss, etc.

Your server should now be running. You can test it using a standard web browser to http://localhost:8080/my-rest-app-server/welcome and you should see XML output like:

Step 5: Run the client

Open a new command prompt, change directory into the client sub-directory and start your JavaFX client:

cd my-rest-app\my-rest-app-client
mvn jfx:run

When the JavaFX client starts up enter your name and hit the “Say Hello” button. The response from the server will be shown in the text area below:

Step 6: Edit your project

You now have a working skeleton project which you can build upon to create your next awesome JavaFX and REST server application. Since you are using Maven, you can simply open the base level POM file in your favourite IDE and your project will be automatically configured for you with the classpath all setup, etc.

Here’s the links again for using Maven with your IDE:

Your project tree should look something like (this is taken from IntelliJ):

Hopefully the code is pretty self explanatory, and I have included JavaDoc with links to external help documentation in most cases. If you need more help, post comments here or raise issues in the GitHub project for the archetype: https://github.com/zonski/javafx-rest-archetype/issues

Step 7: Distribute your app

Distributing your server is very easy, just take the generated WAR file from the ‘target’ directory of your server module and copy this to any JEE web server. I use and highly recommend Tomcat but you can use whatever you like. In tomcat simply download and install Tomcat (i.e. unzip it) onto your server and then copy the WAR file into the webapps directory. Tomcat will take care of the rest – server side deployment is easy these days.

As with the simple JavaFX application example, you can choose any of the JavaFX deployment options such as Webstart, native installer, executable JAR file, etc. They each have their advantages and disadvantages but refer to my previous post for details on this.

All the same commands are available as in the simple JavaFX project, just make sure you run them from within the client module. For example to build an executable JAR use:

cd my-rest-app\my-rest-app-client
mvn jfx:build-jar

And an executable JAR will be built into the target directory of the client module for you to copy and distribute however you want.


Using this archetype it is very easy to get up and running quickly with a simple JavaFX client and SpringMVC REST server. All of the code generated can be modified, added to and deleted to suit your own project needs so there are no dependencies or links to any special classes of my creation in the project. This simply provides a starting shell for you to do with as you please.

This example is deliberately simple. It does not include security or database setup, both of which would be pretty much standard in your typical REST client-server application. If I get time I and/or there is strong interest in seeing a REST setup with security and persistence, I may add an additional archetype. Register your interest in this by commenting below.

REST is very popular because it provides a way for JavaScript/AJAX clients to make remote calls on servers. I’ve provided this archetype because AJAX is such a popular space, however there are better, faster and simpler options than REST when working with pure Java on both the client and server, so why compromise? I am planning to create another archetype that creates the same setup as this one but using Spring Remoting based on Spring’s HTTPInvoker. Hopefully I will have something going on this over the next month or two – again register your interest by commenting if this is something you would find useful.

If you have any problems or suggestions please comment or raise an issue on the archetype GitHub project:  https://github.com/zonski/javafx-rest-archetype/issues

Continue Reading→
    • Nov
    • 24
    • 2012

From Zero to JavaFX in 5 minutes

Posted by In Enterprise, JavaFX

Over the last few weeks, I’ve been working on a new Maven Plugin for JavaFX. Using this plugin it’s much, much easier to get up and running quickly and to build complicated distribution bundles (such as executable JAR files, native installers and webstart bundles). Rather than tell you about it, here’s the steps to take you from nothing to a fully working, packagable JavaFX distribution.

Before starting you will need to have installed JDK 7 update 6 or later, and Maven 3.0 or later. This guide will walk you through that.

Step 1: Fix your Classpath

When you install the JDK currently, it includes JavaFX but does not put it on the classpath (yes this is weird – it will be fixed in Java 8). To fix this, open a Command Prompt and type:

mvn com.zenjava:javafx-maven-plugin:1.3:fix-classpath

This will ask you to confirm that you want to do this, type “y”.

You will need to do this only once for each development machine (and you will never need to do it on your users’ machines, only development ones).

Step 2: Create a New Project

Open a command prompt and go to a new workspace area (i.e. create a new directory to house your code), then type:

mvn archetype:generate -DarchetypeGroupId=com.zenjava /
-DarchetypeArtifactId=javafx-basic-archetype /
You will be prompted for some parameters:
  • groupId: com.mycompany
  • artifactId: my-jfx-project
  • version: leave as default
  • package: com.mycompany.myjfx
This will create a new directory called “my-jfx-project” with some basic source code which you can use as a skeleton to get you up and running quickly.

Step 3: Run the Project

Change directory into your newly created project and use Maven to launch your application:

cd my-jfx-project
mvn jfx:run

You should see a basic hello world style dialog popup like so:

Note: this run command is just a pure wrapper around the maven exec plugin. There is no special JavaFX magic going on here, it’s just a convenience method.

Step 4: Edit the Project

You can now open the new project in your favourite IDE:

Since this a Maven application any dependencies you need will be downloaded, your classpath will be all setup for you and you simply can get stuck in and start editing, running and debugging your project.

The starter project includes some example FXML, basic logging and makes use of the very cool MigPane layout manager. All of this is just a guide, you can delete, edit, rename or do what you like to all of this code to create your perfectly customised JavaFX app.

Your project should look something like this, with MainApp being the main entry point that you run:

For tips on writing JavaFX applications see: http://docs.oracle.com/javafx/

For tips on using Maven to manage your dependencies: http://maven.apache.org/guides/getting-started/index.html

Step 5: Distribute your App

JavaFX applications can be deployed in a number of different ways – each option has it’s benefits and drawbacks - choose whichever option suits you.

Executable JAR file 

From the command line, and in the base directory of your project (where the POM file is) type:

mvn jfx:build-jar

Your executable JAR will be found at: {project.dir}/target/my-jfx-project-1.0-SNAPSHOT-jfx.jar

The Executable JAR file option is simple and handy as you can easily send the single JAR around to users and they can just double click it. It does require Java to be already installed on the user’s system though, and there’s no support for auto updating and advanced functions (like menu shortcuts, file associations, etc). Also be aware that if your jars contain files with the same name then they will clobber each other (see this issue)

‘BAT’ file (for Windows)

From the command line, and in the base directory of your project (where the POM file is) type:

mvn jfx:build-win-bat-bundle

A directory containing a Windows batch file  and all project JARs will be found at: {project.dir}/target/win-bat

The ‘BAT’ file option is great for quick demos, you can easily copy the directory to your demo machine and tweak the JAR files and scripts as needed. It does require Java to be already installed on the user’s system and java.exe being on the path, so it’s more for internal use than general end user consumption.


Webstart applications can either be signed, or unsigned. If they are not signed then they are limited by the browser’s sandbox. Most interesting applications will need to be signed and to do this you need to get a certificate to verify you are who you say you are.  For development this can be a pain, so the JavaFX Maven plugin includes the ability to generate a quick certificate for testing (i.e. you will be able to deploy but your users will see a “this app is not trusted” message when they run it).

To generate a certificate run the following command in the base directory of your project (change the domain, country code and state to match your details):

mvn jfx:generate-key-store -DcertDomain=com.yourcompany -DcertCountry=US -DcertState=WASHINGTON

You only need to do this once for your project and you can optionally check this development keystore into your source control so other developers can avoid this step.

To then build a Webstart bundle run:

mvn jfx:build-webstart

A directory containing  a HTML file, JNLP file and your signed JAR files will be found at: {project.dir}/target/webstart

You can copy this directory directly to any web server and point users at the HTML file to run your app. Both the HTML and JNLP files are built from velocity templates which you can customise to be anything you want.

The web-based distribution, and auto updating of Webstart are great in theory, but it doesn’t work that well in practice. Use webstart only if you have control over the operating environment (e.g. you are running within a corporate IT network and can control Java versions, etc). Don’t try to use it for delivery to the general public – it just won’t work and will cause you lots of grief.
 Some other things to be aware of with webstart  depoyment:
  • browser security issues means Java will always be auto-updated, your app may break at any time if a future version of JavaFX changes the way your app works
  • there is a trend away from browser plugins and this option is not likely to be supported on major browsers soon

Native Installers

To build the native installer for your current OS run:

mvn jfx:build-native

Your bundle will be built into: {project.dir}/target/bundles

Currently native installers require you to first manually download and install an extra packaging tool specific to your OS. e.g. on Windows you need to install WiX. See the JavaFX packaging guide for more info.

Native installers are a recent addition to JavaFX, basically wrapping your Java program in a native launcher for your platform (i.e. an ‘exe’ on Windows) and bundling this into a native platform installer (i.e. an ‘MSI’ package on Windows). The JRE is actually co-bundled into the installer so your user just installs your application and does not need to install Java separately. From the end user’s perspective the whole thing is ‘native’ and the fact that your app is a Java app is hidden from them completely.

This is a very powerful option and has a lot of promise (and is the approach I would recommend) but there are still a couple of drawbacks. The main one is that you can only build the distributable for the target platform on that platform, i.e. you can only build a Windows MSI on a Windows machine, and a Mac PKG on a Mac machine. Additionally you have to download and install a third-party packaging tool that the JavaFX packing tool uses under the hood (i.e. on Windows you have to download and install WiX). I am working on extending the Maven plugin to do this last step for you.

The other major drawback is that the JRE is currently very large (70MB+) making your distributables large. This is something the Java community is (very slowly) working on, and once I get the other parts of this plugin working I may also put some effort into fixing this – it should be possible to get the bundle size under 20MB.

Finally there is no auto-updating code as yet, so each release your users must uninstall the old version and install the new one. Again this is something on the JavaFX to-do list but it hasn’t got a lot of attention. If it is something that you want, best to raise it in the open JFX mailing list.

Native installers is where I intend to spend the most effort going forward as I believe it is the only real long term option for JavaFX. I plan to release a version of the Maven plugin that can automatically download WiX for you sometime in the next few weeks. After that I will look at options for doing something similar for Mac and Linux bundles. 


The Maven Plugin makes it simple to get up and running with JavaFX and to build distribution bundles.  Your projects are also IDE independent (i.e. developers can use IntelliJ, Eclipse or NetBeans on the same project without problems) and you get all the cool dependency assistance that has made Maven such a popular tool. There’s little reason not to use it.

The Plugin is quite new however and since I develop on Windows, it has not been tested on Mac and Linux. If you run into any trouble on these other platforms, please raise an issue (general testers on these platforms would be great).

Currently the plugin does not support Applets. This would be trivial to add but since Applets are virtually a dead technology I have not bothered. If this is something you would like to use, raise an issue.

I also have not added Mac/Linux shell script options (i.e. similar to the Windows BAT option). Again these would be trivial to add but I don’t have environments to test on. If you have a need for these, raise an issue (and by doing so you volunteer to be the tester).

Several more advanced features are either missing (e.g. including native third-party libraries) or not well documented (e.g. templating HTML and JNLP files). I will tick away at these as and when I have time and motivation. I’m just one guy working on this in my free time, after-hours though – there’s plenty of work to be done here so if anyone is interested in volunteering some time, let me know.

Continue Reading→