Reliable deployment idea: JNLP Launcher exe/dmg
zonski at gmail.com
Thu Dec 13 17:43:08 PST 2012
In your exe and dmg do you want the JRE co-bundled into each? It does sound
like you basically want the existing native packaging tools but with AU
As a general aside/heads-up, I think you will likely find more problems
with JNLP than in the past, the 64bit-32bit cross-over has known bugs, and
the forced auto-updating (i.e. you can't actually pin your app to a Java
version in the JNLP going forward) causes new problems. Add to that the
risk of CSS changes being uncontainable (a change could affect anything
anywhere), and the fact that Swing was more or less stable for 10 years
whereas FX is rapidly growing and not looking to stabalize any time soon (I
hope!), and you have some pretty rocky ground to stand on.
I'd be cautious about treating JNLP with the same confidence you might have
had with it in the past. I took that approach on my project and had some
frustrated users (stuff wouldn't launch because of the 64bit issue, lots of
uninstalling/re-installing) and narrowly avoided a system death when 2.2
was released. FXML changed, breaking my code and a ComboBox class was added
which clashed with my own - since I couldn't pin my app to a version, had I
not caught this ahead of time, my live app would have stopped working the
instant users were forced to upgrade their JRE. And that's with Richard
being super defensive about backwards compatibility to the point of not
allowing interfaces in the code!
On Fri, Dec 14, 2012 at 12:17 PM, Jeff Martin <jeff at reportmill.com> wrote:
> 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. :-)
> 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
> > 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
> > 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
> > 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
> > 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:
> > 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
> > 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
> > 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
> > If your open source project is to add this then I'm in for that. I've
> already done a POC:
> > I ported JFX Ensemble to include auto updating support:
> > 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
More information about the openjfx-dev