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.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
