Why is almost everything in the API final

[David Ray]

When you have a new version of your app to distribute, you would repackage it using the same tool you did before - maybe specifying a new JVM target (if you would like to update the JVM that gets bundled with the app). Then upload your app to the Apple App Store and voila' :)  (Ok so there's the extra step of the endless slew of provisioning licensing and packaging hurdles introduced by Apple -- then voila' !!!)   :-D

David


On Sep 3, 2013, at 1:48 PM, 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