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.limasoftw...@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.b...@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
