Apple won’t provide further updates to Java, but OpenJDK for Mac OS X is advancing rapidly.
Thankfully, TheServerSide.com provides an extensive list of OpenJDK/OS X related links:
For more information about the Mac OS X Port project, please check out these resources:
Project home: <http://openjdk.java.net/projects/macosx-port>
Project wiki & getting started instructions: <http://wikis.sun.com/display/OpenJDK/Mac+OS+X+Port>
Project status: <http://wikis.sun.com/display/OpenJDK/Mac+OS+X+Port+Project+Status>
Mailing list: <http://mail.openjdk.java.net/mailman/listinfo/macosx-port-dev>
Source repository: <http://hg.openjdk.java.net/macosx-port/macosx-port>
You are looking for binaries? Then head over to the opendjk-osx-build project on Google Code (via).
My iCal kept crashing constantly due to a segmentation fault (EXC_BAD_ACCESS, SIGSEGV). In the short time right before it crashed, I noticed that iCal tried to sync with a corrupt external calendar. The bad data got into iCal once, and iCal didn’t stand it 
If you happen to meet a failing iCal one day, and you can’t remove the mischief from within iCal, you have two options:
- get the decent Purity app, unplug the network (so that iCal won’t sync before the culprit has been removed), and clean the iCal cache
- have a closer look at ~/Library/Calendars/, where all the calendars are stored. Inspect the info.plist files and .ics event data to find the bad calendar and move its folder to another location. Restart iCal. If it is still crashing you got the wrong calendar – put the moved calendar back and keep on searching.
No. 2 did the trick for me.
Plain text files and simple folder layouts might not look as evolved as SQL tables and mysterious binary data files – but they work just fine in this scenario and are pretty easy to debug.
Apple just released Mac OS X 10.6.3. Pretty good. As usual, the list of bug fixes and patches is quite long. Thanks for that 
Oh, and they added a diagnostic and usage data collection … erm, feature? Hey, it is even enabled by default:
If there was a possibility for opting out I must have missed it somehow. Actually, I am pretty sure they did not ask me.
Speaking as a software engineer, I understand that crash logs and usage data can be invaluable for creating timely and to-the-point patches and updates. On the other side, this is my system. And the data stored on it is mine. Once again, speaking as a software engineer: in the way of creating new applications, a lot of crashes will occur. Bugs need to be squashed, and features to be added. Why should Apple know what I am working on? Or simply what video I was looking at before Youtube crashed? Or what mail caused Mail.app to go down in flames?
And why is it so hard to ask your customers if they want to take part in the user data collection before such a gimmick is activated?
Read more about the Diagnostic and usage data collection (and how to disable it) here.
September 8th, 2009 niels Apple apparently set Java 6b14 (64 bit) as default in Snow Leopard, both in 32 and 64 bit Kernel environments.
They dumped Java 1.4 and Java 5, but you can switch to Java 6 (32 bit).