Reliable deployment idea: JNLP Launcher exe/dmg

[Jeff Martin]

Mark, I definitely don't want Oracle to have an app store. App stores are very evil, if done right. :-)

Dan, I guess I'm mostly thinking of my deployment scenario with ReportMill (and Java Inventor). I have had good luck with our ReportMill.jnlp Web Start link because our customers are developers who generally have a working, up to date JRE. I update my ReportMill.jar about once a month and my customers get the update automatically.

When things don't work, I think it's because the browser didn't handle the JNLP-link/WebStart launch correctly, or they don't have the correct version of Java, and/or the JRE update mechanism doesn't work, or the installed JRE installation is corrupted somehow, or the cache is confused. There may also be security and/or permissions problems with a general JRE installation. Probably the best way to clear this up is to have them uninstall Java and re-install the latest version. But I can't realistically guarantee that my latest version works with all the last 10 updates or the next 100 updates of the JRE.

So having the GreatApp.exe and GreatApp.dmg options available, to me, simplifies the step of making sure that the JRE is a clean, uncompromised, compliant (for my app) installation. But I don't want a static version of my app and I don't want to have to rebuild the .exe/.dmg every time I have an update (nor could I expect my customers to regularly re-install my app).

So maybe my scenario isn't common for everyone. But I think this is a reasonably trouble free way of deploying an auto-updating app without having to send users to a generic JRE install (and then help some of them troubleshoot it). I only suggest NetBeans because building the .exe/.dmg would be a rare occurrence.

I have built a launcher like this before (Sun paid us to do one for a version of JFXBuilder years ago), so I already have some utility methods for checking for a new GreatApp.jar.pack.gz, downloading it, unpacking it and class loading it. I think it was only a few pages of code. :-)

jeff

On Dec 13, 2012, at 6:32 PM, Daniel Zwolenski <zonski at gmail.com> wrote:

> Hey Jeff, 
> 
> I don't fully follow your suggestion (i.e. which bits are native, which bits are Java and which bits are downloaded when) but I don't think it will be quite as simple as this unfortunately (I've spent many a night laying awake, staring at the ceiling trying to work out a clean way to do deployment). 
> 
> Maybe you could clarify some aspects of your suggestion though: 
> 
>  
> What if we build a Netbeans JNLP launcher project
> 
> Do you mean a new open source Java project here that provides extra deployment functionality that others can leverage? Or are you giving an example of a user creating a new "GreatApp" project that they want to launch? 
> 
> Is your launcher project native code or Java code and what role does Netbeans have in this (I wouldn't do anything IDE specific and passionately disagree with the Netbeans bias of JFX - everything should be IDE agnostic). How does the Launcher work and what does it do?
> 
> 
> that you customize with just a link to a JNLP and a splash image,
> 
> Where does the JNLP come from, what is building it - are we just building a normal JFX webstart bundle here or is this a special JNLP file? 
> 
> 
> and it builds your GreatApp.exe and GreatApp.dmg.
> 
> What builds this? To create an 'exe' you have to build on Windows (plus 32 bit on 32 bit, and 64bit on 64 bit), whereas to build a DMG you currently have to be on Mac. There's no nice utility where you just go build-me-all-my-installers-for-all-platforms. Partly this is due to technology issues with each OS (e.g. MSI's can only be built on Windows) and partly it is due to the JRE not being available for co-bundling anywhere (the only one you have is the one installed on your machine), see http://javafx-jira.kenai.com/browse/RT-22964 
> 
> If this step was small and simple, the rest of it would be easy and we wouldn't really need JNLP, webstart, etc.  
> 
> 
> The launcher app would simply fetch the JNLP, download the jars (if newer than cache), load them, and invoke MainClass.main().
> 
> This is what JNLP does at the moment. I assume you mean it add some value somewhere but I'm missing what exactly that is? Note there is even a pre-launcher MainClass in the JFX packaging tools that does some JFX checks and updating stuff (it's weird and messy).  
>  
> 
> Then on your website you can say,
> 
>         If you have Java, try the Web Start link [ here ] or
>         Download [ GreatApp.exe ] or [ GreatApp.dmg ]
> 
> In this case the JNLP file is a traditional one or something new and special? If it is a traditional one then you cannot pin it to a JRE and have all the problems we know about. If it is something special, I'm not sure what that special is or how the specialness gets hooked into the start-up process (since if you install Java the JNLP will be opened with Java). 
> 
> In this case do GreatApp.exe and GreatApp.dmg have the JRE co-bundled into them - i.e. they are just like the installers we can build now? 
> 
> If the JNLP is not special and the native installers are the same as now then I'm missing what you're adding to what we have now (i.e. you can produce the above website right now)? 
> 
> The only thing I think you might be suggesting is auto-updating of the exe/dmg based apps, which is not currently supported but planned by Oracle (unknown timeframe). Additionally there were a lot of discussions around adding AU and I have put up prototype code for this that can be used to do this (but it is raw and cludgy).  
> 
> See this discussion: http://mail.openjdk.java.net/pipermail/openjfx-dev/2012-June/002433.html
> 
>  
> 
> So the benefit over plain web start is that your GreatApp would have a consistent, self-contained execution environment, in the event that the target system doesn't have an installed JRE that is the right version or uncorrupted.
> 
> I'm missing how this happens? Can you clarify. 
>  
> You also don't get scary warning panels or signing issues.
> 
> Currently you don't have any of this with the native installers. The JRE is co-bundled and never installed so you side-step the JRE installation horrors. 
> 
> The problems with native installers that need to be addressed are: 
> - Auto updating
> - Reduce the JRE size to make smaller downloads 
> - Being able to build native releases on multiple platforms 
> 
>  
> 
> But you would still get the benefit of simple upgrades that WebStart gives you. And you wouldn't have to constantly generate a new .exe/.dmg (maybe once or twice a year if you decide a new JRE update would benefit your app).
> 
> This is basically just adding Auto Updating (AU) support to native installers. 
> 
> If your open source project is to add this then I'm in for that. I've already done a POC: http://code.google.com/p/zen-update/source/browse/trunk/
> 
> I ported JFX Ensemble to include auto updating support: http://zenjava.com/demo/update/ensemble/EnsembleWithZenUpdate-1.0.exe
> 
> Work on this stalled because the JFX deployment team were unable/uninterested in implementing the changes needed to support this work. 
> 
> Once the packaging tools get open sourced (which is overdue) then the community can take over this work (and it is on my todo list). So long as the code remains behind the Oracle iron curtain however, we are hamstrung unless we want to re-implement most of what they have done from the ground up. This is an option but seems wasteful when the OS of the packaging code is suppose to be soon (but "soon" seems to be a very loose term). 
>  
> 
> Such a Netbeans project would probably only be a dozen pages of code.
> 
> Sounds ambitious :)
>  
> Here's an even better idea - Oracle sets up a server that will take any JNLP link and dynamically generates a .exe/.dmg for us. :-)
> 
> 
> You may be interested in this JIRA for this: 
>   http://javafx-jira.kenai.com/browse/RT-22994
>   http://javafx-jira.kenai.com/browse/RT-22995
> 
> I'm keen to explore this topic with anyone and everyone wanting to do so. I like that you are looking at it but I'm either missing something about your suggestion or it's a bit too simple in it's approach to provide a solution. If I'm missing something then I really want to know what! If I'm not then I'm happy to help expose all the nasty complexities around this area if you want.
> 
> Cheers, 
> Dan  
>  
> 
> 
> 
>