JFX build and deployment - squeaking wheel

[Daniel Zwolenski]

Currently there is no good way to build and distribute a JavaFX
application. The options we have either don't work at all, or have such a
poor user and developer experience as to be as good as broken. This has
been the single point of frustration for me and also the primary reason my
only commercial client using JFX is considering moving off it.

For me there is no other bug or problem in the list that even registers on
the scale compared to this one. It is a show-stopper: Failure to
Launch. JIRA should have one bug: "User can't run JavaFX". Everything else
could be deleted.

There is no point in having 3D, Media, Charts, CSS, Animations or really
even a TextBox if we can't actually get the thing to run on the users'
machines. At the same time there seems to be zero interest or movement in
this area. I am left to assume that either:

a) I have it wrong, and others are building and deploying just fine -
please tell me how you do it!
b) No one is really deploying happily and the JFX team just aren't aware
how crippling this problem is

I've raised this many times before, but given the squeaky wheel policy for
feature prioritisation, I'm going to sum it all up again. As with all of my
squeaking, it comes with suggestions for you to take or refute as you like.

I think I pretty much have to address this to Richard, because no one else
seems in a position to do anything about this.

Richard, if you don't want to read all of the below, what I'd really like
to know is: *what is the roadmap for JavaFX deployment options?*

Do you plan to extend or fix any of the current JFX deployment options
(JAR, Applet, JNLP, Native) and if so how and when? If there's no plans,
well that would be just as useful to know. I know there's a focus on open
sourcing right now and I can see how that is a super high priority for you.
Where does deployment rank on the priorities list though?


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

If the JFX runtime boot classpath issue was fixed then this becomes a
legitimate deployment option but only for situations where you have control
over the users environment (e.g. an office where you can control the images
installed on people's machines). It's not ever going to be a good way to
mass distribute an application to the general public or even within a
standard business environment where the OS platform is not controlled.


Applets

Why they are unusable:

   - Require a JVM installation which is currently a horrible, scary user
   experience and a big turn off
   - Problems with the plugin detecting versions of Java installed and
   actually running (i.e. it doesn't work most of the time)
   - All sorts of security problems and issues, now and forever more
   - Don't really integrate well with the browser or the page-based browser
   model so not overly useful
   - Offline usage not well supported
   - Requires constant upgrading to latest version of JRE/JFX which is not
   safely backwards compatible - app could break with each new release

I don't think Applets are worth fixing in their current form so one option
is to ditch them entirely. This would free up some deployment resources to
work on other options and remove some nasty requirements (like forced
auto-updating of the JRE for security reasons).

An interesting alternative to applets is to port the JRE to run on top of
JavaScript and make this available as a plugin for all the major browsers.
This would allow "Java in the Browser", which is basically what Applets are
trying to do. This idea was floated by Richard a while back (i.e. I'm not
taking credit for it). Since it's all running in the browser's sand-box it
would only require the installation of the plugin, not a native JRE like we
have now, potentially removing all the security problems we have with the
current approach.

In a perfect world JFX would run in this JScript JRE but I'd actually
settle for just being able to mess with the DOM via Java. i.e. JFX would be
a (huge) bonus but the JScript VM on it's own, with access to the DOM,
would be a pretty huge win.

There are a lot of big challenges to making this work though. Cross-browser
support for this could be very tricky. The plugin would need to be a simple
one-click install, etc. My gut feel is that fixing the native installers
would be a quicker, easier win and something like this would be interesting
to look at down the road. If it could work though it would be a huge boon
to Java in the Client.


JNLP

Why it is unusable:

   - Requires a JVM installation which is currently a horrible, scary user
   experience and a big turn off
   - Problems with the plugin detecting versions of Java installed and
   actually running (i.e. it doesn't work most of the time)
   - All sorts of security problems and issues, now and forever more
   - Requires (I think) constant upgrading to latest version of JRE/JFX
   which is not safely backwards compatible - app could break with each new
   release

I really love JNLP as an ideal but it just doesn't work. Conceptually it is
flawed (because you have to do a horrible Java install in order make your
installations easier, all wrong) but at the moment it is also functionally
broken. I have tried with several different machines to load JNLP files and
every one of them has failed in a unique and special way. The main problem
seems to be JRE detection and version management, plus making the user
actually install the JRE is horrible.

Again one option is to ditch them freeing up resources.

Since the flaws all revolve around Java version management, another option
might be to provide an alternative to this. Instead of making the user
download and install the JRE, provide a native app that acts as the Java
launcher but which internally manages all the JREs. When this app reads a
JNLP file it then downloads and unzips (i.e. not installs) the appropriate
JRE into it's own local directory. It can then manage multiple JREs and
share these between apps, etc, Writing this would be easy, but the JRE
would need be made available as a zip (legally only Oracle would be allowed
to do this).

It would be a kind of "Java App Manager". It could be extended to be a Java
App store if you really wanted to, where the actual app manager could
browse a repository of apps and download and launch them as required, etc.

The big problem with this is of course getting the App Manager onto the
desktop in the first place. A plugin might be able to install it but this
might well just open up more problems. If the actual installer for the App
Manager was extremely simple (as simple as installing Chrome for example -
there's your bench mark) then perhaps it would be ok to make users do
this. If it has legs as an idea then this area would need further expanding
and thinking.


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.

This is the option with the most potential. It removes the major security
hassles with Applet and JNLP (each app is now responsible for ensuring it's
own security and updating if needed), which in turn removes the need to
force JRE automatic updates. The installation experience is not too bad
(still worse than a webapp but a lot cleaner than all the options above).

It also is the only option to potentially work on mobile platforms, and as
OS's are starting to lock down things to app-stores this is the option most
likely to survive when that trend becomes rule (i.e. a system-wide JRE and
hence JNLP, Applets and JARs are all on the cards to be blocked on Mac and
Windows before too long).

In it's current form however native bundling of JFX apps is not much above
an interesting proof of concept and is not usable in a practical way,
except in very limited situations. There also doesn't seem to be much if
any developments in this area - nothing is visibly moving forward on it.

The first problem is the size of the distributables due to the technical
and legal barriers to cutting out the fat from the JRE. Project Jigsaw was
promised to fix this but it got bumped to way too far down the track. Last
word from Richard was there was still plans to make the JRE trimmable in
Java 8 but we've got no idea what this actually means or any solid
guarantees this will happen. It sucks that we have to wait for J8 for this,
but will suck even more if J8 rolls around and it's still not possible.

The next major hurdle are the build tools. These are currently horrible to
work with, taking us back to the days of 'make' files. Having to download
and install an extra native packager is nasty (JFX is suppose to be the
packager). Having to run the build on each platform you want to distribute
on is even worse.

We need build tools that are clean and simple, that have the native
bundlers already in them (whether that means co-bundling the existing
third-party tool, or writing your own native bundlers). We need to be able
to build for all platforms from the one platform (i.e. if I run the build
on my 64 bit windows machine I should be able to produce a 32-bit, 64-bit
MSIs, DMG's, DEBs, and one day APKs and iPhone apps). I'm well aware that
there are massive technical (and potentially legal) issues to this but I
don't believe they are insurmountable.

And of course, we need auto-updating. As I demonstrated with some POC code,
this is not particularly difficult, however the current native packaging
from JFX do not provide enough features to do this properly.

Native installers look like our best bet but there is a lot of work to be
done in this area and from an outsiders view at least there seems to be
zero attention or interest in this.

If you're going to say "yes, great, why don't you contribute to the above",
I'll highlight that all of the above needs to be integrated with the JFX
deployment tools and some of it has legal issues, so even if I wanted to
spend the hours doing this, it won't be usable. I did try to assist on this
with AU code and that contribution was largely ignored.

The community can assist you to do this, but we cannot do this ourselves.

Unless that is, we totally ignore the existence of your tools and write our
own from scratch, in which case we could solve a lot of the above issues.
That's a hell of a lot of work and re-inventing the wheel though - I'd at
least want to see a roadmap on the deployment strategies planned from JFX,
otherwise we could be double-handling and anything the community does could
be superseded by JFX stuff that we didn't even know was planned or in
progress.