Last weeks were very busy here in Oracle. JavaOne 2012 is next week. Come to see us there!
Meanwhile i'd like to quickly update you on recent developments in the area of packaging tools. This is an area of ongoing development for the team, and we are continuing to refine and improve both the tools and the process. Thanks to everyone who shared experiences and suggestions with us. We are listening and fixed many of reported issues. Please keep them coming as comments on the blog or (even better) file issues directly to the JIRA.
In this post i'll focus on several new packaging features added in JDK 7 update 10:
Self-Contained Applications: Select Java Runtime to bundle
Self-Contained Applications: Create Package without Java Runtime
Self-Contained Applications: Package non-JavaFX application
Option to
disable proxy setup in the JavaFX launcher
Ability to specify codebase for WebStart application
Option to update existing jar file
Self-Contained Applications: Specify application icon
Self-Contained Applications: Pass parameters on the command line
All these features and number of other important bug fixes are available in the developer preview builds of JDK 7 update 10 (build 8 or later). Please give them a try and share your feedback!
Self-Contained Applications: Select Java Runtime to bundle
Packager tools in 7u6 assume current JDK (based on java.home property) is the source for embedded runtime. This is useful simplification for many scenarios but there are cases where ability to specify what to embed explicitly is handy. For example IDE may be using fixed JDK to build the project and this is
not the version you want to bundle into your application.
To make it more flexible we now allow to specify location of base JDK
explicitly. It is optional and if you do not specify it then current JDK will be used (i.e. this change is fully backward compatible).
New 'basedir' attribute was added to <fx:platform> tag. Its value
is location of JDK to be used. It is ok to point to either JRE inside
the JDK or JDK top level folder. However, it must be JDK and not JRE as we need
other JDK tools for proper packaging and it must be recent version of
JDK that is bundled with JavaFX (i.e. Java 7 update 6 or later).
Here are examples (<fx:platform> is part of <fx:deploy> task):
<fx:platform basedir="${java.home}"/>
<fx:platform basedir="c:\tools\jdk7"/>
Hint: this feature enables you to use packaging tools from JDK 7 update
10 (and benefit from bug fixes and other features described below) to create application package with bundled FCS version of JRE 7 update 6.
Self-Contained Applications: Create Package without Java Runtime
This may sound a bit puzzling at first glance. Package without embedded Java Runtime is not really self-contained and obviously will not help with:
Deployment on fresh systems. JRE need to be installed separately (and this step will require admin permissions).
Possible compatibility issues due to updates of system runtime.
However, these packages are much much smaller in size. If download size
matters and you are confident that user have recommended system JRE
installed then this may be good option to consider if you want to improve user experience for install and launch.
Technically, this is implemented as an extension of previous feature.
Pass empty string as value for 'basedir' attribute and this will be
treated as request to not bundle Java runtime, e.g.
<fx:platform basedir=""/>
Self-Contained Applications: Package non-JavaFX application
One of popular questions people ask about self-contained applications -
can i package my Java application as self-contained application? Absolutely.
This is true even for tools shipped with JDK 7 update 6. Simply follow steps for creating
package for Swing application with integrated JavaFX content and they will work even if your application does not use JavaFX. What's wrong with it? Well, there are few caveats:
bundle size is larger because JavaFX is bundled whilst it is not really needed
main application jar needs to be packaged to comply to JavaFX packaging requirements(and this may be not trivial to achieve in your existing build scripts)
javafx application launcher may not work well with startup logic of your application (for example launcher will initialize networking stack and this may void custom networking settings in your application code)
In JDK 7 update 6 <fx:deploy> was updated to accept arbitrary
executable jar as an input. Self-contained application package will be created preserving input jar as-is, i.e. no JavaFX launcher will be embedded. This does not help with first point above but resolves other two.
More formally following assertions must be
true for packaging to succeed:
application can be launched as "java -jar YourApp.jar" from the command line
mainClass attribute of <fx:application> refers to application main class
<fx:resources> lists all resources needed for the application
To give you an example lets assume we need to create a bundle for application consisting of 3 jars:
dist/javamain.jar
dist/lib/somelib.jar dist/morelibs/anotherlib.jar
where javamain.jar has manifest with Main-Class: app.Main Class-Path: lib/somelib.jar morelibs/anotherlib.jar
Here is sample ant code to package it:
<target name="package-bundle">
<taskdef resource="com/sun/javafx/tools/ant/antlib.xml"
uri="javafx:com.sun.javafx.tools.ant"
classpath="${javafx.tools.ant.jar}"/>
<fx:deploy nativeBundles="all"
width="100" height="100"
outdir="native-packages/" outfile="MyJavaApp">
<info title="Sample project" vendor="Me"
description="Test built from Java executable jar"/>
<fx:application id="myapp" version="1.0"
mainClass="app.Main" name="MyJavaApp"/>
<fx:resources>
<fx:fileset dir="dist">
<include name="javamain.jar"/>
<include name="lib/somelib.jar"/>
<include name="morelibs/anotherlib.jar"/>
</fx:fileset>
</fx:resources>
</fx:deploy>
</target>
Option to
disable proxy setup in the JavaFX launcher
Since JavaFX 2.2 (part of JDK 7u6) properly packaged JavaFX applications have proxy settings initialized according to Java Runtime configuration settings.
This is handy for most of the application accessing network with one
exception. If your application explicitly sets networking
properties (e.g. socksProxyHost) then they must be set before
networking stack is initialized. Proxy detection will initialize
networking stack and therefore your custom settings will be ignored.
One way to
disable proxy setup by the embedded JavaFX launcher is to pass
"-Djavafx.autoproxy.disable=true" on the command line. This
is good for troubleshooting (proxy detection may cause significant
startup time increases if network is misconfigured) but not really user friendly.
Now proxy setup will be disabled if manifest of main application jar has "JavaFX-Feature-Proxy" entry with value "None". Here is simple example of adding this entry using <fx:jar> task:
<fx:jar destfile="dist/sampleapp.jar">
<fx:application refid="myapp"/>
<fx:resources refid="myresources"/>
<fileset dir="build/classes"/>
<manifest>
<attribute name="JavaFX-Feature-Proxy" value="None"/>
</manifest>
</fx:jar>
Ability to specify codebase for WebStart application
JavaFX applications do not need to specify codebase (i.e. absolute location where application code will be deployed) for most of real world deployment scenarios. This is convenient as application does not need to be modified when it is moved from development to deployment environment.
However, some developers want to ensure copies of their application JNLP
file will redirect to master location. This is where codebase is
needed. To avoid need to edit JNLP file manually <fx:deploy> task now accepts optional codebase attribute. If
attribute is not specified packager will generate same no-codebase files
as before.
If codebase value is explicitly specified then generated JNLP files
(including JNLP
content embedded into web page) will use it. Here is an example:
<fx:deploy width="600" height="400"
outdir="Samples"
codebase="http://localhost/codebaseTest"
outfile="TestApp">
....
</fx:deploy>
Option to update existing jar file
JavaFX packaging procedures are optimized for new application that can use ant or command line javafxpackager utility. This may lead to some redundant steps when you add it to your existing build process.
One typical situation is that you might already have a build procedure that produces executable jar file with custom manifest. To properly package it as JavaFX executable jar you would need to unpack
it and then use javafxpackager or <fx:jar> to create jar again (and you need to make sure you pass all important details from your custom manifest).
We added option to pass jar file as an input to javafxpackager and <fx:jar>. This simplifies integration of JavaFX packaging tools into
existing build process as postprocessing step. By the way, we are looking for ways to simplify this further. Please share your suggestions!
On the technical side this works as follows. Both <fx:jar> and
javafxpackager will attempt to update existing jar file if this is the
only input file. Update process will add JavaFX launcher classes and update the jar manifest with JavaFX attributes. Your custom attributes will be preserved. Update could be performed in place or result may be saved to a different file.
Main-Class and Class-Path elements (if present) of manifest of input jar file will be used for JavaFX application unless they are explicitly overriden in the packaging command you use. E.g. attribute mainClass of <fx:application> (or -appclass in the javafxpackager case) overrides existing Main-Class in the jar manifest. Note that class specified in the Main-Class attribute could either extend JavaFX Application or provide static main() method.
Here are examples of updating jar file using javafxpackager:
Create new JavaFX executable jar as a copy of given jar file javafxpackager -createjar -srcdir dist -srcfiles fish_proto.jar -outdir dist -outfile fish.jar
Update existing jar file to be JavaFX executable jar and use test.Fish as main application class javafxpackager -createjar -srcdir dist -appclass test.Fish -srcfiles fish.jar -outdir dist -outfile fish.jar
And here is example of using <fx:jar> to create new JavaFX executable jar from the existing fish_proto.jar:
<fx:jar destfile="dist/fish.jar">
<fileset dir="dist">
<include name="fish_proto.jar"/>
</fileset>
</fx:jar>
Self-Contained Applications: Specify application icon
The only way to specify application icon for self-contained application using tools in JDK 7 update 6 is to use drop-in resources.
Now this bug is resolved and you can also specify icon using
<fx:icon> tag. Here is an example:
<fx:deploy ...>
<fx:info>
<fx:icon href="default.png"/>
</fx:info>
...
</fx:deploy>
Few things to keep in mind:
Only default kind of icon is applicable to self-contained applications (as of now)
Icon should follow platform specific rules for sizes and image format (e.g. .ico on Windows and .icns on Mac)
Self-Contained Applications: Pass parameters on the command line
JavaFX applications support two types of application parameters: named and unnamed (see the API for Application.Parameters).
Static named parameters can be added to the application package using
<fx:param> and unnamed parameters can be added using
<fx:argument>. They are applicable to all execution modes including standalone applications.
It is also possible to pass parameters to a JavaFX application from a Web page that hosts it, using <fx:htmlParam>. Prior to JavaFX 2.2, this was only supported for embedded applications.
Starting from JavaFX 2.2, <fx:htmlParam> is applicable to Web
Start applications also. See JavaFX
deployment guide for more details on this.
However, there was no way to pass dynamic parameters to the
self-contained application. This has been improved and now native
launchers will delegate parameters from command line to the application code. I.e. to
pass parameter to the application you simply need to run it as "myapp.exe somevalue" and then use getParameters().getUnnamed().get(0) to get "somevalue".
