Deployment

[Peter Pilgrim]

I disagree.

JavaFX deployment must also ultimately serve *client-centric design*.
Enterprise issues are more important than end-user ones because
user-centric design is a subset of the client-centric design. After
all, it is business and commerce that drive profits and the economy;
and if a business, whether large like a financial or small as in
start-up, decides to invest in JavaFX UI solutions it could be a major
win for the platform, and from such adoption will then come the users.
So making this all so easy for business people is supremely important.

In my travels in financial services at least here in London I have met
at least one senior manager who said he got burned by the Java plugin
circa 2000-2001. He swore never to depend on Java runtimes again and I
suspect many people have long memories of that time delegated the Java
as only suitable for Java EE and/or Spring. The coming deployment
solutions needs to be lightweight, intuitive  and efficient.

Sent from my iPhone 4S

On 24 Apr 2012, at 16:08, Anthony Petrov <anthony.petrov at oracle.com> wrote:

> On 4/24/2012 6:31 PM, Igor Nekrestyanov wrote:
>> On 4/24/12 3:03 AM, Anthony Petrov 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.
>> That's true.
>> What i meant is that user may want it because application he use depends on specific JRE version.
>> He may not be aware of it - just use specific browser to run corporate applications and other browser for other apps
>> (e.g. use IE64 with JRE6 for corporate app and 32 bit Chrome for everything else).
>> Or corporate admins can set his system this way.
>> > 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.
>> That's true too but IMHO we also need to consider other subgoals
>>   - should be easy for developers to deploy their apps
>>   - enterprise setups where environment is (at least partially) controlled by admins
>>   - compatibility requirements - application might be certified to run in specific environment (e.g. with JRE6)
>
> These subgoals must certainly be considered. However, easiness and simplicity of deployment for end users must be our top priority for now. And we should never sacrifice it for the sake of developers/enterprise admins. They undoubtedly are very important users from our (FX/Java developers') perspective, however, these user categories can easily live with not-the-most-convenient solutions for their requirements, while the end user would simply drop inconvenient apps/frameworks and would never come back. We may improve the situation for advanced users later, but at this time we must focus on end users.
>
> --
> best regards,
> Anthony
>
>> -igor
>>> 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>  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
>>>>>>>
>>>>