App vendors usually test jvm to death with the OS version they have during
development, then the testing budget is exhausted, and jvms are
"certified" with the following OS releases despite having only cursory app
vendor testing (because no one dares telling the truth to management about
the whole situation, not certifying them would be commercial suicide, and
testing them properly would cost too much).
Not surprisingly, the end result crashes.
Yeah sure, but once I get a system that works, that doesn't wake me up at night because it went down at 2 am, I'm inclined to sit on it.
The jvms OS vendors ship might not be tuned perfectly but at least they
work and distributions will fix them if they don't. App vendors support
will tell you to use the unsecure underperforming entreprise linux version
that was already old when they tested against it. And that after paying
$$$$ for gold support.
Maybe, maybe not.
I've got a limited amount of faith in vendors. My productivity as a developer was destroyed for about six months that I had to deal with race conditions or deadlock issues in the defective 2.4 kernel that shipped with RHEL 3. We bought RHEL through a third-party vendor, so support was useless, and I doubt that we'd have done better if we'd talked directly to RH. It probably would have taken a nearly-identical test machine and a few weeks of time from a full-time kernel developer to have fixed our problem, probably a total cost of 10x our yearly registration cost.
An upgrade to 2.6 solved the problem.
I do have faith in the 2.6 kernel, but I'm more interested in catching up with six months of lost time than I am in spending another few months screwing around with buggy software.
If they don't have the resources to keep their jvm current with OS
releases, they should be honnest and team with jvm/OS vendors (ie push the
fixes they need upstream during their testing phase, and rely on upstream
not to break it afterwards). They do rely on kernel/libc vendor packages,
and they're as impacting performance-wise.
Yeah, I wish that were all possible.
But there's a lot of nonsense in this world.
For years, RH shipped a free 'java' runtime that was completely broken, wouldn't run any real java applications, and ran toy applications with an order of magnitude worse performance than commercial java implementations.
The skills and knowledge about code generation, concurrency control, memory allocation and garbage collection in the open source world have been largely insufficient to make workable java implementations.
(Yes, the new gcc-java is a big step forward, but it's still quite quirky, and it's overall success depends on dumping AWT and Swing into the trashcan.)
Sun's software strategy is unclear (how could they possibly make money off of Java?) and their relationship with Linux is problematic. (A few years ago they laid off the developers of Solaris x86, now they're coming on full-force with Solaris 10 as a competitor against Linux.)
IBM has it's own Java runtime which is a derivative of Sun's -- at times they've put some good work in it. God bless IBM, but you can only count on them so far for support.
The 2.6 kernel team is doing big things, often really good things. Will those things introduce subtle breakages involving Java threads? Quite likely. Is it really fair to Sun and IBM to expect their engineers to solve problems immediately because some kernel developer had a 'good' idea they wanted to try out?
The kind of model you're talking about, in a lot of ways, might be easier when we're dealing with the kind of single-vendor hardware stack that you're likely to get from Apple or with SPARC/Solaris from Sun.
