Mittwoch, 26. Februar 2014

App Start - Bringing JavaFX Applications to the End User

How to bring JavaFX applications to the end user's client?

Two possibilities:

  1. Install Java (quite up to date version...) on the client. Then use web start or applet.
  2. Package your JavaFX application so that the JRE is included (e.g. using bundling) and run it as autarc application on client side.
Let's take a deeper look into both approaches:
  1. WebStart/Applet: hmmm... maybe we ourselves are too close to industry/business scenarios, but the installation of a client side Java VM often is some hot discussion. If the discussion is valid or not - who cares at the end, if you are the poor guy to try to make your JavaFX application run at the client side.

    And even if the customer agrees to install some up to date Java VM, he/she typically is not the one who is willing to constantly upgrade the VM on all the clients later on... So it's you having to live with the fact that your WebStart/Applet-stared JavaFX application will have to run on many different Java versions...
  2. Autarc client application: yes, this often is a nice alternative, because now people are not talking about this client wide Java installation - they more or less treat your application as a native one. Who cares, if there is some bundled JRE which no one outside the application knows about. - And now you are the master of which Java version you use, there is no company policy or whatever you have to fight with.

    But...: now you are missing all the nice features that are part of WebStart/Applet: the re-loading of your client application if it changes on server side - the automated roll out of your client software, both for the initial and for the continuous installation.
So, this was the situation we were/are in: for many scenarios we want to go the "autarc application" way, but at same point of time needed something to control the roll out of the client software.

Consequence: we wrote a simple and thin framework which we called "App Start". (We did not check if this name is somehow blocked, so this is an internal project name at the moment!).


It's a client side launcher of a JavaFX application that is kept on server side. The launcher is a small Java programm that is configured by some xml-file, so that it knows what to download from where and after downloading how to start the JavaFX application.
The launcher knows the version stamp of the JavaFX application and with each start checks if the version still is in sync with the server side.

So "App Start" is some mixture out of the "autarc application" mode and the "Web Start" mode. Main difference: "App Start" is only working in the context of one JavaFX client application

As I said: App Start is a quite thin framework. And currently it's only available for Windows scenarios (sorry... but this is the 9x% of our users...), but taking over to other OSs is "just effort". We are open to share everything here - sources, docu, demos etc. are available in the links below. If this is interesting for you: please contact us (info@CaptainCasa.com), maybe this is something we can join forces.

Now the links:

Some slides (PDF)
Tutorial
Test / Demo (currently Windows only)

App Start page: http://www.CaptainCasa.com => Community => App Start Framework - please find all resources (including source code)

...as I said: the framework was born out of our concrete own requirements, but is strictly decoupled from our "normal" JavaFX development. So, it's normal water which we used for cooking, there is not too much magic inside.

One final comment: the picture above only is a simplified view on "App Start" - emphasizing the loading of the JavaFX application. On a long run a client side applications also will require a Java version update (only in the context of this autarc application!) and also an update of the starter program itself. So, in reality, everyhing is versioned and everyhing is synced if required...:


4 Kommentare:

  1. The first scenario isn't very likely. Most companies who use web start use it to deploy internal applications. They keep the JVM updated according to their own needs. They just need to be able to quickly update apps without going through some long drawn -out procedure.

    AntwortenLöschen
  2. Hi Björn,

    is it possible that you do not make mention of the real reasons for discarding Java Web Start? Our experience the last months was that the client runtime, i.e. the JVM, wasn't really controllable when using JWS. For example, asking for a specific JRE version via the JNLP file didn't work any longer as expected. This together with the so many restrictions and requirements on signing and annotating the JARs introduced every new Java version led to unusable clients on customer side and glowing hotline wires here. Knowledge on customer side to administer the effects 'away' is hardly available. So one hotfix followed the next one. In order to escape from the JUH (Java Update Hell) we decided to clone the JWS functionality within an own solution (internally called 'Java App Launcher'). This was in November last year. Since December (rollout) the work load returned to a normal level.

    Regards

    Frank Fröhlich

    AntwortenLöschen
    Antworten
    1. Yes, I 100% agree that there was quite some trouble with webstart over the various 7.* releases. (...well, we also have to see that Java is part of the security discussions all the times, so some of these changes really are good ones, e.g. duty to officially sign web start apps).

      Clearly: the negative consequence for developers and end users was to follow all these changes (e.g. updating manifest files...). - As developer you deliver(ed) something and do not exactly know if it smoothly runs with the next Java update...

      So your consequence seems to be exactly the same as ours: bundle the Java VM of your choice as a local VM of your app and have some concept to update the JAR/whatever files of your app if required.

      The only problems in this "bundled scenario" are:
      1. there is no way of browser integration (applet / webstart-link), so if your scenario requires this, if will not work. This also includes all the things coming with browser integration like single sign on.
      2. things like proxy settings to make you app connect with the net have to be repeated for each bundled app. (And each app will have its own way of configuring this...)

      ...from our perspective it would be nice to have some standard here, which is "below Webstart" and "above a plain Java Application"...

      Regards, Björn


      Löschen
    2. Hi Björn,

      of course, Oracle didn't do all the security intensification for fun. I understand them. But for me it came too late - years too late - and the proclamation was too restrained (I do not visit the official Java sites on the web every day).

      All in all Java has lost reputation for many people. It's hard to explain a non techie that all the trouble didn't had to do with the programming language itself but only with a technology around it.

      Yes, you (we) loose some comfort with the replacement. In order to reduce pain we added a very small (but nice) application to our solution that helps end users to create a shortcut for 'their' client start on the desktop. Within this little GUI you can set the necessary basic environment properties like proxy settings and so on.

      CaptainCasa is company number three who created an own solution for detaching from JWS I know about. Is there an emerging market?

      Ciao

      Frank

      Löschen