Day 1 JavaONE

JavaONE 2009 1 day down, 3 to go. I wish I could give a lot of information about the sessions I attended but with so many things happening, I wasn't able to get to a single session finally attending a the meet the HotSpot team BOF at 9:30pm!

The big buzz was about Larry Elison joing Scott McNealy on stage to end the keynote. Keywords coming from Larry included JavaFX, netbook, phones, an end to AJAX and oddly enough OpenOffice. He didn't come close to addressing the big questions of GlassFish, mysql or more importantly, community. I've got my own speculations on what the future holds.

My speculations are based on how Oracle has managed it's prior major acqusitions. They have always seemed to provided further investment into key components of those businesses. If this trend continues, the future looks bright for JavaFX. The odd ball in the list I expect will see increased investment is OpenOffice. Larry mentioned that he'd like to see OpenOffice embrace JavaFX. To make that happen will require a large investment in both technologies.

Another big question is about the future of mysql. I know that there is currently a lot of backroom politics around mysql and that things that have happened that have upset key people involved with the project. However, I don't see Oracle burying mysql. Being open source, MySQL could be forked (I believe it might already have been) and not only is trying to bury it not really possible, it would alienate a very large community. I don't think that Oracle is interested in alienate communities.

Sun has done an enviable job of building community. Many companies would give their right arm to have the numbers, size and diversity of communities that Sun has been able to build. If we keep with the do not alienate theme, it stand to reason that many of the things that Sun has done are safe because of these large communities.

People have been speculating that Oracle will drop GF. I'd bet they don't. Reason, its the RI. Dropping GF flys in the face of Oracles tradiionally strong support of the JCP. Want more assurance, think JPA. Also the economic downturn has created situations where companies made compelling business cases to move to GF from other implementation. This acquisition may put those plans on hold until Oracle gives some indication as to how they are going to handle GF. That is only being prudent. However Oracle will recognize that they are going to want these companies business.

All in all the Sun employees seemed fairly calm about the acqusition. Some had a wait and see attitude but in the mean while, it will be business as usual.

HotSpot Team BOF

The HotSpot BOF was interesting as always. I got in my fair share of questions and requests. Topics on my hit list was a backhanded comment on CMS and permspace. Why permspace GC with class unloading is not on by default is beyond me but as long as it isn't, I'm going to keep seeing request for help from teams who have turned on CMS only to start experiencing OOMEs.

On locking optimizations, seems like the infoq article written by Jeoren Borgers that I had a helping hand in may have exposed some bug in biased locking. I'd always assumed that the failure of biased locking to hold in about 1/3rd of the runs was due to some race condition. That still maybe true but the finding surprised the team even though it had been published quite some time ago.

Next topic of interest was GC log rollover and GC log format. We may finally see GC log rollover which means that it will be able to safely leave GC logging turned on in production. The other problem is GC log format. I'm glad to hear that they will not resort to XML. That said, it doesn't seem a burning priority to clean up the logging information so that we finally have a dependable machine readable format.

Some bullet item I'd like to mention here, on stack allocation for local variables. The optimization allocates fields in registers and not on the stack as the name suggests. Neelan support is already being baked into Hotspot and work continues on the G1, the long awaited replacement for CMS.