Musings from The Software Underground

I've been reading a lot on various sites regarding the blurb in an Apple tech note about Cocoa-Java being frozen at 10.4 lately, and I just wanted to correct some of the wildly inaccurate information and poor understanding of what Apple actually WROTE and about Java on the Mac in general.

1. Java development on the Mac is NOT going away. Apple didn't suggest that you not develop in Java on the Mac. They said that after version 10.4, new features of Cocoa will not be added to the Cocoa-Java framework. The note made no mention of Java development in general.


2. Apple is NOT pulling support for the Java Bridge. They didn't say they were. The Java Bridge != Cocoa-Java. The bridge allows objects to be morphed from one runtime to another. Cocoa-Java is a framework that depends on the bridge. Even with the feature set of Cocoa-Java frozen, every indication is that the bridge will still be there, and supported.


3. You WILL still be able to develop Cocoa-Java applications. As long as you don't need to take advantage of the latest OS X functionality post 10.4, you're good to go. The current framework provides more than enough to make a great fully-featured Mac application if you want to use Cocoa-Java. Apple also never said they were no longer supporting Cocoa-Java. They only said that after 10.4, that they would no longer be adding new features of Cocoa to the Java version of the framework.


4. Cocoa Java is NOT useless for real applications. There's a fallacy surrounding Cocoa-Java, and Java in general that it's "too slow" for real work. This is just wrong. I've seen fast Java applications and slow ones. I've seen fast Objective C applications, and slow ones. Like anything else, Java, and Cocoa-Java, are TOOLS, and it's always a requirement that the developer use the right tools for the job, and use them well. SQLGrinder 1 is written almost entirely in Cocoa-Java. I started it while using Mac OS X developer preview 4, and because I didn't know Objective C yet and knew Java very well, it was easier to use Cocoa-Java. That said, I know Objective C extremely well now, and MacGourmet is written in Objective C, and SQLGrinder 2 is has been rewritten almost entirely in Objective C, except for a thin JDBC connectivity layer. Is version 2 faster than version 1? Absolutely, but version 1, in most cases, wasn't that bad. Does it start up faster? Yes, but again, the version 1 start up time wasn't awful. (I've also learned a LOT since starting the first version of SQLGrinder, so the overall design and look and feel of version 2 is a lot better as well, but that's a separate issue).


5. The Java bridge is very useful for adding support to your application using libraries unavailable in Objective C, or on the Mac, that are written in Java. SQLGrinder is based on JDBC, which is a Java technology. Why? Because there are JDBC drivers for just about every database, most of them work really well, and most are them are free. Compare that to ODBC, or native connectivity libraries, especially for the Mac. There's just no comparison. The availability and use of the bridge makes it possible to connect to a LOT more databases than would be possible were there no Java bridge. It's a great piece of technology and it's used by more developers than most casual users probably know.
   

So all of this poses the question, "Why is Apple doing this?" Well I think that it takes a lot of work to keep the two in step. I think the Java bridge, and Cocoa-Java were really created for WebObjects, which doesn't need the latest additions to Cocoa to function. Compared to Objective C, C and C++, the number of people using Cocoa-Java is also probably pretty small. Note that there is nothing stopping people from extending the framework themselves if they want to in the future.

I think Apple just decided that it was time to move on. They most likely decided that they had taken Cocoa-Java as far as they wanted to and spent enough money on it. But, really, what's in the frozen API, everything up to 10.4, is an amazing set of functionality. Far more than is available in most frameworks, so their decision doesn't kill Cocoa-Java in any way.