JFX build and deployment - squeaking wheel

[Richard Bair]

> a) I have it wrong, and others are building and deploying just fine -
> please tell me how you do it!

I think there is truth to this -- many of the customers I've been working with have not had a problem with deployment. There are different reasons for this -- one is that there are other commercial tools for creating pre-packaged co-bundled Java applications (this isn't a new technology we invented, it has been happening in the Java desktop world for a decade. We're just trying to make it the preferred approach and build it into our own tooling). Another reason could be that many of the other folks have much tighter control on their deployment scenario.

> b) No one is really deploying happily and the JFX team just aren't aware
> how crippling this problem is

And there are people in this bucket too.

We have customers all across the spectrum, and just about every missing feature (in Media, Accessibility, i18n, etc) are also critical P0's for those who encounter them and need the missing functionality.

> JARs and Executable JARs
> 
> Why they are unusable:
> 
>   - Require a JVM installation which is currently a horrible, scary user
>   experience and a big turn off
>   - Local classpath, JRE version matching issues, etc
>   - JFX Runtime is not on the JRE path so this needs to be co-bundled but
>   then DLL loading and JRE version matching gets weird quickly
>   - No way to auto-update the app - need to send out a JAR to manually
>   replace the app

You also need to add that some systems are configured to treat jar files as zip files, and thus double clicking doesn't work.

> Applets
> JNLP

> Again one option is to ditch them freeing up resources.

This will free up resources in 8-15 years. We have support contracts and people who pay money for this stuff, and many year support plans. Just to put this in perspective, there are no easy answers here.

> Native installers with Co-Bundled JREs
> 
> Why they are unusable:
> 
>   - Current build tools are hard to use and understand - mysterious
>   configuration options, all melded in with jnlp/applet build, all ant based
>   - Huge distribution bundle sizes due to co-bundled JRE app size
>   - Need to install third party native packagers that then get magically
>   picked up from the environment, no way to configure this
>   - Need to run a separate build on each target platform to produce the
>   native installer for that platform (not very "Java")
>   - No way to auto update apps once installed
>   - No way to easily distribute the appropriate native to the client (i.e.
>   the user has to know what OS and architecture they are on and choose the
>   corresponding native file)
>   - Limited configuration options currently, the installer itself can not
>   be overly/easily customised to make a nicer, custom tailored installation
>   experience for an application.

As I've mentioned before (and during the keynote at JavaOne 2012), this is where I want to put my effort. The difficult problem is being able to build installers from any system for any other system, but baring that, the rest is pretty solvable. We're open sourcing the javafx packager, which hopefully helps make this a little easier to contribute to.

Richard