Well I haven't really found any feedback from Oracle about this yet. I looked through a lot of different sources and means, but wasn't really able to get a hold of anyone on the JavaFX deployment team. I sent email to the openjfx-dev mailing list, but did not get a reply (perhaps because I am not a subscriber).
But I am basically done implementing this now for our product. I found that with Java 8, everything basically worked and did what I needed to package our Swing app with the JavaFX deployment tools. I did run into issues with the documentation of JavaFX 2.2 not having complete enough or 'real world' enough examples. But I managed to work through the issues with the help of StackOverflow.
After the work was done, I made changes to my ANT files and environment to try to get it working with Java 7u25, but that did not go well. I ran into "null" errors that simply gave me a line number (fx:deploy) and only the "null" message. Here is my fx:deploy statement:
|<fx:deploy width="1024" height="768"|
There is currently some discussion in my company about not wanting to ship Java 8 (even with the compile target set to 1.6) as part of the production self-contained app before Java 8 goes final. Thus the reason that I tested with Java 7u25 (from June). Hopefully I can convince them that as long as we fully test our app with Java 8 then we shouldn't expect any issues in production since we control the JRE via the self-contained app model.
So far this self-contained app idea has been quite a shock to the way that IT departments think of Java. They are so used to controlling / testing every JRE installation on the machines that they don't really want to embrace this new pattern. They are just now starting to approve and roll out Java 6u35. There is a lot of worry that having this Java 8 JRE self-contained in our app will negatively impact some other software product on the machine or open up security holes. Mostly the IT folks just have never heard of the concept of Java self-contained apps before.
I really hope that we see some more progress and presentations on JavaFX deployment for JavaOne 2013.
I do not understand why they would be making some fuss about this. This is similar to shipping a DLL in the app's folder instead of copying it to the Windows/System32 folder. If there are any security flaw, it only impacts the app itself and not the whole system as when there is a system-wide JRE installed, plus you do not change the JRE they decided to install for your setup/browser. If anything, they should be happy about it: the use of that particular version of Java is confined to the app only, no other app on the system uses it. If your app never goes online, none of the web/network flaws apply...
On the other hand, if would be better if the JFX deployment tools in the FX 2.x line was a bit more mature and was working correctly on Linux and Windows; currently, for me, it only produces a correct installer on Mac OS X. And on all 3 platforms its lack of options for native integration is really annoying (why install on Desktop instead of App on Mac OS X? Let me, as a developper, configure that behavior!). Still missing lots of support to put proper information in the installers (compagny info, license, pre and post install scripts) as well as a proper working chain to integrate native digital signature for the execs. Missing support for several execs generation in the same installer too (ie: my main app have several satellite tools that I'd like to put shortcuts for in the start menu).
If you have time, you may wish to create feature requests against the deployer in the JavaFX jira for some of the items in your post.
Note that some of your requests such as pre-post packaging scripts might not ever be implemented in the deployment tools (or would only be implemented as a loose shell like the maven rpm plugin), but might be delegated to some of the package specific packaging tools which the JavaFX deployment tools delegate too (for example the rpmbuild tool for rpm scripts).
While the JavaFX 2 branch is pretty much receiving very few updates now and most of the development effort is on JavaFX 8, I think a bunch of fixes and feature enhancements to the deployment tools will be added in a forthcoming JavaFX 2.2.40 release. There are 55 deployment issues addressed for 2.2.40. Some of those fixes were performed six months ago, so it is frustrating that it takes so long for Oracle to officially release them - they did seem to be making such good progress on this a year ago. If you accept or work around some of the warts in the self-contained application packaging process, the tools work pretty well (at least for me).
You can also find the deployment issues scheduled for Lombard (JavaFX 8.0). Most of the stuff you mention is not in there I think, also I think a lot of the deployment tasks which are not currently completed will likely end up getting dropped from the Lombard release as JavaFX 8 goes through a feature freeze and restricted high priority bug fix lockdown.
It may be worth investigating 3rd party tools such as the JavaFX maven plugin or JavaFX gradle plugin, you can log feature requests (or contribute code) against those projects for additional features you require - the features might end up getting deployed quicker (as long as capable people are willing and have time to work on them) than trying to integrate into the main JavaFX deployment tool code. The JavaFX maven plugin has picked up 54 stars and 13 forks on github, so it is a mildly active project.
Thank you. That is very helpful. I thought that those 2.2.40 fixes (specifically RT-24881) were going to be released in the Java 7u25 update. But it appears that was not the case (both from your statement and my testing).
If they do get into a Java 7 build before October 2013, then I will be able to consider using Java 7 again and that would make things go a lot easier with IT. Based on the current Java 7u25, is 2.2.40 really resembling Java 7u40? I saw some news on Google that JavaFX 2.2.6 was renamed to 2.2.40. But I want to clarify that 2.2.40 = Java 7u40. Of course, based on the patch speed atm (which is a lot faster than in the past) it still seems like Java 7u40 will not be available until sometime after March 2014? Or is there some other conclusion that I should be drawing from all of this confusing information/naming?
So many of these changes were completed in Fall 2012 and still haven't been made available in an official release/patch 10 months later.
There is an early access version of JDK7 update 40 that you could try to see if it works well for you.
I don't know Oracle's schedule for future releases of the JDK (other than JDK8), but I think it is likely JDK7 update 40 will be released by end of October.
> is 2.2.40 really resembling Java 7u40?
Yes. The current Java versioning scheme is just terrible, but at least it should be stable.
In the past, the target version kept changing as new unexpected security patch updates were slipped in between feature releases and JavaFX minor version numbers did not relate to Java minor version numbers. Now these things should match 1:1
> it still seems like Java 7u40 will not be available until sometime after March 2014?
No, I doubt that - it should be released a lot earlier I think. March 2014 is for the JDK 8 release - it makes sense for Oracle to release Java 7u40 earlier.
My guess is that the release will come around the time of JavaOne (end September) so that Oracle have something to talk about there (e.g. official support for packaging for Mac App store or something like that), but that is just speculation.
> So many of these changes were completed in Fall 2012 and still haven't been made available in an official release/patch 10 months later.
I think Oracle have just been doing planned and unplanned security releases since then. Oracle have a policy that no new functionality goes into security releases. The unplanned security releases pushed out planned minor feature releases - it's one of the disadvantages of JavaFX being tightly coupled to the JDK/JRE and the JDK/JRE lacking a modular deployment and delivery model. It is also one of the reasons that 3rd party tools have the potential to be a bit more agile here (though they haven't really demonstrated it much to date), especially if they don't need to directly support legacy security issue prone delivery models such as applets.
I already have a request that's been in the JIRA since last year: on some of my projects, the packaging tools (or NetBeans) is completely unable to get the proper main JAR and main class to launch right on Windows and Linux (apparently the ANT task that does the packaging is utterly unable to get those information from NetBeans) and yet it works OK on MacOS... it's been marked as fixed for u40 for ages but we got tired of waiting for Oracle to have the fix published so we switched back to other installers/deployment tools for now, at least for Windows.
There used to be other annoyances on Linux, like when on 64bit, the compact JVM copied by the development tool lacks the client native lib (it only has the server's) and thus cannot run... This has also been reported to the JIRA for a while and not fixed yet.Manually, it's very easy to fix:
cd dist/bundles/<program name>/runtime/jre/lib/adm64 ln -s ./server client