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 22:56:28 PST 2011
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.
> The plugin to run Java makes sense, and this has been around for a while
> now. Improving it is nice, but this should be done back in the core JRE
> area I would have thought? It's the 'install' of JavaFX that I am confused
> about. I'm possibly over simplifying things but if JavaFX is just a jar and
> some native DLLs then isn't it just another library that gets added to the
> classpath like everything else?
No, unfortunately it is not that simple.
First of all plugin and webstart code used to be inherently Swing/AWT
To get most of JavaFX (at least performance wise) you do not want to run
it in the heavyweight AWT container or load Swing/AWT classes.
Browser integration is not that simple if you want to use hardware
acceleration in browser window.
There is special code in JavaFX to attach stage to window handle
provided by the browser.
Obviously Java plugin in JRE6 has no idea of JavaFX existence as it was
implemented years before it.
Hence to be able to support users who stuck with JRE6 and can not switch
to latest JRE7 (or 8) we
are shipping updated copy of deployment with JavaFX.
JavaFX-specific changes are merged back into JRE source base. E.g. JRE7
update 2 has (almost) the same deployment stack as JavaFX 2.0.2.
But deployment code need to be in sync with JavaFX code and dependencies
are tight. So, as we march to support new platforms (Mac/Linux)
source bases will again be different for some more time.
Eventually JRE will include full JavaFX capable plugin and there will be
no need to include it into JavaFX (assuming most of the users will
new version of JRE). But this likely will take time.
> Ideally installing the plugin(s) really needs to be simple (1 or 2
click install). Currently the Java one takes me off to another page and
makes me jump through a lot more hoops and then the > JFX one has
another go at me. It would be great if we could work out ways to avoid
these hoops. Maybe the co-bundling will fix all this, but it would be
nice to just streamline everything as
> soon as possible.
Cobundling should improve things a little but in general i agree user
experience could be improved.
We would be happy to hear about possible ideas of how to improve the
process (and yet satisfy legal requirements such as accepting the license).
> 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
>> users have installed/use and autoupdate it when important updates are
>> available (e.g. security).
> This is a risky approach, especially for developers. I often have multiple
> JDKs and JVMs installed on my machine which means I need the correct JFX
> install in each.
There is a difference between developer who needs SDK to build app and
user who only needs runtime to run app.
We are not autoupdating SDK as it can not be used by attacker.
Like with JDK you may still have multiple JavaFX SDK installed (at least
i do not see why not).
Runtime is different. Whenever you open web page with javafx application
it will be launched using installed runtime.
And if this runtime is vulnerable then user is in trouble. Keeping it up
to data and secure is important.
If you really need to test with older version of runtime then you can
install it and decline offers to autoupdate it.
> I currently have a system where it thinks I don't have JFX installed
but I do, but not in the JRE the browser is using, but the deployment
tool won't let me install it because it thinks I have it
> already installed. In fact each of the computers I use (3 of them)
seem to do something slightly different when I try to run an applet and
something different again when I run a webstart app > (and rarely do
they work, and never with any real message on why they failed).
Sorry to hear that.
Would you mind filing issues on this and providing us with trace/log files?
> My best guess is that the multiple versions of stuff is confusing the
deployer. I have 64 bit and 32 bit versions on my machine at the same
time too, as some of the native libraries (e.g. finger print scanner)
that I use need this.
Well, in theory both plugin and webstart are supposed to use one
"latest" version as it should supersede others.
If you have both 32 and 64 bit versions then there are 2 "latest"
versions and they are selected depending on whether your browser is 32
or 64 bit.
(Most of the browsers are still 32 bit).
Typical source of the issues right now is that JRE6 is not fully updated
to be JavaFX aware and if JRE6 is installed/uninstalled/upgraded while
JavaFX runtime is installed then it can corrupt registry. Also, before
2.0.2 installer had nasty bug and if JavaFX runtime was installed by one
user then another user could neither install it nor use it i think.
We are solving these issues as we learn about them. Please report bugs
to JIRA and we will do our best to make it more robust.
> When we have multiple versions of JFX out there, we will end up with
JNLP files specifying specific specific versions to use (as we see now
with Swing and JRE versions). If a jnlp file sepcifies an older version
of JFX is required (i.e. I don't want my code to run on the latest
because it causes me problems, etc), then what will the install tools do
in this case?
Current thinking is that we will only allow to specify minimal version
assuming all JavaFX version in the same family are backward compatible.
I.e. you can request 2.0.2+ but if user has 2.0.3 installed you can not
request him to install 2.0.2.
> What exactly are the security risks associated with JavaFX? How does
this differ to say me using another display library like SWT or any
toolkit like GWT, or hibernate, or spring.
The biggest difference is that JavaFX will likely be preinstalled on
large number of systems and shared between different applications.
It does not come as private part of the application (by default).
> We also use the fact that JavaFX runtime is installed to be able to
autodetect runtime install path when standalone application is being
> Can you elaborate on why standalone apps would need this and how they can
> work this out? The problem we have at the moment is exactly that the
> standalone app can't find the installation path (and hence the native
> files) without being told where it is via the system path, which is not
> setup by the installer. I'd be interested to understand more about this
> autodetect mechanism, how it is used currently, and how I might be able to
> make use of it.
If you follow JavaFX application packaging guidelines (see deployment
guide on javafx.com) then result application jar will contain small
that will be used as default entry point (e.g. when you double click on
jar) and it is capable of checking system requirements (e.g. presence of
and detecting where JavaFX runtime is installed. Then it will setup
classpath to include required.jars and instantiate main Application class.
> What is it
> that JFX does above beyond what standard JRE/JNLP has been doing for a
E.g. embedded launcher can check this without JNLP.
I.e. you can ship just jar file and user will be guided how to run it as
long as it has java.
More information about the openjfx-dev