JavaFX Maven support (was: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls.)
igor.nekrestyanov at oracle.com
Tue Dec 6 16:22:19 PST 2011
>> One bigger question this whole topic raises for me though: what exactly is
>> the JavaFX installer doing? If it's just a case of getting the natives on
>> the path to make JavaFX work, why do we have to make users (and developers)
>> go through the whole, do you want to install JavaFX drama? Why can't it
>> just be another jar on the path of my custom application - a simple
>> dependency that I manage, much like I manage my log4j, spring, and datafx
>> dependencies, etc?
> A big part of it is the applet. Also, in the near future we'll be co-installed and then co-bundled with Java, so it will be everywhere Java is.
There are many reasons to have installer.
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.
As of now we expect JavaFX to work on top of JRE6 and therefore we ship
new version of deployment stack as part of JavaFX.
To register it in the browser/OS on Windows you need to make registry
changes. This is one big reason to have install JavaFX runtime.
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
have installed/use and autoupdate it when important updates are
available (e.g. security).
We also use the fact that JavaFX runtime is installed to be able to
autodetect runtime install path when standalone application is being
and to ensure other requirements are met (e.g. application may require
specific version of JavaFX to be available or presence of compatible JRE).
IDE like Netbeans can also detect where runtime/sdk is installed and
validate that libraries used to compile code .
Overall, having installer helps to ensure typical user/developer has
We realize it may be not perfect way for everybody and this does not
mean other distribution options are not possible. E.g.
1) Cobundling JavaFX Runtime with the application
In that case application is responsible to update private copy
of runtime and there are no detection issues
2) Installing JavaFX runtime as part of JRE or as JDK8 module
3) shipping JavaFX SDK as zip or maven module, etc.
I can not tell if Oracle will officially support any of them for
binaries distributed by Oracle.
Adding new official artifacts contributes to the test/support costs and
it is not my call anyways
but once JavaFX code is open sourced alternative/additional build
artifacts can be easily added.
Like Oracle does not provide official JRE/JDK packages tailored for each
of existing flavors of Linux but distro vendors can create them based on
OpenJDK if desired.
>> And if it turns out the installer does actually need to run, why doesn't it
>> just put the jfx natives on the system path so that when the runtime starts
>> up it will always find it, regardless of where that jfxrt.jar is on the
>> local filesystem?
BTW, having open lookup path for native libraries is generally security
hole that intruder may use if he finds a way to add file to the
directory on the path.
More information about the openjfx-dev