Co-bundling for christmas

[Daniel Zwolenski]

Hello all,

I've been thinking about the future plans to co-bundle JFX with Java and
I'm just wanting to throw out a few comments on this for you guys to think
about while eating your xmas pudding and unwrapping your bounty from the
jolly red fat man.

The bottom line to it all is this:* are we sure co-bundling is a good idea*?

*Advantages *

Here's the advantages (that I can see):

   1. Co-bundling means there are less steps for the end user to do when
   installing (i.e. you only have to install Java, instead of Java and then
   JFX).
   2. Co-bundling means that JFX will always be updated to the latest
   version via the JRE auto-updater that is installed with Java

These are the only ones I could come up with. Can anyone suggest any others?

Looking at #1 more closely, it turns out that the only thing that actually
needs to be 'installed' is the plugin to run Applets. For general code
execution, it is fine to just put the jfxrt.jar on the classpath and the
binary files on the system path (both of which can easily be done without
an 'install'). So in reality the only reason we need to do the second
'install' step right now is to install a browser 'plugin'.

If we end up deciding that co-bundling is not something we want, then there
is plenty of room for turning this process around. The (not co-bundled) JFX
browser plugin can be installed just like  normal plugin is. It could then
install Java if it is not found on the local system when it runs - making
it a smooth, friendly, single flow install. I'd argue that is actually a
much nicer way to do things anyway, since it would avoid the current Java
install, which is very cumbersome for users and not at all like a normal
'plugin' install. So while co-bundling has given us the feature of #1 it is
not the only way to solve it and other solutions exist that don't require
co-bundling (and are arguably as good or better) .

Looking at #2 more closely, this looks like a benefit at first, but it is
also going to feature in our 'disadvantages' list. By always linking to the
latest version, we have the flip side of this that you always *must* be
linked to the latest official version. This has several drawbacks (explored
in the 'disadvantages' below) and once again it could be solved without
co-bundling. Webstart is an existing tool that can be *configured (that's
the important bit!) *to check-for and download the latest versions of
specific jars from a remote location. This is all that is needed for JFX to
work and be auto-updated (i.e. each time you run, if the jnlp file says to
use the latest version, check for it and get it). This leaves the developer
with the option to choose to use a specific version or the latest (or the
latest version 2 but not upgrade to 3, etc).

So on deeper review of our 'advantages' we're actually left with no single
feature that couldn't be implemented in a way that doesn't need
co-bundling, with an end-result of something at least as good, but probably
better and more powerful.


*Disadvantages*

There are actually a number of quite strong disadvantages to co-bundling.
I'm not fully up on the whole 'modularisation' stuff planned for Java8 and
possibly some of the below will be addressed by this (please chime in if
you know), but these look like the main challenges to me (Swing has
suffered from all of these):


   1. The *release cycle* becomes entwined with the JRE. That means that
   new releases and updates can only go out when a Java release is made and
   these have to take into account the bigger feature list of the whole JRE.
   This means that JFX is not the sole driver for the speed of
   releases/fixes/upgrades. This would affect both minor fixes (e.g. updates
   to charts, css processing, etc), and major releases (i.e. when JFX v3 comes
   along will it have to wait for the next major Java release - what are the
   rules on this?). JFX will not be able to move at its own natural rate of
   improvement, it will have to fit into the JRE release cycle.

   2. We lose *control over versions* in use. Since the Java auto-updater
   is always pulling down the latest version, there is no way to pin an
   application to a specific JFX version. This is going to mean zealous
   adherence to 100% backwards compatibility for all JFX releases - this is
   both at the API level (which is not too hard to achieve) but also at the
   visual level - we cannot put a fix into JFX 2.3 for say a CSS styling
   attribute (like 'wrap-text' which currently doesn't seem to work in some
   layouts) - we must live with this being broken forever. Otherwise, when we
   release JFX 2.3 all the apps out there that have been styled based around
   that CSS attribute *not working*, will suddenly change. There's no
   situation where this is a good idea. If the developers had control over
   their upgrade path then we can be a little more flexible on the
   visual-backwards-compatible thing - i.e. the developer can adjust their
   code for the latest changes before pushing out the upgrade to their users.
   Auto-update ties our hands badly.

   3. We lose the ability to use *preview releases* (i.e. upcoming alphas
   and betas). The Java install will be tied to the latest official release
   (so currently that would be 2.0.2). Once it's all co-bundled it should then
   be impossible to run a preview release (like 2.1 is now) on an older
   version of Java (since it is, as I understand it, impossible to 'override'
   the classes/packages of the official JRE via a third-party jar). You would
   have to install a preview release of the whole future JRE (or manually
   patch your current JRE build with the new files - either way it won't be
   the simple process it is now).

   4. We lose the ability to *jigsaw from different jdks*. In particular we
   can't run OpenJRE version of JavaFX from within the Sun JRE (for the same
   security reasons in #3). This one seems like a major limitation, since JFX
   in the OpenJRE will be the bleeding edge version whereas the OpenJRE as a
   whole will likely be lagging behind the Sun JRE for the foreseeable future.
   If you want OpenJFX you must run the OpenJRE, if you want SunJFX you must
   run the SunJRE - not ideal.


*Summary*

When I first heard about co-bundling, I was stoked about how much better I
thought it would make things, and on the surface it does seem like it
should. Having done some deeper digging and thinking, and based on all the
above, I'm starting to form the view that for co-bundling: *the disadvantages
outweigh the advantages*.

The wheels are in well in motion on this, but I don't think it is too late
to turn the truck if we needed to? I think it's worth taking a step back
from the co-bundling idea, thinking it through in detail, and making a
fresh decision either for or against. If co-bundling is what we see as the
way forward then I would love to see the advantage list be defined with the
actual advantages we should be getting, and the various points in the above
'disadvantages' list pulled apart and addressed.

It's a long term target this one (as far as I understand it), so we
probably don't need to rush into anything. Take some time, think it over
and see what comes out. I'm happy to be wrong on this, but now's the time
to have the conversation, we will hit the point-of-no-return before too
long.


*Merry Xmas :)*

Well friends, that's it from me for 2011 - it's been an interesting year.
I've certainly enjoyed getting involved with this little JFX project and
I'm looking forward to 2012. I'm about to go on a technology-free road-trip
so (after this one) your inbox will be spared my rambling emails for two
weeks or so. I hope you all have a great xmas, see you next year!