On 3/09/2013 20:34, Richard Bair wrote:
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.
Actually, one of the best things of Java is that in like 99.9% of the
cases, my app will run flawlessly on whatever version of the JDK or JRE
is installed... on multiple platforms. If Java goes down the road of
requiring testing against a specific JRE (and thus specific platform by
extension) then that is its biggest advantage lost.
In fact, any framework that does not aspire to do the same (being
backwards compatible to a flaw) is not a framework I'll consider for
production use. I want to be able to upgrade, and at most run my unit
tests to have the confidence that it will perform as expected. There
can always be mistakes, both in the frameworks or in my code doing
something that was undocumented or incorrectly interpreted, but in the
end backwards compatibility is what makes or breaks a framework -- a big
reason for that is that such frameworks are actually designed with some
care, exactly because they aspire to be backward compatible... and a
good API is everything.
--John
