Deployment

[Pedro Duque Vieira]

I agree with Anthony. We should only concentrate on end users. Developers
are another use case, and surely they have better knowledge of how things
work under the hood.

- double download size and not just for users of 64 bit platforms

Javafx runtime 32bit is only 6mb and the 64bit is 7mb which totals
something like 14mb. I think its still a small download.

Thanks, best regards,

On Tue, Apr 24, 2012 at 11:03 AM, Anthony Petrov
<anthony.petrov at oracle.com>wrote:

> On 4/23/2012 9:42 PM, Igor Nekrestyanov wrote:
>
>>  >  I'm sorry I thought this issues were known so I didn't report them.
>> I'll report the issue to Jira than.
>>
>> Many registration issues have different "roots" whilst appear to be
>> similar on a surface.
>> Thank you for your help!
>>
>>>
>>> As for issue B wouldn't it be possible to install both 32bit and 64bit
>>> JVM for users that have 64 bit PCs?
>>>
>> This is one option.
>>
>> Complications are:
>>   - double download size and not just for users of 64 bit platforms
>>        (how do we detect what user needs)
>>   - user may want to have different JREs
>>        (e.g. experiment with beta build, etc.)
>>
>
> A user does not want to experiment with different JREs. He may not even be
> aware of what JRE or Java is. A developer may want to do so, but not the
> user. While we're discussing the deployment issues we must first
> concentrate on end-user experience which must be flawless and shiny. There
> might be an alternative interface for developers, even an ugly one.
> However, we should do our best to not spread this possible ugliness to the
> deployment model for end users.
>
> Just my $.02.
>
> --
> best regards,
> Anthony
>
>
>    - Good user experience requires use of single (32-bit?) installer.
>>       Historically installer changes take long time and any bugs there
>> are highly visible (as everyone goes through install step)
>>      This is significant amount of work for install team.
>>   - Technical complications related to the build infrastructure.
>>      We use distributed build systems (more than one) and build on
>> different platforms separately. Full build on windows is taking hours.
>>      For "true" combo installer  we will need to build 32 and 64 bit
>> separately, then import 64 bit artifacts and build combo installer.
>>      Possible but this is non trivial technical effort given number of
>> impacted teams.
>>
>>   I think most users aren't aware what 64bit/32bit is, and the best would
>>> be if this was transparent to the user. Would it be possible to autodetect
>>> this?
>>>
>>
>> This is what we exploring as short term solution - be more explicit what
>> user needs if we can detect it.
>> This applies to both message in the web page and landing page where user
>> need to pick JRE/JavaFX to download.
>>
>> -igor
>>
>>>
>>> Thanks, best regards,
>>>
>>> Sent from my iPad
>>>
>>> On 20/04/2012, at 06:55, Igor Nekrestyanov<igor.**
>>> nekrestyanov at oracle.com <igor.nekrestyanov at oracle.com>>  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<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
>>>>>
>>>>>
>>


-- 
Pedro Duque Vieira