Deployment

[Tom Eugelink]

Ok. How about the "there is no standard way to distribute a stand alone JavaFX application"? Create a JIRA issue?

Tom


On 2012-04-20 07:55, Igor Nekrestyanov wrote:
> 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
>>
>
>