Why is almost everything in the API final
cognitionmission at gmail.com
Tue Sep 3 14:08:54 PDT 2013
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
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.
> 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.
More information about the openjfx-dev