Deployment

[Igor Nekrestyanov]

We are working on improving deployment experience but obviously more 
work is needed.
There is no need to argument for it.

But we really need more specific complains/ideas/suggestions/feedback 
from you guys.
Please share what are specific pain points you are facing.

For the sake of clarity it will help to structure them to separate 
different "similar" topics:

   1) Runtime deployment/installation issues

       If application does not attempt to launch because "javafx runtime 
need to be installed" and
         you are sure it is installed then it falls into this bucket.

       Obviously it impacts overall deployment experience but we hope 
these issues will be less critical
         in near future once JavaFX will be part of Java Runtime.

   2) Standalone application deployment issues

       E.g. redistribution of javafx with the application, wrapping as 
.exe file, etc.

   3) Deployment issues for apps embedded in the browser/webstart

       E.g. runtime failures, signing issues, bad APIs, etc.

So far (quite unfortunate) we do not have many deployment-related issues 
reported to the JIRA from outside of Oracle,
and many of existing reports are non detailed :(
Please tell us what does not work (and when), what features are missing, 
where and why UE is suboptimal, etc.
We are looking into every single bug report we get on deployment and 
trying to do this promptly.

Most of reports we get are of the first kind (JavaFX-aware 
plugin/webstart artifacts are not properly registered)
and we had fixed a lot of them recently (in 2.1/7u4).
There are two big outstanding issues:

    A. Older JRE releases (including recent 6 updates!) are not fully 
aware of JavaFX Runtime
           and installation of such JRE on the system that has JavaFX 
may corrupt the registry.
           This is especially annoying as JRE 6 is being autoupdated and 
these updates may corrupt JavaFX installation.

         Changes had been done to JRE 6 installer to be more compatible 
with JavaFX and soon autoupdate will switch to JRE 7.
         JavaFX will become part of JRE installation too. With all this 
we expect this issue to be much less frequent in the real world.

    B. Users of 64 bit Windows system tend to install 64 bit JRE and 64 
plugin but most of browsers on these systems are 32-bit apps.
        (Chrome and Firefox are 32 bit)

        We are looking into improving messaging to make it more for the 
user. Not sure what else can be done.

I suspect that specific problem you are referring below is caused by 
installing 6u31 autoupdate on system that had FX.
Reinstallation of JavaFX should likely help to heal the registry.

Please do not hesitate to report issues you are seeing with latest 
JavaFX builds (ideally to the JIRA) and help us to troubleshoot them
(these areas are very sensitive to the system configuration and setup). 
We will be happy to work with you to get to the bottom of them.
Do not wait for "next" build, sooner we know about the issue sooner we 
can resolve it.
And given the nature of these issues more people report them more likely 
we will have enough details to reproduce problem in house.

Ideas, suggestions on what features might be useful or what changes in 
deployment architecture are needed are very welcome too,

-igor

On 4/18/12 1:42 PM, Pedro Duque Vieira wrote:
> Hi,
>
> I'm very concerned about the state of deployment in JavaFX. Just yesterday
> I tried the new example by Jim Weaver in
> http://learnjavafx.typepad.com/weblog/tweetbrowser.html.
> It doesn't work correctly in firefox nor chrome, only managed to make it
> work on IE 9 64bit. And it appears I'm not the only one.
>
> Also the state of application installers for Java doesn't seem that good
> either (I think).
>
> I think this is very critical, if the technology can't get to the users in
> a transparent, simple, reliable way than you'll almost certainly won't get
> it adopted.
>
> Thanks, best regards
>