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
