Why is almost everything in the API final

[Richard Bair]

The user has downloaded an app -- they have established and explicit trust relationship similar to any other native app by choosing to execute it. For apps distributed through the apple store (for desktop, the same as mobile) the update will happen via the store instead of directly over the air. For one-shot apps (the kind you find while browsing), this model doesn't work well (since I would be hesitant to run any random app I've downloaded off the internet -- but I don't have a problem running apps I download over the internet from a source I trust).

Richard

On Sep 3, 2013, at 11:48 AM, Mario Torre <neugens.limasoftware at gmail.com> wrote:

> But this puts the task to update the jre in the hands of the developer, no? This would be very insecure in my opinion then.
> 
> Cheers,
> Mario
> 
> Il giorno 03/set/2013 20:36, "Richard Bair" <richard.bair at oracle.com> ha scritto:
> >> I would strongly recommend leaving the shared JRE install world behind.
> >
> > As a suggestion, try JWrapper - we have flawless installs now, even using an OSGI deployment procedure! Bundled JVMs are really the only dependable way to go now it seems?
> 
> If my business were betting on it, I'd not use a shared install for a couple reasons:
>   - I want to control the *exact* version of the JRE such that my app testing was done against a specific version of the JRE
>   - I have the freedom to modify the JRE as needed for my app
>   - I can deploy as a normal desktop app using normal mechanisms
>       - Related, I don't have to field support requests around what version of Java is installed or not, or Java install problems
> 
> I can still have auto-update with an app cobundle, so I don't miss out there either.
> 
> None of these points are suggesting the problem is with WebStart's implementation, they all hold even if WebStart were completely bug free. They're just the natural side-effect of a shared install system.
> 
> Richard