Co-bundling for christmas

Fri Dec 23 01:20:55 PST 2011

Hi Daniel,

I'm not an expert on jigsaw expert if I read the draft documents I think
we'll have to rethink our understanding of the JRE/JDK because the whole
system will look more like a maven repo does today, which means you have
have multiple versions of a module (e.g. javafx-2.0.2, javafx-2.1.0,
...) in the local JRE-Repository and your application can specify itself
which one it needs.

A module unlike a jar can contain native libs as well which marks a
major improvement. I suggest reading [1] if you haven't done so already.

The question so simply comes down to if modules inside the OpenJDK can
do patch releases independently or whether it is an orchestered effort
where all modules release new bugfix versions together.

I think in future one will only download the VM + core-modules (not sure
what those are) and the rest will provided by installers (Setup.exe,
deb, rpm, dmg, ...) from your application or fetched dynamically from
the web (e.g. when an webstart app is launching) but as said I'm not an
expert on this nor I know the details but this is how I understand
JRE/JDK 8 with jigsaw applied to it.

Tom

[1]http://cr.openjdk.java.net/~mr/jigsaw/notes/jigsaw-big-picture-01

Am 23.12.11 00:58, schrieb 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!

-- 
B e s t S o l u t i o n . a t                        EDV Systemhaus GmbH
------------------------------------------------------------------------
tom schindl                 geschäftsführer/CEO
------------------------------------------------------------------------
eduard-bodem-gasse 5-7/1   A-6020 innsbruck     fax      ++43 512 935833
http://www.BestSolution.at                      phone    ++43 512 935834