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

[Daniel Zwolenski]

Hi Igor,

Thanks for the info, some comments inline below.

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?

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. The installation is the first
experience everyone will have of JFX and it there is a legacy in this area
from old Applets, etc, of Java being heavy, unfriendly and buggy in this
area. It was one of the reasons we lost ground to the web guys in the early
days of AWT and Swing. JavaFX needs to fight the "battle for hearts and
minds" on this one, failing that it needs to call in some "shock and awe".

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. 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). 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.

I think it will probably be a bigger problem than just for weird developers
like myself in the future though. 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?

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. Or even application servers like tomcat - if
these have problems, I download a new release when it suits me, I don't
want tomcat randomly updating itself.

Is it actually JavaFX that has the risks and needs to be updated, or is the
browser plugin deployment tool thing?

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.


> and to ensure other requirements are met (e.g. application may require
> specific version of JavaFX to be available or presence of compatible JRE).


This should all be taken care of by the normal JNLP stuff no? What is it
that JFX does above beyond what standard JRE/JNLP has been doing for a
while?


> IDE like Netbeans can also detect where runtime/sdk is installed and
> validate that libraries used to compile code .
>

IDE's are built to work off jars on the classpath. I would think they
should be able to validate against a jar? In most cases I imagine they
would find this more natural and easier than referencing an install path
somewhere.

Overall, having installer helps to ensure typical user/developer has
> reasonable environment.
> 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.
>

Once the licencing issues are sorted and once we get access to the code
that does the DLL loading, I will certainly be looking at ways to make the
install as simple as possible for my end users. Webstart is such a powerful
feature though and the newer JFX build tools make all this nice and easy to
use. It seems a shame not to be able to leverage these due to reasons of
usability, rather than technical requirements.

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.


Agreed, I was thinking more about placing the dlls on the windows system
path as when you install most other normal windows applications. Then when
the code is run, it won't matter where the jar is, the dlls will be found.