Reliable deployment idea: JNLP Launcher exe/dmg

Mark Fortner phidias51 at gmail.com
Fri Dec 14 09:24:19 PST 2012 

Here's what's on my app store wish list:

Short-term wishes

   - A simple app store that lets me upload a JNLP and a JAR.  The app
   store would then:
      - Fetch all dependencies listed in the JNLP from the Maven Repo
      - Create all platform dependent artifacts (i.e. RPMs, DEBs, DMGs,
      EXEs)
      - Handle signing
      - Set the price & handle licensing
   - A simple app store client that sits in the dock and lets me find,
   download and update apps, and notifies me when updates are available, and
   lets me file bug reports for those apps.


Longer-term wishes

   - An open source, enterprise version of the app store that lets
   businesses distribute their own apps internally, and could optionally allow
   them to search the external app store to find apps that I want to make part
   of a "standard" desktop.  If you buy apps through the enterprise store,
   then licensing is handled at the enterprise store level, not at the
   individual desktop level.
   - The ability to republish apps from the app store to platform dependent
   app stores, thus making it easier for users to get my app.
   - A Git-hub like experience, where I can publish the source code to the
   enterprise app store, and the app store will build my app and the
   appropriate artifacts.


Business justification

   - Since JavaFX is clearly aimed at the desktop (for the time being) it's
   critical to create positive awareness of Java on the desktop.
   - The app store creates an opportunity for Oracle to incentivize
   developers who might otherwise not look at desktop development as a viable
   business opportunity.
   - The enterprise app store creates another revenue stream for Oracle.



Cheers,

Mark




On Fri, Dec 14, 2012 at 8:57 AM, Josh Marinacci <joshua at marinacci.org>wrote:

> Sun/Oracle did build a Java app store, remember? I built the GUI :)
>
> The reality is that desktop OSes are moving towards an app store model.
> Java has to adapt to this new reality.
>
>
> --
> Josh Marinacci
> joshondesign.com
>
>
> On Friday, December 14, 2012 at 5:23 AM, Jeff Martin wrote:
>
> > I can't disagree with most of that - but I also can't help but feel
> Apple set up a big toll booth for app developers (complete with bureaucracy
> and censorship). I don't want to have to go hat-in-hand to anyone for
> approval to release my app, and I don't want to part with 30% of the
> proceeds unless they are contributing serious sales and marketing effort.
> >
> > Not to cry a river for Oracle, but it seems a shame that my app(s) rely
> so heavily on Java and JavaFX, yet Apple walks away with 30% and Oracle 0%.
> Yet if Oracle were to charge 30% for their significant contribution, app
> developers might as well give up.
> >
> > I'm a former Apple employee and a stock holder - but their precedent
> scares me. And I was a Steve Jobs hero worshipper, but I always said if
> Apple was as big as Microsoft, they'd probably be at least as evil. :-)
> >
> > jeff
> >
> > On Dec 13, 2012, at 10:35 PM, Daniel Zwolenski <zonski at gmail.com(mailto:
> zonski at gmail.com)> wrote:
> >
> > > 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(mailto:
> 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(mailto:
> 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(mailto:
> 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
> > > >
> > >
> > >
> >
> >
> >
>
>
>

More information about the openjfx-dev mailing list