JavaFX Maven support (was: hg: openjfx/2.1/master: Added build scripts that are needed for building UI controls.)

[Igor Nekrestyanov]

Hi,

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 
based.
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 
migrate to
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 
launched
>
> 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 
launcher program
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 
JRE)
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
> while?
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.

-igor