Co-bundling for christmas

[Richard Bair]

Hi guys,

> *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



> 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) .

The technical problem here is that you can only have a single plugin on the system for a given type. Since JavaFX apps are just Java apps, we cannot have a separate plugin install process for JavaFX. It has to be the same plugin as is used for Java applets.

>   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.

The trajectory for openJFX is to eventually become part of JavaSE. We will be starting the JSR process with the JCP. Our current plan is the Java 9 timeframe, though we've heard from some partners a desire to have JavaFX standardized by Java 8. In any case, at some point in the foreseeable future we hope JavaFX is part of JavaSE, and in that case JavaFX will be shipping with JavaSE.

Also, our release schedules are aligned with JavaSE in large part because we have applet fixes for JavaFX which have to be part of JavaSE. When it is shipped separately, we have major installer headaches. When shipped together, we can have a single release that is known to work. It is a huge problem having JavaFX installed separately (and it must be installed for applets to work).

Also, we need support in the platform for Mac OS X before we can ship JavaFX on Mac. Having those schedules aligned also makes sense otherwise JavaFX would always lag. Java 7 shipped before JavaFX 2.0 and this was a source of problems. Things are just simpler for us if the schedules are aligned.


>   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 no different than in normal Java deployment today. Which means, this needs to be fixed for Java.

> 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.

This is a real problem, but it isn't just a JavaFX problem. It is a Java problem. I think the other co-bundling (co-bundle Java + JavaFX + App into a single native executable) is the real right answer here. And in that case, you don't have any of the above issues and don't frankly care where Java is installed or not. The only real advantage to having Java installed on the system ahead of time is for the case of Applets. OK, to be fair, it keeps the app size smaller by pre-installing libraries, but that is less of an issue these days and with modularity it will become a very minor thing indeed.

> 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.

I think the way to think about it is:

	- Aligning the release schedules is independent of bundling -- it is useful in terms of increasing throughput on features and bug fixes (non-aligned schedules would reduce our ability to move quickly)
	- Co-bundling resolves a series of issues around applet based deployment:
		- Driving up the number of pre-installations
		- Simplified install when needing to run a JavaFX applet
		- Deliver code fixes to the plugin in a consistent manner (since the same plugin must be used for JavaSE and JavaFX)
		- Security fixes can be pushed out quickly

The problems that you mentioned in the disadvantages section really all stem from applet / JNLP deployment -- the implementation but the nature of the beast. We *must* force people to upgrade to the latest and greatest constantly or we leave machines vulnerable to fixed security flaws, and this gives Java a very bad reputation and really hurts our adoption (which is a shame because our technology rocks). But for enterprise deployments, you are really burned by this because Java isn't 100% compatible (regardless of the purity of our intentions, even bug fixes break strict compatibility). And you don't know what version of what people are running, really, and that hurts the stability of your app.

The solution I like best is one where you co-bundle Java + FX with your application as a single executable. Using modularization you can trim the size down to something reasonable. If you are doing web-based deployment, then you need the applet and things installed (or something like GWT) and you need to realize that for security purposes (in the applet case) your app needs to always be certified against the latest running version of Java. There are some schemes that might work for applet based deployment for "trusted" apps that can target a specific version of Java (and thus JavaFX) like today, but that is (IMO) asking for trouble. But anyway, I think solving this problem is a bigger problem that needs to be addressed within Java.

> 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!

Cheers!
Richard