Native packaging for JavaFX

JavaFX 2.2 adds new packaging option for JavaFX applications, allowing you to package your application as a "native bundle". This gives your users a way to install and run your application without any external dependencies on a system JRE or FX SDK. I'd like to give you an overview of what it is, motivation behind it, and finally explain how to get started with it.

Screenshots may give you some idea of user experience but first hand experience is always the best. Before we go into all of the boring details, here are few different flavors of Ensemble for you to try: exe, msi, dmgrpm installers and zip of linux bundle for non-rpm aware systems. Alternatively, check out native packages for JFXtras 2.


Whats wrong with existing deployment options?

JavaFX 2 applications are easy to distribute as a standalone application or as an application deployed on the web (embedded in the web page or as link to launch application from the webpage). JavaFX packaging tools, such as ant tasks and javafxpackager utility, simplify the creation of deployment packages even further. Why add new deployment options?

JavaFX applications have implicit dependency on the availability of Java and JavaFX runtimes, and while existing deployment methods provide a means to validate the system requirements are met -- and even guide the user to perform required installation/upgrades -- they do not fully address all of the important scenarios.

In particular, here are few examples:

  • the user may not have admin permissions to install new system software
  • if the application was certified to run in the specific environment (fixed version of Java and JavaFX) then it may be hard to ensure user has this environment due to an autoupdate of the system version of Java/JavaFX (to ensure they are secure). Potentially, other apps may have a requirement for a different JRE or FX version that your app is incompatible with.
  • your distribution channel may disallow dependencies on external frameworks (e.g. Mac AppStore)

What is a "native package" for JavaFX application?

In short it is: 

  • A Wrapper for your JavaFX application that makes it into a platform-specific application bundle
  • Each Bundle is self-contained and includes:
    • your application code and resources (same set as need to launch standalone application from jar)
    • Java and JavaFX runtimes (private copies to be used by this application only)
    • native application launcher 
    • metadata (icons, etc.)
  • No separate installation is needed for Java and JavaFX runtimes
  • Can be distributed as .zip or packaged as platform-specific installer
  • No application changes, the same jar app binaries can be deployed as a native bundle, double-clickable jar, applet, or web start app

What is good about it:

  • Easy deployment of your application on fresh systems, without admin permissions when using .zip or a user-level installer
  • No-hassle compatibility.  Your application is using a private copy of Java and JavaFX. The developer (you!) controls when these are updated.
  • Easily package your application for Mac AppStore (or Windows, or...)
  • Process name of running application is named after your application (and not just java.exe) 
  • Easily deploy your application using enterprise deployment tools (e.g. deploy as MSI)
  • Support is built in into JDK 7u6 (that includes JavaFX 2.2)

Is it a silver bullet for the deployment that other deployment options will be deprecated? No.  There are no plans to deprecate other deployment options supported by JavaFX, each approach addresses different needs. Deciding whether native packaging is a best way to deploy your application depends on your requirements.

A few caveats to consider:

  • "Download and run" user experience
    Unlike web deployment, the user experience is not about "launch app from web". It is more of "download, install and run" process, and the user may need to go through additional steps to get application launched - e.g. accepting a browser security dialog or finding and launching the application installer from "downloads" folder.
  • Larger download size
    In general size of bundled application will be noticeably higher than size of unbundled app as a private copy of the JRE and JavaFX are included.  We're working to reduce the size through compression and customizable "trimming", but it will always be substantially larger than than an app that depends on a "system JRE".
  • Bundle per target platform
    Bundle formats are platform specific. Currently a native bundle can only be produced for the same system you are building on.  That is, if you want to deliver native app bundles on Windows, Linux and Mac you will have to build your project on all three platforms.
  • Application updates are the responsibility of developer
    Web deployed Java applications automatically download application updates from the web as soon as they are available. The Java Autoupdate mechanism takes care of updating the Java and JavaFX runtimes to latest secure version several times every year. There is no built in support for this in for bundled applications. It is possible to use 3rd party libraries (like Sparkle on Mac) to add autoupdate support at application level.  In a future version of JavaFX we may include built-in support for autoupdate (add yourself as watcher for RT-22211 if you are interested in this)

Getting started with native bundles

First, you need to get the latest JDK 7u6 beta build (build 14 or later is recommended). On Windows/Mac/Linux it comes with JavaFX 2.2 SDK as part of JDK installation and contains JavaFX packaging tools, including:

  • bin/javafxpackager
    Command line utility to produce JavaFX packages.
  • lib/ant-javafx.jar 
    Set of ant tasks to produce JavaFX packages (most recommended way to deploy apps)
For general information on how to use them refer to the Deploying JavaFX Application guide.

Once you know how to use these tools to package your JavaFX application for other deployment methods there are only a few minor tweaks necessary to produce native bundles:

  • make sure java is used from JDK7u6 bundle you have installed:
    • adjust your PATH settings if needed 
  • if you are using ant tasks:
    • add "nativeBundles=all" attribute to fx:deploy task
  • if you are using javafxpackager:
    • pass "-native" option to deploy command
    • or if you are using makeall command then it will try build native packages by default
  • result bundles will be in the "bundles" folder next to other deployment artifacts

Note that building some types of native packages (e.g. .exe or .msi) may require additional free 3rd party software to be installed and available on PATH.

As of JDK 7u6 build 14 you could build following types of packages:

  • Windows:
    • bundle image
    • EXE:
      • Inno Setup 5 or later is required
      • Result exe will perform user level installation (no admin permissions are required)
      • At least one shortcut will be created (menu or desktop)
      • Application will be launched at the end of install
    • MSI:
      • WiX 3.0 or later is required
      • Result MSI will perform user level installation (no admin permissions are required)
      • At least one shortcut will be created (menu or desktop)
  •  MacOS:
    • bundle image
    • dmg (drag and drop) installer
  • Linux:
    • bundle image
    • rpm
      • rpmbuild is required
      • shortcut will be added to the programs menu

If you are using Netbeans for producing the deployment packages then you will need to add custom build step to the build.xml to execute the fx:deploy task with native bundles enabled. Here is what we do for BrickBreaker sample:

    
     <target name="-post-jfx-deploy">
       <fx:deploy width="${javafx.run.width}" height="${javafx.run.height}" 
                 nativeBundles="all"
                 outdir="${basedir}/${dist.dir}" outfile="${application.title}">
          <fx:application name="${application.title}" mainClass="${javafx.main.class}"/>
          <fx:resources>
              <fx:fileset dir="${basedir}/${dist.dir}" includes="BrickBreaker.jar"/>
          </fx:resources>
          <fx:info title="${application.title}" vendor="${application.vendor}"/>
        </fx:deploy>          
     </target>
  

This is pretty much regular use of fx:deploy task, the only special thing here is nativeBundles="all".

Perhaps the easiest way to try building native bundles is to download the latest JavaFX samples bundle and build Ensemble, BrickBreaker or SwingInterop.

Please give it a try and share your experience. We need your feedback!

BTW, do not hesitate to file bugs and feature requests to JavaFX bug database!

Wait! How can i ...

This entry is not a comprehensive guide into native bundles, and we plan to post on this topic more. However, I am sure that once you play with native bundles you will have a lot of questions. We may not have all the answers, but please do not hesitate to ask! Knowing all of the questions is the first step to finding all of the answers.

Comments:

Awesome stuff guys!

Native packaging was a highly anticipated feature and it will take JavaFX to the next level, I believe.

I just tried to build a bundle image on my Linux workstation (latest Ubuntu) and it works just fine. Would be nice to get DEB packaging support as well though (in addition to RPM one). But I guess it will be added in the near future anyway.

Also very excited about built-in app-update mechanism that will hopefully be added to future JavaFX versions (btw, regarding mentioned "larger download size" point: I guess it won't be that big disadvantage if there's some kind of "delta"-based approach for app-updates).

Kudos to JavaFX dev team and keep up the good work!

Posted by Kion on June 16, 2012 at 06:57 PM PDT #

Are we going to get a Right-click on Project tab in Netbeans7.2 and be able to say create native bundle?

Posted by DJ on June 17, 2012 at 03:48 PM PDT #

What about iOS and Android?

Posted by guest on June 17, 2012 at 04:04 PM PDT #

> Would be nice to get DEB packaging support as well though (in addition to RPM one).

DEB support is being investigated. See http://javafx-jira.kenai.com/browse/RT-21606

> Are we going to get a Right-click on Project tab in Netbeans7.2 and be able to say create native bundle?

Not in 7.2 as it was too late for them but hopefully IDEs will pick it up soon.
Feel free to file feature request on IDE of your choice :)

And you can build native bundles from Netbeans but you will need to add custom ant task.

> What about iOS and Android?

I am sure that when JavaFX will officially support these platforms packaging tools will be extended to support them too.

Posted by guest on June 17, 2012 at 04:35 PM PDT #

Why is an installer mentioned? The packager tool should create a binary that can be double-clicked to start it. No installation should be required. Instead using a classical installer should be an optional step in the process. When I write a small tool for my company I want just make it available via a netdrive. My colleagues just need to double click the binary (say, an .exe file) and the tool will run.
This is exactly what they can do today, if they have Java installed and get a .jar from me. Nobody really wants to run an installer first and click through dialogs.

Please, don’t do this strong coupling. Like a clean program design with decoupled components the deployment process should be the same. Not a monolithic approach please.

Posted by guest on June 18, 2012 at 01:28 AM PDT #

Our javafx app's deployment is really the most crucial and touchy point for our start-up launching.
Bundles support is the hope a new breath for us.
Indeed, on my old home Windows XP I just can't make my 100% correct jnlp work.
From JSE 6u31, no automatic update worked, I had to manually install jre7 (horrible for end user customers).
And then with jre7u4... nothing worked properly. Simply impossible to have it working under firefox or chrome.
And I'm not talking about a school level deployment trial, it's a professionnal work by a competent java dev team.

My point :
I was wondering how we could integrate a native bundled applet, as one of our offers is applet based. Something like a one time native installation that could be reused everytime the user opens the applet page.
Has something like that ever been discussed ?

Posted by Pitt on June 18, 2012 at 01:51 AM PDT #

This packaging option is contrary to the appstore/repository approach that has always been popular in linux, including ubuntu and fedora, and which has been taken to new heights in the iphone and to some extent also the android ecosystems. It is the job of the appstore/repository administration to pick one java runtime version and then verify that all apps that list the java runtime as a dependency, properly function in the new release, while notifying upstream authors of issues as they arise. There should be as little as possible distribution from upstream directly to end users, for the technical reasons listed above, for other technical reasons, and also for well-known security reasons. Therefore, this javafx distribution method will most likely be generally rejected in the existing linux environments, in the phone and tablet environments, and even in the upcoming windows8 environment, in which the idea of direct distribution from upstream to end user is also generally rejected.

For distribution of in-house apps, the javafx packaging system proposed is also not suitable. The proper solution consists in creating an in-house appstore, staffed by competent appstore administration (internal or outsourced), while apps should list their dependencies against both the general appstore and the in-house appstore, in such a way that the existing distribution tools (apt-get, yum, and so on) can resolve and install dependencies as needed. Developers should simply not be allowed to install their new versions on end user machines without the appstore administration vetting the new release and having their say. Do we really need new virus fiestas? Also, there is a clear need for central software asset management and to keep a general overview on what exactly is being installed on end user machines.

Furthermore, installations should be automated. Who is going to click on all those unnecessary buttons that javafx is bringing along? I am surprised to see Oracle going down a completely wrong route ...

Posted by guest on June 18, 2012 at 02:12 AM PDT #

Why the lackluster Ubuntu/Debian support? You are treating rpm based distros as first class citizens, but Ubuntu is far more popular than all of those combined, particularly on the desktop where this is most useful.

Posted by Carl Z on June 18, 2012 at 04:51 AM PDT #

This is great news. I was concerned that packaging will be the biggest issue with JavaFX, but your solution looks great. Good job!

Posted by guest on June 18, 2012 at 06:06 AM PDT #

Wow! So Oracle (Sun) finally did what should have been done in the 90s! Kudos to being only 20 years behind in the absolute minimum basics for desktop adoption!

Posted by guest on June 18, 2012 at 07:09 PM PDT #

> Why is an installer mentioned? The packager tool should create a binary that can be double-clicked to start it. No installation should be required. Instead using a classical installer should be an optional step in the process. When I write a small tool for my company I want just make it available via a netdrive. My colleagues just need to double click the binary (say, an .exe file) and the tool will run. This is exactly what they can do today, if they have Java installed and get a .jar from me. Nobody really wants to run an installer first and click through dialogs.

Support for doubleclickable jar files is not going away. Bundled applications is new option for deployment, not a replacement for existing deployment methods.

Moreover, one type of bundle is image of bundled application. This is folder containing .exe launcher + application resources (e.g. jars) and jre. It can be launched by clicking on .exe file and can be moved around as a folder.

Installers are generated for convenience as many users prefer to distribute applications in this way.

> Indeed, on my old home Windows XP I just can't make my 100% correct jnlp work.

I am sorry to hear about issues you have. Please make sure they are reported to javafx-jira.kenai.com
Detailed reports and testcases are most useful (see http://docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-Desktop/html/plugin.html for ideas what details can be collected)

Posted by Igor on June 18, 2012 at 09:46 PM PDT #

> Why the lackluster Ubuntu/Debian support? You are treating rpm based distros as first class citizens, but Ubuntu is far more popular than all of those combined, particularly on the desktop where this is most useful.

.deb support is planned, simply unfinished. See http://javafx-jira.kenai.com/browse/RT-21606

> This packaging option is contrary to the appstore/repository approach that has always been popular in linux, including ubuntu and fedora, and which has been taken to new heights in the iphone and to some extent also the android ecosystems.

IMHO, it really depends on application. There is no security problem if older version of library is private to application. Security hole is bigger if older system wide JRE is installed because on of apps needs that old version.

This is solution for those developers who needs complete package they have full control of.
Some platforms (e.g. Mac OS App Store) actually only support this mode, use of system frameworks is disallowed.

This is *not* the only deployment options available. If this one is not the right option for you then pick another that works best for your project.

> Furthermore, installations should be automated. Who is going to click on all those unnecessary buttons that javafx is bringing along?

Clearly it is possible to install msi, dmg and rpm/deb in the automated way. Once autoupdate support is added it will be optional and may be integrated with platform update mechanisms (e.g. on linux) where it is feasible.

Posted by Igor on June 18, 2012 at 09:57 PM PDT #

> It is the job of the appstore/repository administration to pick one
> java runtime version and then verify that all apps that list the java
> runtime as a dependency, properly function in the new release, while
> notifying upstream authors of issues as they arise.

They explicitly wrote:
“There are no plans to deprecate other deployment options supported by JavaFX, each approach addresses different needs. Deciding whether native packaging is a best way to deploy your application depends on your requirements.”

So, a developer can specify the exact JVM version, and the exact JFX version he wants. Then on the corresponding Linux multiple JVM and JFX versions will be installed, and each program will run in the one it specified.

If your Linux distro supports only a single installation of Java, then the distro is broken. In principle hundreds of installations could exist on a single machine.

But on the iPhone this is not allowed. An app must run on its own. It would be great though if Oracle could politically convince Apple to have many JVMs installed, on which an App can then depend. But if that is not going to happen, then this packaging mechanism is about letting JFX apps run on iOS.

> There should be as little as possible distribution from upstream
> directly to end users, for the technical reasons listed above,

I totally agree. If the system worked perfectly, then there would be a single java binary, which is a tiny loader and Maven-like system. Each .jar would specify in its manifest file what dependencies it have, and the java starter would check if this dep has already been downloaded. If not, it will download it first, and then run it. This *could* end up with the end user having 29 JVMs on her system, but this is fine. The local cache (i.e. .m2 folder) can be cleared manually from time to time.
In such a perfect world all OSes would allow such a behaviour, including iOS.
If an OS already has a useful package system, where the user can specify the dependency and its exact version number, then the java loader binary can outsource the dependency management to the OS.

> Therefore, this javafx distribution method will most likely be
> generally rejected in the existing linux environments,

This doesn’t matter. One would use other deployment mechanisms.
But as I said, if an OS (Lin, Win, osx) does not allow multiple installations of the same software in different versions, then the OS is broken. A user may wish to run the programs A and B, where A depends on Java 7 Update 2 with JFX 2.1 and B depends on Java 7 Update 11 with JFX 2.4. Obviously the user needs both JVMs and both JFXes on her system. The OS concept of „installing” a single version of a software is outdated. It simply is too 90ies. There needs to be a cache for versions. If a version is not present, then download it. If it is present, use that one.

Posted by guest4278 on June 19, 2012 at 02:12 AM PDT #

Hi Igor, thanks for your reply.

>> Why is an installer mentioned? The packager tool should create a
>> binary that can be double-clicked to start it.

> Support for doubleclickable jar files is not going away. Bundled
> applications is new option for deployment, not a replacement for
> existing deployment methods.

Yes, I understood that part. The double click on the jars will still be available. What I propose here is that this should be the same for the produced binary, say, “myApp.exe”.
I don’t need an installer for my überjar. I should not need one for my überbinary, which includes it all.

> Moreover, one type of bundle is image of bundled application. This is
> folder containing .exe launcher + application resources (e.g. jars)
> and jre. It can be launched by clicking on .exe file and can be moved
> around as a folder.

Okay, that is good then. All I was proposing was having such an option.
Small tools in company environments, or even private ones that I use at home surely don’t require an installer. It is about the ease of sharing a useful tool.
I can not tell my boss that I have this cool new tool which will download him nice reports directly from the DB, but he just has to go through the 18 screens of an installer. I just want to place it on the netdrive where he double clicks it, and all is done.
The biggest competitor for JFX, HTML5, works so easy. I just present an URL and it works. If I want to use JFX in my company, it requires a similar approach.

> Installers are generated for convenience as many users prefer to
> distribute applications in this way.

As an optional step this is of course okay. Depending on what I want to do, and who my target group is, this is fine. I just should have the choice if I want an installer or not. It should not be forced on us.

Posted by guest427 on June 19, 2012 at 02:24 AM PDT #

It's funny that you mention
> No-hassle compatibility. Your application is using a private copy of Java and JavaFX.
Yet everyone of the examples in the Ensemble app fails with:

19/06/2012 21:12:35 [0x0-0x9a59a5].javafx.ensemble.Ensemble2[14467] Caused by: java.lang.NoSuchMethodError: javafx.scene.web.WebView.setContextMenuEnabled(Z)V
19/06/2012 21:12:35 [0x0-0x9a59a5].javafx.ensemble.Ensemble2[14467] at ensemble.pages.SamplePage.getWebView(SamplePage.java:400)

...

Posted by guest on June 19, 2012 at 01:16 PM PDT #

Hi,
Thanks for the answer. I'll try to reproduce those bugs, but my environment changed many times since then.

I understand that if all users had a recent jvm installed and webstart worked perfectly there would be no need for that (mainly talking about windows/mac there). But even if webstart works 99% good, not all users have a recent enough jvm to support the auto-download of the required jvm. And having to manually install the JRE is really a pain as it looks for them like some other software that has nothing to see with our app.
So allow me to insist on the core of my point :

> I was wondering how we could integrate a native bundled applet, as one of our offers is applet based. Something like a one time native installation that could be reused everytime the user opens the applet page.
> Has something like that ever been discussed ?

Posted by Pitt on June 20, 2012 at 02:27 AM PDT #

While I appreciate any efforts in the desktop space and deployment aspects in particular, I would really highlight the potential of Java WebStart. If more resources would be dedicated to take it to a higher level, I'd be glad. Ideally, please start with fixing those nasty bugs like http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6957028 .
Especially, if you want to support and promote complex JavaFX apps with a lot of additional dependencies this is indispensable.
Please share this info with the Java WebStart team...

Thanks for your efforts!

Posted by guest on June 20, 2012 at 12:06 PM PDT #

OK nice feature, but what about licensing? I understand OpenJDK is basically GNU and Oracle currently doesn't allow redistribution of its JRE if I'm correct. Is there a way do distribute a closed-source commercial program this way?

Posted by guest on June 21, 2012 at 08:08 AM PDT #

Hi,

I tried to make a native bundle of our fx2 application Mac OS X 10.7.4 (11E53).

I used the ant tools provided in jdk1.7.0_06.

Creation of .app and .dmg are fine.

But the application doesn't start, I have the following error :

Process: FX2Launcher [9926]
Path: /Applications/FX2Launcher.app/Contents/MacOS/JavaAppLauncher
Identifier: javafx.xxxx.xxxx.main.FX2Launcher
Version: 1.0 (1)
Code Type: X86-64 (Native)
Parent Process: launchd [220]

FX2Launcher is the name of our main class.

Exception Type: EXC_BAD_ACCESS (SIGABRT)
Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000008

VM Regions Near 0x8:
-->
__TEXT 0000000100000000-0000000100002000 [ 8K] r-x/rwx SM=COW /Applications/FX2Launcher.app/Contents/MacOS/JavaAppLauncher

Application Specific Information:
objc[9926]: garbage collection is OFF
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** -[NSURL initFileURLWithPath:]: nil string parameter'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff907ebf56 __exceptionPreprocess + 198
1 libobjc.A.dylib 0x00007fff8e48bd5e objc_exception_throw + 43
2 CoreFoundation 0x00007fff907ebd8a +[NSException raise:format:arguments:] + 106
3 CoreFoundation 0x00007fff907ebd14 +[NSException raise:format:] + 116
4 Foundation 0x00007fff8c03ee40 -[NSURL(NSURL) initFileURLWithPath:] + 78
5 Foundation 0x00007fff8c03edd9 +[NSURL(NSURL) fileURLWithPath:] + 47
6 libglass.dylib 0x000000010eb02513 Java_com_sun_glass_ui_mac_MacWindow__1setIcon + 611
7 ??? 0x0000000104811f90 0x0 + 4370538384
8 ??? 0x0000000104806158 0x0 + 4370489688
9 ??? 0x0000000104806158 0x0 + 4370489688
10 ??? 0x0000000104806806 0x0 + 4370491398
)

terminate called throwing an exception
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff90b90ce2 __pthread_kill + 10
1 libsystem_c.dylib 0x00007fff89b207d2 pthread_kill + 95
2 libsystem_c.dylib 0x00007fff89b11a7a abort + 143
3 libc++abi.dylib 0x00007fff89c307bc abort_message + 214
4 libc++abi.dylib 0x00007fff89c2dfcf default_terminate() + 28
5 libobjc.A.dylib 0x00007fff8e48c1b9 _objc_terminate + 94
6 libc++abi.dylib 0x00007fff89c2e001 safe_handler_caller(void (*)()) + 11
7 libc++abi.dylib 0x00007fff89c2e05c std::terminate() + 16
8 libc++abi.dylib 0x00007fff89c2f152 __cxa_throw + 114
9 libobjc.A.dylib 0x00007fff8e48be7a objc_exception_throw + 327
10 com.apple.CoreFoundation 0x00007fff907ebd8a +[NSException raise:format:arguments:] + 106
11 com.apple.CoreFoundation 0x00007fff907ebd14 +[NSException raise:format:] + 116
12 com.apple.Foundation 0x00007fff8c03ee40 -[NSURL(NSURL) initFileURLWithPath:] + 78
13 com.apple.Foundation 0x00007fff8c03edd9 +[NSURL(NSURL) fileURLWithPath:] + 47
14 libglass.dylib 0x000000010eb02513 Java_com_sun_glass_ui_mac_MacWindow__1setIcon + 611
15 ??? 0x0000000104811f90 0 + 4370538384
16 ??? 0x0000000104806158 0 + 4370489688
17 ??? 0x0000000104806158 0 + 4370489688
18 ??? 0x0000000104806806 0 + 4370491398
19 ??? 0x0000000104806158 0 + 4370489688
20 ??? 0x0000000104806158 0 + 4370489688
21 ??? 0x0000000104806158 0 + 4370489688
22 ??? 0x0000000104806158 0 + 4370489688
23 ??? 0x0000000104806158 0 + 4370489688
24 ??? 0x0000000104806158 0 + 4370489688
25 ??? 0x0000000104806158 0 + 4370489688
26 ??? 0x0000000104806158 0 + 4370489688
27 ??? 0x0000000104806806 0 + 4370491398
28 ??? 0x0000000104806806 0 + 4370491398
29 ??? 0x0000000104806806 0 + 4370491398
30 ??? 0x00000001048004f7 0 + 4370466039
31 libjvm.dylib 0x0000000103286eb3 JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*) + 557
32 libjvm.dylib 0x0000000103286c80 JavaCalls::call(JavaValue*, methodHandle, JavaCallArguments*, Thread*) + 40
33 libjvm.dylib 0x00000001032a2727 _ZL20jni_invoke_nonstaticP7JNIEnv_P9JavaValueP8_jobject11JNICallTypeP10_jmethodIDP18JNI_ArgumentPusherP6Thread + 677
34 libjvm.dylib 0x000000010329648f jni_CallVoidMethod + 278
35 libglass.dylib 0x000000010eadfc09 -[GlassRunnable run] + 121
36 com.apple.CoreFoundation 0x00007fff907db70d -[NSObject performSelector:withObject:] + 61
37 com.apple.Foundation 0x00007fff8c069d70 __NSThreadPerformPerform + 214
38 com.apple.CoreFoundation 0x00007fff9075a4f1 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
39 com.apple.CoreFoundation 0x00007fff90759d5d __CFRunLoopDoSources0 + 253
40 com.apple.CoreFoundation 0x00007fff90780b49 __CFRunLoopRun + 905
41 com.apple.CoreFoundation 0x00007fff90780486 CFRunLoopRunSpecific + 230
42 com.apple.HIToolbox 0x00007fff9507d4d3 RunCurrentEventLoopInMode + 277
43 com.apple.HIToolbox 0x00007fff950846d3 ReceiveNextEventCommon + 181
44 com.apple.HIToolbox 0x00007fff9508460e BlockUntilNextEventMatchingListInMode + 62
45 com.apple.AppKit 0x000000010000ce31 _DPSNextEvent + 659
46 com.apple.AppKit 0x000000010000c735 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135
47 com.apple.AppKit 0x0000000100009071 -[NSApplication run] + 470
48 libglass.dylib 0x000000010eae06f7 -[GlassApplication runLoop:] + 1287
49 com.apple.CoreFoundation 0x00007fff907db70d -[NSObject performSelector:withObject:] + 61
50 com.apple.Foundation 0x00007fff8c069d70 __NSThreadPerformPerform + 214
51 com.apple.CoreFoundation 0x00007fff9075a4f1 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
52 com.apple.CoreFoundation 0x00007fff90759d5d __CFRunLoopDoSources0 + 253
53 com.apple.CoreFoundation 0x00007fff90780b49 __CFRunLoopRun + 905
54 com.apple.CoreFoundation 0x00007fff90780486 CFRunLoopRunSpecific + 230
55 com.oracle.java.7u06.jdk 0x0000000101ae091c CreateExecutionEnvironment + 871
56 com.oracle.java.7u06.jdk 0x0000000101adb10c JLI_Launch + 1952
57 javafx.xxxx.xxxx.main.FX2Launcher 0x0000000100001a33 launch + 2572
58 javafx.xxxx.xxxx.main.FX2Launcher 0x0000000100000f94 main + 76
59 javafx.xxxx.xxxx.main.FX2Launcher 0x0000000100000f40 start + 52

Do you know the root cause of that error ? Is it comes from the ant tool or from our application ?

Thanks,

BR

Posted by guest on June 22, 2012 at 12:52 AM PDT #

The license for JavaFX the BCL for Java SE: http://www.oracle.com/technetwork/java/javase/terms/license/index.html Refer to clause C. The main gist is "Oracle grants you a non-exclusive, non-transferable, limited license without fees to reproduce and distribute the Software, provided that (i) you distribute the Software complete and unmodified and only bundled as part of, and for the sole purpose of running, your Programs". There are other clauses which you can read in the license, none of which appear overly onerous. My reading is that this native packaging approach for bundling JavaFX + JRE + app is perfectly acceptable method for distributing a "closed-source commercial program".

Posted by jewelsea on June 22, 2012 at 01:01 PM PDT #

Thanks a lot for bug reports. It helps us to improve quality of the platform before the release.
Please keep reporting them to http://javafx-jira.kenai.com (use Packaging or Deployment as component if you file bug on native bundlers).

> Re: Webstart bugs

We are not abandoning webstart and fixing many bugs there.
It is hard to track externally as JDK7 builds do not include list of fixed in the closed source but every single build of Java 7 typically has 10-20 deployment bugs fixed.

6957028 specifically is marked as Incomplete in our internal bug database (do not know why status is not updated on bugs.sun.com) because we are unable to reproduce it in house (and suspect it may have been resolved by other fixes in the core JRE). If you still can reproduce it with recent Java 7 builds - please add comments to CR on bugs.sun.com

OpenJDK will be migrating to JIRA in next few months and then it should be easier for external folks to report problems and track status. Please do not hesitate to file bugs and provide more info on existing bug reports. We trying to keep an eye on developer feedback and focus on important issues.

> OK nice feature, but what about licensing?

Rules for redistribution of JRE are defined here:

http://www.oracle.com/technetwork/java/javase/jre-7-readme-430162.html

JavaFX is part of JRE and subject to the same rules.

> Re: FX2Launcher crash

It is hard to tell for sure but my guess is that you are adding custom icons to the stage?
Looks like icon path is invalid and this cause JavaFX to crash.

This is surely bug in JavaFX that must not crash on invalid data. Please report it to JIRA.

To validate it is not native launcher related run your application from command line as
cd /Applications/FX2Launcher.app/Contents
./PlugIns/jdk1.7.0_06.jdk/Contents/Home/bin/java -jar Java/*.jar

> I understand that if all users had a recent jvm installed and webstart worked perfectly there would be no need for that (mainly talking about windows/mac there).

Actually this is not true. There different use cases and for some of them webstart does not suit well.
E.g. offline redistribution or Mac App Store. Also, some application do not need or want recent JRE, they may want ancient JRE.

> I was wondering how we could integrate a native bundled applet, as one of our offers is applet based.
> Something like a one time native installation that could be reused everytime the user opens the applet page. Has something like that ever been discussed ?

We are looking into different ideas how to improve things. For example, one of them is to allow to cobundle private JRE with an applet. This will make download size larger but will allow to reduce number of possible compatibility problems and there will be no separate installation for JRE.

This does not ensure compatibility of deploy APIs as they have to be coming from installed JRE
(only one plugin can be registered in the browser and browser side should share protocol/cache/etc with
deployment stack used in the applet process).

It is just an idea for now.

Posted by Igor on June 23, 2012 at 02:03 PM PDT #

Re: FX2Launcher crash

Thank you for your answer.

The same build worked for linux and windows so I think it would not be caused by a wrong ressources path.

I tried your command and I get the following error :

FX2Launcher.app/Contents/PlugIns/jdk1.7.0_06.jdk/Contents/Home/bin/java -jar Java/*.jar
-bash: ./PlugIns/jdk1.7.0_06.jdk/Contents/Home/bin/java: No such file or directory

Is it normal I don't have bin/java in /PlugIns/jdk1.7.0_06.jdk/Contents/Home/ ?

BR,

Posted by guest on June 24, 2012 at 01:22 AM PDT #

Great Stuff!

with this new feature I was able to build an installer package for mac. Small modifications on my side were necessary to get it work:
- the shown code-snippet for the build.xml had to be modified
- I had to create a softlink to /usr/bin/SetFile

Here are the details:
snippet for build.xml:

<target name="-post-jfx-deploy">
<fx:deploy width="${javafx.run.width}" height="${javafx.run.height}"
nativeBundles="all"
outdir="${basedir}/${dist.dir}" outfile="${application.title}">
<fx:resources>
<fx:fileset dir="${basedir}/${dist.dir}"
includes="*.jar"
excludes="**/web-files/*,*.jnlp,*.html,**/bundles/*"
/>
<fx:fileset dir="${basedir}/${dist.dir}/lib"
includes="*.jar"/>
</fx:resources>
<info title="${application.title}" vendor="${application.vendor}"/>
<fx:application name="${application.title}" mainClass="${javafx.main.class}"/>
</fx:deploy>
</target>
---
The second fileset includes necessary lib files (in my case derby and eclipselink). The info and the resources tag are not possible in the fx-application tag.

Additionaly I made the dir /Developer/Tools
then:
cd /Developer/Tools
ln -s /usr/bin/SetFile .

After that ti worked great and I love this feature.

Thanks for the possibility and thanks for this blog!

Posted by guest on June 24, 2012 at 10:02 AM PDT #

> Small modifications on my side were necessary to get it work:
> - the shown code-snippet for the build.xml had to be modified
> - I had to create a softlink to /usr/bin/SetFile

Thanks a lot for reporting problems.
I've update code snippet in blog and will fix SetFile location detection issue.

> The same build worked for linux and windows so I think it would not be caused by a wrong ressources path.

IMHO, there could be differences in supported formats, bugs in JDK, etc.
Are you setting icons? Will it still crash if you temporarily comment that part of code?

If you can craft small test to reproduce the problem and submit issue to JIRA this will be very helpful.

> I tried your command and I get the following error :
> FX2Launcher.app/Contents/PlugIns/jdk1.7.0_06.jdk/Contents/Home/bin/java -jar Java/*.jar
> -bash: ./PlugIns/jdk1.7.0_06.jdk/Contents/Home/bin/java: No such file or directory
> Is it normal I don't have bin/java in /PlugIns/jdk1.7.0_06.jdk/Contents/Home/ ?

ok, my bad.
forgot that java launcher is missing in the bundled runtime on Mac.

Simply run you application using java from jdk7u6 you used for cobundling it.
Can you reproduce same problem? Goal here is understand whether native launcher is related to the crash or not.

Posted by Igor on June 24, 2012 at 01:46 PM PDT #

Re: FX2Launcher crash

Thanks for your answer.

1- If I launch the application using java from jdk7u6 I used for cobundling I have exactly the same exception. So native launcher is not in cause.

2- If I comment : stage.getIcons().add(loadImage("icon.png"));
it works !

loadImage do the following :

private Image loadImage(String path){
Image image = new Image(
ResourceLoader.class.getResourceAsStream(path));
return image;
}

and ResourceLoader is an empty class.

This mecanism works perfectly for others images in the application, so my guess is the bug is around stage.getIcons().add() !

I will submit issue to JIRA.

Cheers

Posted by guest on June 25, 2012 at 12:47 AM PDT #

Google Chrome is attempting a 'tight integration' of desktop apps with their web-browser using the technology NaCL. (successor to Netscape's NPAPI ). This enables a native-app to run in the browser's frame. (check out the examples). This is really powerfull.

Java's applet/jnlp examples do demonstrate a similar power. (DynamicTree demo). I hope that the natively packaged javafx bundles can also be similarily executed within a browser's process. I guess this would be via applet/native-bundle combination.

A non-trivial example should be demonstrated by Oracle.

Posted by guest on June 27, 2012 at 04:19 AM PDT #

Re: webstart bugs
Thanks Igor for responding.

Hm, is bug commenting disabled on bugs.sun.com or do I need a special login?
At least with my current OTN account I'm not able to comment...

I wanted to add the following comment to
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6957028 :
We first noticed this bug with version 1.6.0_18. 1.6.0_17 was the last release that doesn't show this bug. The current version 1.6.0_33 still exhibits this bug.
I think the best chance to reproduce this bug is to try it with a complex real-world app, but I don't know if you have such an webstart-enabled app at Oracle.
Here are some characteristics of our app:
We have more than 60 third-party JARS in our JNLP file referenced (Spring, Apache Commons, Hibernate, JIDE ...). These are not downloaded with JarDiff, e.g. they have no version attribute in the JNLP. Only our 10+ self-made JARS are versioned, e.g. JarDiff-enabled.
Every time we release a new version, we observe bug 6957028 with JRE versions > 1.6.0_17. Most of our customers use Windows XP/Vista/7. For example, I observe the bug with Windows 7 64-bit and Firefox 13 32-bit with JDK 1.6.0_33 64-bit and 32-bit installed.

Posted by guest on July 02, 2012 at 03:42 AM PDT #

> I wanted to add the following comment to
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6957028

Added your comment to the CR.
I am not sure about bugs.sun.com, i expect it to be operation but may be already read only due to migration to JIRA ... Hopefully it will be much easier to provide additional details soon.

Posted by Igor on July 02, 2012 at 11:43 AM PDT #

I suggest:The minimum JRE size, binding characteristics of the operating system

Posted by guest on July 18, 2012 at 08:19 PM PDT #

Any way to do the same for Jars containing Java Swing applications ?

Posted by guest on July 31, 2012 at 12:46 AM PDT #

Creating native executables does not work for me. Tried to adapt the build.xml file from the BrickBreaker sample. This message is shown:

Using base JDK at: C:\Program Files\Java\jdk1.7.0_06\jre
Skip [Windows Application Bundler] due to [Main application jar is missing.]
Skip [MSI Bundler (WiX based)] due to [Main application jar is missing.]
Skip [Exe Bundler (based on Inno Setup)] due to [Main application jar is missing.]

My Application is a single jar defined at <fx:resources>. Why the fxpackager does not find the "Main application jar"?

Posted by guest on August 06, 2012 at 08:32 AM PDT #

hi,

add extra libs does not work to me. I add the location of the jar

<fx:fileset dir="${basedir}/${dist.dir}/lib" includes="*.jar"/>

and they are copied to the app folder, but I it look like they are not
loaded...
Any ideas...?Thanks

Posted by guest on August 13, 2012 at 11:00 AM PDT #

Hi

I am using the new "native packaging" feature of JavaFX 2.2 Developer preview (Build 19). I can build successfully an installer (.exe). However, once I started the JavaFX application that was deployed using that installer, I get an exception (SunTlsRsaPremasterSecret KeyGenerator not available) for every HTTPS-request I do. This exception does not occure, when I start the same application via eclipse or command line.

I assume this is a bug of the developer preview.

I posted a detailed description here:

http://stackoverflow.com/questions/11960195/javafx-native-packaging-https-request-throws-suntlsrsapremastersecret-keygener

Posted by guest on August 14, 2012 at 01:33 PM PDT #

Very exciting stuff. Thanks!

Posted by guest on August 30, 2012 at 07:01 AM PDT #

We created a native bundle for MacOS.
After installation, the application starts but after few seconds, it crashes with the following error :

Process: xxx [1035]
Path: /Applications/xxx.app/Contents/MacOS/JavaAppLauncher
Identifier: name
Version: 1.0.0 (100)
Code Type: X86-64 (Native)
Parent Process: launchd [151]

Date/Time: 2012-09-10 14:24:50.003 +0200
OS Version: Mac OS X 10.7.4 (11E53)
Report Version: 9

Interval Since Last Report: 1034441 sec
Crashes Since Last Report: 40
Per-App Interval Since Last Report: 217 sec
Per-App Crashes Since Last Report: 6
Anonymous UUID: 73F50529-D100-4E19-8DBC-82A365692277

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_BAD_ACCESS (SIGABRT)
Exception Codes: 0x000000000000000d, 0x0000000000000000

VM Regions Near 0:
-->
__TEXT 0000000100000000-0000000100002000 [ 8K] r-x/rwx SM=COW /Applications/xxx.app/Contents/MacOS/JavaAppLauncher

Application Specific Information:
objc[1035]: garbage collection is OFF
abort() called

hread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x00007fff92491ce2 __pthread_kill + 10
1 libsystem_c.dylib 0x00007fff8ae447d2 pthread_kill + 95
2 libsystem_c.dylib 0x00007fff8ae35a7a abort + 143
3 libjvm.dylib 0x00000001013b5073 os::abort(bool) + 25
4 libjvm.dylib 0x00000001014a382e VMError::report_and_die() + 2306
5 libjvm.dylib 0x00000001013b6767 JVM_handle_bsd_signal + 1073
6 libsystem_c.dylib 0x00007fff8ae96cfa _sigtramp + 26
7 libobjc.A.dylib 0x00007fff8b5e0e90 objc_msgSend + 16
8 libglass.dylib 0x000000010d1c5648 -[GlassTouches(hidden) sendJavaTouchEvent:] + 1064
9 libglass.dylib 0x000000010d1c4e54 listenTouchEvents + 68
10 com.apple.CoreGraphics 0x00007fff89a09077 processEventTapData + 734
11 com.apple.CoreGraphics 0x00007fff89a09302 _CGXPostEventTapDataOOL + 221
12 com.apple.CoreGraphics 0x00007fff89ae187a _XPostEventTapDataOOL + 251
13 com.apple.CoreGraphics 0x00007fff89ae1646 CGXEventTap_server + 146
14 com.apple.CoreGraphics 0x00007fff89a08a12 eventTapMessageHandler + 30
15 com.apple.CoreFoundation 0x00007fff92eb3c52 __CFMachPortPerform + 386
16 com.apple.CoreFoundation 0x00007fff92eb3abc __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 44
17 com.apple.CoreFoundation 0x00007fff92eb37eb __CFRunLoopDoSource1 + 155
18 com.apple.CoreFoundation 0x00007fff92ee9f27 __CFRunLoopRun + 1895
19 com.apple.CoreFoundation 0x00007fff92ee9486 CFRunLoopRunSpecific + 230
20 com.apple.HIToolbox 0x00007fff8e1b74d3 RunCurrentEventLoopInMode + 277
21 com.apple.HIToolbox 0x00007fff8e1be781 ReceiveNextEventCommon + 355
22 com.apple.HIToolbox 0x00007fff8e1be60e BlockUntilNextEventMatchingListInMode + 62
23 com.apple.AppKit 0x00007fff8a085e31 _DPSNextEvent + 659
24 com.apple.AppKit 0x00007fff8a085735 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 135
25 com.apple.AppKit 0x00007fff8a082071 -[NSApplication run] + 470
26 libglass.dylib 0x000000010d1b2186 -[GlassApplication runLoop:] + 838
27 com.apple.CoreFoundation 0x00007fff92f4470d -[NSObject performSelector:withObject:] + 61
28 com.apple.Foundation 0x00007fff8f99cd70 __NSThreadPerformPerform + 214
29 com.apple.CoreFoundation 0x00007fff92ec34f1 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
30 com.apple.CoreFoundation 0x00007fff92ec2d5d __CFRunLoopDoSources0 + 253
31 com.apple.CoreFoundation 0x00007fff92ee9b49 __CFRunLoopRun + 905
32 com.apple.CoreFoundation 0x00007fff92ee9486 CFRunLoopRunSpecific + 230
33 libjli.dylib 0x000000010003c91c CreateExecutionEnvironment + 871
34 libjli.dylib 0x000000010003710c JLI_Launch + 1952
35 name 0x0000000100001a91 launch + 2178
36 name 0x000000010000117c main + 76
37 name 0x0000000100001128 start + 52

Posted by valpok on September 10, 2012 at 05:58 AM PDT #

There is a way to receive an command line parameter on javafx? I create the .exe file and im calling the program like 'program.exe parameter' and im not receiving the parameter on getParameters().getUnnamed().get(0) !!!!

Posted by Fuinha on September 14, 2012 at 11:26 AM PDT #

How can i receive an .exe parameter? I created my javafx app and I need to receive an argument like 'myapp.exe testeparameter', but when i call getParameters().getUnnamed().get(0) nothing is returned. When i call my app using java -jar then it works. Any ideas?

Posted by Fuinha on September 14, 2012 at 11:54 AM PDT #

Re: We created a native bundle for MacOS....

This is a bug in JavaFX and not related to signing/bundling your app. See http://javafx-jira.kenai.com/browse/RT-24864

Posted by Scott K. on September 18, 2012 at 09:46 AM PDT #

Using SwingInterop example,
on Windows Server 2003 (64bit) I got the error:
[fx:deploy] Exception: java.io.IOException: Exec failed with code 128 command [[C:\DOCUME~1\bkozel\LOCALS~1\Temp\2\iconswap3948943569049376081.exe, C:\DOCUME~1\bkozel\LOCALS~1\Temp\2\build5402054198487250493.fxbundler\windows\SwingInterop.ico, C:\EclipseBK\workspace\@TestPackakging-fx\dist\bundles\SwingInterop\SwingInterop.exe] in unspecified directory

Please help

Posted by guest on September 20, 2012 at 12:09 AM PDT #

> Using SwingInterop example, on Windows Server 2003 (64bit) I got the error:

This is http://javafx-jira.kenai.com/browse/RT-24960
Copy mscv100.dll from jre folder to windows system directory or use latest 7u10 build from jdk7.java.net

> How can i receive an .exe parameter?

This was unsupported in the 7u6. We recently added this to JavaFX 2.2.4/7u10.
Should be in this week build. See http://javafx-jira.kenai.com/browse/RT-24993

> add extra libs does not work to me. I add the location of the jar
> <fx:fileset dir="${basedir}/${dist.dir}/lib" includes="*.jar"/>

Sorry, it was bug in the post/docs. Now example is corrected. It should be
<fx:fileset dir="${basedir}/${dist.dir}" includes="lib/*.jar"/>

> Any way to do the same for Jars containing Java Swing applications ?

Yes, at least 2 options:
1. Use same approach as for JavaFX/Swing apps (https://blogs.oracle.com/talkingjavadeployment/entry/packaging_swing_apps_with_integrated)
- repackage swing jar using fx:jar to embed JavaFX launcher
- Use fx:deploy to produce a bundle

2. Try 7u10 beta builds (jdk7.java.net) where support for non-JavaFX apps was improved.
See http://javafx-jira.kenai.com/browse/RT-24881

> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6957028

This should be resolved now. Please try latest 7u10 beta build (backport to 6u is considered).
Sorry that it took so long. Please keep providing us feedback and we will try to improve.

> However, once I started the JavaFX application that was deployed using that installer, I get an exception (SunTlsRsaPremasterSecret KeyGenerator not available) for every HTTPS-request I do. This exception does not occure, when I start the same application via eclipse or command line.

One of the jars is missing in the ext folder. This jar is now included by default in 7u10/2.2.4.
You can also add script to copy content of ext folder to your package if you want to do it with 7u6.

Posted by Igor on September 21, 2012 at 08:06 PM PDT #

Hii all,

i created a java application and converted into .app,and it works fine. now i want to make this app to be launched automatically whenever the system is restarted. please suggest me how to proceed to bring this feature.

Thanks in advance

Posted by Raj on September 25, 2012 at 10:00 AM PDT #

> i created a java application and converted into .app,and it works fine. now i want to make this app to be launched automatically whenever the system is restarted. please suggest me how to proceed to bring this feature.

I do not think this has any specifics for Java apps. Process is the same as for any other Mac application. Google for "launch application at login on Mac" and you will see many step by step instructions.

Posted by Igor on September 25, 2012 at 02:03 PM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

JoeM

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today