Because I’ve been a hermit over the past few days, I’m only now reading about Sun’s open source event earlier this week. Sadly, I wasn’t invited (likely because I work at IBM and I’m a peon in the OSS landscape). :-)
Looks like there was more news about Project Indiana, Glassfish, and OpenOffice. I wonder if there’s a place to get the presentations that were used?
This statement caught my attention:
“Red Hat has created a project called Ice Tea to make OpenJDK run better in a Linux environment, Reinhold said.”
Just because two JDKs pass Sun’s test suite doesn’t mean there won’t be (unexpected) differences in the way they handle the same Java application. Sun’s TCK (Technology Compatibility Kit) attempts to minimize the impact of these differences, and generally does a good job, but differences will exist. That’s why most ISVs state which JDKs are supported. If your ISV says their Java product runs on all the leading JDKs, it could be that they’ve tested their app on the Sun, IBM and BEA JDKs. Or it could mean that the ISV has tested with one of these three (or an alternative) and is relying on Sun’s TCK tests to ensure there won’t be unexpected results on a different JDK. This isn’t such a bad strategy 99.99% of the time. But there must be a reason that some ISVs test on multiple JDKs ;-)
I wonder what % of ISVs will be enamored by the news that Red Hat is creating another JDK that could be added to the ISV’s test matrix. Being an OpenJDK variant helps if the ISV is already testing with the Sun JDK. But, a little different may be different enough. If Red Hat’s JDK doesn’t gain much traction (which is my guess, largely because of the ISV testing and support challenges), will Red Hat have spent their time tuning/improving the Sun JDK for RHEL?
Anywho, here’s a good description of Ice Tea from a Red Hatter.
10.19.07 at 10:23 am
What we really need is a community based test suite above the TCK level that lets people know and verify how well their existing open source infrastructure will run on any given implementation.
Think Gump with versioned dependencies, rather than CVS/SVN heads, and where all the code going in is exclusively open source.
That’s orthogonal to the need of proprietary ISVs (but that’s the price one pays for reserving the right to profit from locking one’s users in), but matches nicely with the needs of open source ISVs.
And in the long run, hopefully only the latter kind will matter in the market …