JavaFX Desktop deployment (offshoot from: JavaFX Maven support)

[Daniel Zwolenski]

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
>
>