[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Co-bundling for christmas
From:       richard.bair () oracle ! com (Richard Bair)
Date:       2011-12-23 19:39:42
Message-ID: 804D0E57-9B43-428B-86AB-B43B3B613077 () oracle ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]