Reliable deployment idea: JNLP Launcher exe/dmg

[Daniel Zwolenski]

As an aside, I agree that Oracle shouldn't try to do it's own App store -
Oracle is not consumer focused enough (and not a consumer brand name) to
compete with the other big vendors in the space. Far better to collaborate
and team up with other vendors like MS, Google, etc, to ensure smooth Java
support.

In my opinion though AppStores are the unexpected light in the dark for JFX
deployment. All of our web-based installer methods in Java are dead or
dying (webstart, applet). Native installers are our last option and are ok,
but they have a lot of issues some of which may well be unsolvable (e.g.
building installers for each platform). Meanwhile some platforms (e.g. Mac)
may well be AppStore only before long, blocking the native installer option
for us.

Ironically, we are seeing a small resurgence of interest in "desktop apps"
thanks to the mobile/smart device revolution. On mobile, "apps" and "app
stores" are seen as richer/faster/more-appealing than "web apps". On a
technical level the gap between "desktop apps" and "webapps" has been
steadily closing but "desktop apps" are getting a PR boost just by
association with the "app" concept. Meanwhile the hugely successful
commercial strategy of the iOS app store has caught the interest of the
money guys, and they are trying to work out how to replicate this on the
desktop side of things. As a result, the big players and OS vendors are
actually competing with each other to provide us with a clean, easy way to
get desktop apps onto their platforms.

Of course the trade off is we have to get our apps reviewed and go through
red-tape but as we've seen with the iOS app store, this is not an overall
barrier to development and getting apps out there. In fact the ease of
installation and the added trust users have in terms of payments, viruses
and spamware aid distribution and make the cost of dealing with the
red-tape insignificant by comparison.

The biggest risk to us within the AppStore era in the JFX/Java space is
getting locked out by the vendors. Not sure how we mitigate this risk
(maybe Ellison, Ballmer and Page could group hug?), but keeping an eye on,
and adjusting to, the licencing issues around AppStores is a good start,
e.g. we can't deploy GPL projects (such as OpenJDK based ones) into the
Apple app store (mobile or desktop) so we need to bias towards solutions
that aren't limited by this.

I never thought I'd say it, but bring on the AppStore era.




On Fri, Dec 14, 2012 at 12:43 PM, Daniel Zwolenski <zonski at gmail.com> wrote:

>
> 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 support?
>
> 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. :-)
>>
>> 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
>> >
>> >
>> >
>> >
>> >
>>
>>
>