What's up with Mac OS X Java and QuickTime?
Some developers who installed Apple's new java 1.4.1 for Mac OS X (and didn't read the release notes or the mailing lists) got a nasty surprise when they tried to run apps they'd written for use with QuickTime for Java:
cadamson% java -classpath PlayMovie.zip PlayMovie Exception in thread "main" java.lang.NoClassDefFoundError: com/apple/mrj/macos/carbon/CarbonLock at quicktime.jdirect.QTNative._getLock(QTNative.java:111) at quicktime.jdirect.QTNative.(QTNative.java:105) at quicktime.QTSession.(QTSession.java:114) at PlayMovie.main(PlayMovie.java:24)
What's happening is that java 1.4.1, now the default when you type
So why so much breakage? The story, as well-covered by MacDevCenter's Daniel Steinberg in Apple Releases Java 1.4.1 for Mac OS X is that Apple has made a huge under-the-hood change, swapping out an AWT/Swing implementation based on the Carbon API for one built on Cocoa.
The change is quite significant, as the move to the
object-oriented, multi-threaded Cocoa environment appears to have
significantly simplified Apple's java codebase. However, it now makes
calls from Java into Carbon code much more difficult. As explained in
As a result, in many cases, they've decided to replace or
simply abandon the Carbon-bound java extras. The
Notice that both terms, "MRJ" and "JDirect" are implicated in the stack trace above. The QTJ code tries to get the carbon lock to avoid hosing the Human Interface Toolbox, but the
However, the situation is not as bad as it might sound. java 1.3.1
remains in place after a 1.4.1 upgrade, and will still run QTJ apps, and will reportedly be included in the next major release of Mac OS X. And in some cases, 1.3.1 will be the default JVM, for example, if your app is distributed as a
With java 1.3.1 sticking around on Mac OS X for the foreseeable future, and with ways to call it explicitly, there doesn't seem to be need for QTJ developers to panic just yet.
Still, the future of QuickTime for Java does seem to be up in the air. It has not been explicitly canceled or deprecated, as have other API's, but it clearly and unapologetically breaks in 1.4.1, which makes a lot of QTJ fans nervous.
It's strange because until now, QTJ had seemed like a first-class citizen in the QuickTime world, prominently featured in developer documentation (the main QuickTime API documentation even cross-references all Java equivalents to the native API's calls). Yet on the QuickTime for Java page, Apple says it is "interested in hearing from QuickTime developers and understanding what aspects of the technology they are using", as if it needs a business case to be made to commit to the technology (or some subset of it) going forward.
From what I've seen, QTJ interest is greater than it has ever been, a beneficiary to some degree of Sun's neglect of the Java Media Framework, which has not seen a major version since 1999, as Sun's media team has focused on a Mobile Media API instead. Developers who want to do media apps in Java are choosing between several imperfect options:
My fear is that if QTJ is not supported in the future, that option 5 will be the default, i.e., it will pretty much close the curtain on developing media applications in java, because the other options are too much work for too little benefit. And that will make developers like me wonder if we like QuickTime so much that we're ready to give in to the crazy square-braces and semi-automatic garbage collection of Objective-C. Time... or is that QuickTime... will tell.
Chris Adamson is an author, editor, and developer specializing in iPhone and Mac.
Comments on this weblog
1 to 3 of 3
1 to 3 of 3
Return to weblogs.oreilly.com.