JFX build and deployment - squeaking wheel

[Scott Palmer]

On 2012-11-02, at 7:40 PM, Richard Bair <richard.bair at oracle.com> wrote:

>> a) I have it wrong, and others are building and deploying just fine -
>> please tell me how you do it!
> 
> I think there is truth to this -- many of the customers I've been working with have not had a problem with deployment. There are different reasons for this -- one is that there are other commercial tools for creating pre-packaged co-bundled Java applications (this isn't a new technology we invented, it has been happening in the Java desktop world for a decade. We're just trying to make it the preferred approach and build it into our own tooling). Another reason could be that many of the other folks have much tighter control on their deployment scenario.

We are in this group. Granted the javafxpackager, while a cool idea, was useless to us.  We bundled JavaFX with our app using custom hacks for a while.  Now we require 7u7 where it is included, and still need hacks to get it on the classpath.  But it means our distribution is a simple Zip file.  Extract and double click on our launch script and it works.  We have another product that installs our app with a bundled JRE using a standard Windows .msi installer.

Deployment is nowhere near a show stopper for us, but there are many issues that have been and a few that are restricting what we want to deliver.


>> b) No one is really deploying happily and the JFX team just aren't aware
>> how crippling this problem is
> 
> And there are people in this bucket too.
> 
> We have customers all across the spectrum, and just about every missing feature (in Media, Accessibility, i18n, etc) are also critical P0's for those who encounter them and need the missing functionality.
> 
>> JARs and Executable JARs
>> 
>> Why they are unusable:

No need to go through the list. This isn't a JavaFX issue. They have always been unusable for anyone but Java developers... But of course no sane developer would even consider a that as a distribution method for general non-techie users.  Windows *requires* an installer. Mac *requires* an Application Bundle. (Linux, well it isn't for non-techie users anyway, but you would typically make a RPM or DEB package... Of course any typical user would be clueless about such things if they tried Linux -  you would have to get your app in the Linux distros cental repository so the package manager handled everything for you.)


>> Applets
>> JNLP
> 
>> Again one option is to ditch them freeing up resources.
> 
> This will free up resources in 8-15 years. We have support contracts and people who pay money for this stuff, and many year support plans. Just to put this in perspective, there are no easy answers here.

These could work.. JNLP is still far too difficult and unreliable... But the idea isn't entirely bad. Applets mostly work, but have enough glitches that it is still better to try to get JNLP working.  Applets lacked attention from Sun back when it counted.  If they got more polish the, Flash wouldn't exist today.

>> Native installers with Co-Bundled JREs
>> 
>> Why they are unusable:

I disagree that they are unusable, in fact I think they are the best option, but they require a lot of platform specific knowledge and non-java tools.  I do agree with some of you're arguments against them though.

>> 
>>  - Current build tools are hard to use and understand - mysterious
>>  configuration options, all melded in with jnlp/applet build, all ant based

Yes. This is partly the initial blunder of javafxpackager.  That is a tool that was over engineered for the first release. It should have taken a single parameter - your executable Jar file, and produced a platform specific installer with optional embedded JRE.  
Optionally, JVM parameters and app parameters could be specified - exactly as they would be when invoking command-line 'java' 
No other inputs should be required because they can all be inferred from the Jar. E.g. If you can double-click to run it then you can find the JRE to bundle for a stand-alone app and all the dependencies from the manifest classpath.
Applet and JNLP could be generated as well, though they may need a couple more parameters, width x height that sort of thing. Nearly Everything in the JNLP could be generated automatically from the Jar and JVM params.

The blunder was disrupting the development workflow with a tool that required Ant and tried to take over established practices. Like creating a jar and signing it. We had that part figured out already.

>>  - Huge distribution bundle sizes due to co-bundled JRE app size

That has been a non-issue for many years for most desktop users.  A couple minutes of download time at most and the end users will do it.

>>  - Need to install third party native packagers that then get magically
>>  picked up from the environment, no way to configure this

Yep that is awkward.  Anyone want to rewrite WiX in pure Java + JNA?

>>  - Need to run a separate build on each target platform to produce the
>>  native installer for that platform (not very "Java")

A non-issue, since you have to test on those platforms anyway and therefore have them available.

>>  - No way to auto update apps once installed

No Oracle-provided way. You could roll your own over a weekend, or use existing frameworks (some platform specific)

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

Not true. Most web sites grab that from the browser's user-agent info.  And many users know enough anyway - they just have to know to click on the Apple, the penguin, or the Windows icon.

>>  - Limited configuration options currently, the installer itself can not
>>  be overly/easily customised to make a nicer, custom tailored installation
>>  experience for an application.

It is more extensible than I first thought, but yes it still sucks in that you still have to do separate installers using distinctly different tools.

> As I've mentioned before (and during the keynote at JavaOne 2012), this is where I want to put my effort. The difficult problem is being able to build installers from any system for any other system, but baring that, the rest is pretty solvable.

Application Bundles for Mac should be easy to make from any platform, if the launcher stub binary is part of the cross-platform javafxpackager. It's the .dmg that is tricker, but zips of app bundles work well too.. I'm guessing Linux packages could be done in a pure Java way if someone had the time to write the tool to create the RPM or DEB from pure Java (maybe it's easy?). At least the C source would be available for reference - and contamination via GPL :(. 
Windows .msi files would be hardest to deal with I think because I know of no way to make them without Windows.
If you are going to bundle an embedded JRE you will at least need to download the JRE for each platform.  Are there copies of all of the platform-specific JREs that aren't exe's or msi's or dmgs or rpms so they can be extracted and embedded by a tool that runs on any platform? Or would you include the raw JRE installer/package and have the installer bootstrap code just run it first somehow?

> We're open sourcing the javafx packager, which hopefully helps make this a little easier to contribute to.

I hope some nerds with a lot of free time take an interest in it.  :-)
The rest of us probably don't have the time to spend making javafxpackager do what needs to be done when we have our main product to be working on.  The installers are always an after-thought so no employer is going to let me spend much time contributing to javafxpackager when I could be improving the main product. (For Oracle at least it is part of the "main product")



Cheers,

Scott P.