JavaFX Desktop deployment (offshoot from: JavaFX Maven support)

[Stardrive Engineering]

Very much love the very hard but powerful feature you describe. I would extend that a bit further if possible to include the following. 

Lets say we have an app to create drawings, then that this app can publish those drawings as HTML5/SVG web pages. Then as web users discover the published web pages via the built in meta-tags the users can simply click on a button on the web page to auto download the drawing (which is referenced by the web page and published to a the same host or even linked to lets say a Lucene/Solr index somewhere). 

Then if the clicking user does not have the drawing app it is first auto downloaded then the running app auto loads the drawing. If the user does not have JavaFX it first installs that then the app then loads the drawing. 

Consider the published drawing to be an advanced form of landing pages. So, if the maker of the drawing app wanted to publish 1000 cool drawings with different meta-tags each they would have 1000 web agents at their service serving them very well.

Another consideration for the optimal smart installer (that JavaFX can then use to dominate the world :-) would be licensing. Having optional hooks to build in something like the Nalpeiron solution would be very nice. See http://www.nalpeiron.com

Stardrive


On 2011-12-07, at 5:50 PM, Daniel Zwolenski wrote:

> Thanks for the in-depth info Igor. The pieces of the puzzle are starting to
> become clear to me, sorry it takes my head a while to get in gear :)
> 
> I've renamed the thread (again) to reflect the direction this conversation
> is taking. I think the Maven conversation is now separate and should be
> continued off on its own. If this thread is not a correct conversation for
> this forum, please let me know and I can take it to the forums, or wherever
> you think it should belong.
> 
> Summing up: the deployment complexities seem to be mostly centered around
> embedding JFX within a Browser, which makes a lot of sense (it's fairly
> amazing this can be achieved at all). Additionally there are some
> challenges with maintaining a 'current' JFX install and auto-updating this
> when new releases are made. The focus of the install+plugin is mostly in
> solving these two issues.
> 
> The reason I was simplifying the deployment in my head is because the two
> issues are not features that I use in my deployment. The end result being
> that I am having to jump hurdles that don't make sense in my scenario.
> 
> My apps are mostly desktop business apps, often used in the 'back-office'.
> It is rare for me to use Applets or have a need to embed my application in
> a Browser. I also often don't want auto-updates of JFX (or the JRE for that
> matter) as there is often corporate policy/control over this, which
> mandates installation privileges and tries to ensure all desktops in the
> organisation are running the same version of things, etc. The sys admins
> would want to know about and control any updates, especially security
> holes.
> 
> Perhaps the end result is that the current webstart deployment mechanism is
> not actually for pure desktop apps, and we instead need to look at an
> alternate mechanism like the ones you have suggested. What desktop app
> developers really need is something like a (free) InstallShield for JavaFX,
> that also includes automatic updates. For desktop apps, the web is a
> distribution mechanism, not the application platform/runtime.
> 
> As a thought-experiment I've tried to come up with the perfect deployment
> user experience for a pure desktop app, ignoring the fact that applets even
> exist. It would be nice to work backwards from this to see what can be
> achieved, whether it is a case of updating the deployment tools, creating
> new ones in JFX, or this feature being left to third-party tools (like Java
> installshield, but it is currently not in a good state).
> 
> *Background*
> 
> Lisa is a business user at ACME mining, responsible for determining its
> carbon footprint in order to reduce greenhouse gas emissions. Lisa has just
> learnt of a new product called FootprintFX, a desktop application for
> calculating carbon footprints, built in JavaFX. Lisa is a Windows 7 user
> with basic technical skills. She has no Java installed on her machine and
> has no idea what Java or JavaFX really are.
> 
> *Installation steps*
> 
>   1. Using her favourite web browser and google, Lisa finds the home page
>   for FootprintFX and clicks the 'download for Windows7 now' button
>   2. The browser downloads an exe to Lisa's computer, which she then runs
>   3. Windows security pops up a message (as it likes to do) saying "do you
>   want to let this program make changes". Lisa hits yes.
>   4. The executable detects that Java is not installed. It shows a screen
>   asking the user if they would like to install it and the directory to
>   install to. Lisa leaves it at the default directory (c:\Program Files\java)
>   5. The executable shows a combined T&C for using Java, JavaFX. Lisa does
>   the usual - ticks 'I agree' without reading it and hits 'next'
>   6. The executable installs Java and JavaFX to the location specified
>   (JFX is installed in the same directory as the JRE). Lisa just sees a
>   single progress bar for all this, with no dialogs popping up, etc.
>   7. Once Java and JFX are installed the system then asks Lisa where to
>   install FootprintFX and whether she wants a Start Menu and Desktop link.
>   Lisa leaves it at the default settings (c:/Program Files/FootprintFX)
>   8. The install is complete (an icon has been added to the Start Menu and
>   Desktop - as per Lisa's selection) and Lisa has the option to 'Run Now'
> 
> *Running *
> 
> 
> 
>   1. Lisa clicks the desktop shortcut or start menu link
>   2. The application shows the custom splash screen for FootprintFX while
>   behind the scenes Java is loading and the FootprintFX main window is being
>   created.
>   3. On startup a check is made back to the FootprintFX for any updates.
>   If an update is found, Lisa is given the option to update to this new
>   version automatically. If Lisa clicks yes, then the new jars/resources are
>   downloaded and the JVM is restarted with the new details.
>   4. Once the latest code has been loaded, the splash screen is hidden and
>   the application is run. Although the jars are not signed, the application
>   has all permissions (i.e. no sandbox).
> 
> *Variations and comments: *
> 
>   - If the user already has Java and/or JavaFX installed the installer
>   should just use these and skip this whole step.
>   - If the user has Java installed but not JavaFX, the step should just be
>   the install of this
>   - If the user has an older version of these, it should give the user the
>   option to upgrade the current install, or install a seperate version
>   - Auto updates (of Java, JFX and/or the app) should be configurable by
>   the creator of the installation package
>   - The installer should be able to map file types to the installed
>   Application - i.e. I should be able to make files of type .cfp (carbon
>   footprint) get directed directly to FootprintFX.
> 
> There is one very hard feature but very powerful feature that would be
> awesome to have. It would be incredibly useful to be able to have something
> like an  'application url', where we can embed this url inside an email or
> web page, and when a user clicks on it, it opens the local desktop
> application but passes in parameters to it. This is the same idea (and
> would be used in the same way) as web browser URLs, which launch the local
> web browser and pass an address to it.
> 
> Being able to embed a link in an email to a page on the web has been
> incredibly useful for web apps. Being able to embed a link in an email to a
> 'place' within an application (e.g. open FootprintFX and point it to the
> 'flights calculation page' with flight details prepoluated) would be
> amazing.
> 
> I don't know how this would be achieved however. The only way I can think
> of is to use a URL that opens a web page that then triggers the launcher to
> be run passing in parameters, i.e. hijack the browser way of doing it and
> then hook in a Java trigger. Not ideal, but otherwise both the operating
> system and the email browsers (and web browsers) would need to support an
> 'application URL' and I'm not sure that's achievable. Something like this
> would be the place to start looking I guess:
> http://msdn.microsoft.com/en-us/library/aa767914(v=vs.85).aspx Each OS
> would do this differently if it does it at all.
> 
> 
> Interested in hearing a variety of thoughts on this topic. What do other
> people see as the key deployment issues/models/options for JavaFX?
> 
> 
> 
> On Wed, Dec 7, 2011 at 5:56 PM, Igor Nekrestyanov <
> igor.nekrestyanov at oracle.com> wrote:
> 
>> Hi,
>> 
>> 
>> To be able to launch JavaFX application embedded in the browser or using
>> 
>>> Webstart we need to have JavaFX aware plugin/deployment stack to be
>>>> registered in the browser.
>>>> 
>>>> The plugin to run Java makes sense, and this has been around for a while
>>> now. Improving it is nice, but this should be done back in the core JRE
>>> area I would have thought? It's the 'install' of JavaFX that I am confused
>>> about. I'm possibly over simplifying things but if JavaFX is just a jar
>>> and
>>> some native DLLs then isn't it just another library that gets added to the
>>> classpath like everything else?
>>> 
>> No, unfortunately it is not that simple.
>> 
>> First of all plugin and webstart code used to be inherently Swing/AWT
>> based.
>> To get most of JavaFX (at least performance wise) you do not want to run
>> it in the heavyweight AWT container or load Swing/AWT classes.
>> 
>> Browser integration is not that simple if you want to use hardware
>> acceleration in browser window.
>> There is special code in JavaFX to attach stage to window handle provided
>> by the browser.
>> 
>> Obviously Java plugin in JRE6 has no idea of JavaFX existence as it was
>> implemented years before it.
>> Hence to be able to support users who stuck with JRE6 and can not switch
>> to latest JRE7 (or 8) we
>> are shipping updated copy of deployment with JavaFX.
>> 
>> JavaFX-specific changes are merged back into JRE source base. E.g. JRE7
>> update 2 has (almost) the same deployment stack as JavaFX 2.0.2.
>> But deployment code need to be in sync with JavaFX code and dependencies
>> are tight. So, as we march to support new platforms (Mac/Linux)
>> source bases will again be different for some more time.
>> 
>> Eventually JRE will include full JavaFX capable plugin and there will be
>> no need to include it into JavaFX (assuming most of the users will migrate
>> to
>> new version of JRE). But this likely will take time.
>> 
>> 
>>> Ideally installing the plugin(s) really needs to be simple (1 or 2 click
>> install). Currently the Java one takes me off to another page and makes me
>> jump through a lot more hoops and then the > JFX one has another go at me.
>> It would be great if we could work out ways to avoid these hoops. Maybe the
>> co-bundling will fix all this, but it would be nice to just streamline
>> everything as
>>> soon as possible.
>> 
>> Cobundling should improve things a little but in general i agree user
>> experience could be improved.
>> We would be happy to hear about possible ideas of how to improve the
>> process (and yet satisfy legal requirements such as accepting the license).
>> 
>> 
>>> We also assume that JavaFX runtime is shared install per system (or
>> 
>>> eventually per user) and then we want to be able to keep track of what
>>>> users have installed/use and autoupdate it when important updates are
>>>> available (e.g. security).
>>>> 
>>>> This is a risky approach, especially for developers. I often have
>>> multiple
>>> JDKs and JVMs installed on my machine which means I need the correct JFX
>>> install in each.
>>> 
>> There is a difference between developer who needs SDK to build app and
>> user who only needs runtime to run app.
>> We are not autoupdating SDK as it can not be used by attacker.
>> Like with JDK you may still have multiple JavaFX SDK installed (at least i
>> do not see why not).
>> 
>> Runtime is different. Whenever you open web page with javafx application
>> it will be launched using installed runtime.
>> And if this runtime is vulnerable then user is in trouble. Keeping it up
>> to data and secure is important.
>> 
>> If you really need to test with older version of runtime then you can
>> install it and decline offers to autoupdate it.
>> 
>> 
>>> I currently have a system where it thinks I don't have JFX installed but
>> I do, but not in the JRE the browser is using, but the deployment tool
>> won't let me install it because it thinks I have it
>>> already installed. In fact each of the computers I use (3 of them) seem
>> to do something slightly different when I try to run an applet and
>> something different again when I run a webstart app > (and rarely do they
>> work, and never with any real message on why they failed).
>> 
>> Sorry to hear that.
>> Would you mind filing issues on this and providing us with trace/log files?
>> 
>> 
>>> My best guess is that the multiple versions of stuff is confusing the
>> deployer. I have 64 bit and 32 bit versions on my machine at the same time
>> too, as some of the native libraries (e.g. finger print scanner) that I use
>> need this.
>> 
>> Well, in theory both plugin and webstart are supposed to use one "latest"
>> version as it should supersede others.
>> If you have both 32 and 64 bit versions then there are 2 "latest" versions
>> and they are selected depending on whether your browser is 32 or 64 bit.
>> (Most of the browsers are still 32 bit).
>> 
>> Typical source of the issues right now is that JRE6 is not fully updated
>> to be JavaFX aware and if JRE6 is installed/uninstalled/upgraded while
>> JavaFX runtime is installed then it can corrupt registry. Also, before
>> 2.0.2 installer had nasty bug and if JavaFX runtime was installed by one
>> user then another user could neither install it nor use it i think.
>> 
>> We are solving these issues as we learn about them. Please report bugs to
>> JIRA and we will do our best to make it more robust.
>> 
>> 
>>> When we have multiple versions of JFX out there, we will end up with
>> JNLP files specifying specific specific versions to use (as we see now with
>> Swing and JRE versions). If a jnlp file sepcifies an older version of JFX
>> is required (i.e. I don't want my code to run on the latest because it
>> causes me problems, etc), then what will the install tools do in this case?
>> 
>> Current thinking is that we will only allow to specify minimal version
>> assuming all JavaFX version in the same family are backward compatible.
>> I.e. you can request 2.0.2+ but if user has 2.0.3 installed you can not
>> request him to install 2.0.2.
>> 
>> 
>>> What exactly are the security risks associated with JavaFX? How does
>> this differ to say me using another display library like SWT or any toolkit
>> like GWT, or hibernate, or spring.
>> 
>> The biggest difference is that JavaFX will likely be preinstalled on large
>> number of systems and shared between different applications.
>> It does not come as private part of the application (by default).
>> 
>> 
>>> We also use the fact that JavaFX runtime is installed to be able to
>> autodetect runtime install path when standalone application is being
>> launched
>> 
>>> 
>>> Can you elaborate on why standalone apps would need this and how they can
>>> work this out? The problem we have at the moment is exactly that the
>>> standalone app can't find the installation path (and hence the native
>>> files) without being told where it is via the system path, which is not
>>> setup by the installer. I'd be interested to understand more about this
>>> autodetect mechanism, how it is used currently, and how I might be able to
>>> make use of it.
>>> 
>> If you follow JavaFX application packaging guidelines (see deployment
>> guide on javafx.com) then result application jar will contain small
>> launcher program
>> that will be used as default entry point (e.g. when you double click on
>> jar) and it is capable of checking system requirements (e.g. presence of
>> JRE)
>> and detecting where JavaFX runtime is installed. Then it will setup
>> classpath to include required.jars and instantiate main Application class.
>> 
>> 
>> What is it
>>> that JFX does above beyond what standard JRE/JNLP has been doing for a
>>> while?
>>> 
>> E.g. embedded launcher can check this without JNLP.
>> I.e. you can ship just jar file and user will be guided how to run it as
>> long as it has java.
>> 
>> -igor
>> 
>>