Re: Apple should get behind QuickTime for Java

On 17 Aug 2006, at 15:52, Chris Adamson wrote:

Take with a grain of salt, given my obvious biases...

Jerry writes:

Following on from the Cocoa thread, another neglected area is QuickTime for Java. This is a fantastically useful thing to have, but it suffered from having its API completely deprecated (and broken) and then redefined, and is now quite limited

Limited? You can write a full-blown video editor with it and export to your choice of formats. You can work with .mov's, .mpg's, .mp4's, .aac's, .m4a's (iTunes Music Store files, which are understandably play-only), .swf's, etc., and by getting third-party QuickTime components, you can encode MP3 (with the LAME framework and encoder) and import, play, and export Windows Media (with Flip4Mac).

Well, OK, I take it back about the "limited" thing then :-) I'm still recovering from the "deprecatastrophe" (good word) and I kept coming across stuff which didn't work any more.

The "deprecatastrophe", as I call it, was unfortunate, but it's in the distant past. QTJ 6.1 came out like, what, three years ago now? The presence of all the deprecated examples on the website is not helpful (I've filed a bug about how bad the QTJ web pages are), but the fact of the matter is, the overwhelming majority of the native QuickTime API is callable from Java.

It's not so much in the distant past for me - I keep coming across old projects :-) The documentation is impossible and last time I looked practically every piece of sample code was marked as deprecated. I suppose what I'm complaining about mostly are that these things seem to show a lack of commitment to the project and we're made to feel as though it might be a big mistake to try using QTJava. I'm doing a video capture project at the moment, and I'm just uneasy that QTJava might suddenly disappear under my feet again.

The other thing is that QTJava gives the impression of being a closed system - (last time I looked) all the sample code never goes outside QuickTime - there's no interoperability with the rest of Java. If you investigate hard enough you can work out how to convert between BufferedImages and QuickTime, but it isn't pleasant.

For example, why are we restricted to reading TIFF, BMP, PNG and JPEG images in Java - why isn't there an ImageIO plugin for QTJava which would let us read and write all the other formats?

Since QTJ piggy-backs on native QT and its scheme of expansion through components, the correct answer is to get (or develop) a native QT component for whatever image file type you need support for -- then it'll be available in your native QuickTime apps *and* QTJ. Yeah, I know, icky scary C -- It *may* be possible to write a component in QTJ, but I don't know that anyone's ever succeeded (or tried, for that matter).

That's sort of what I meant: This is my personal wish: The Mac has all this wonderful image I/O stuff, Java has APIs for reading images. The two should come together. On the Mac I should in native Java be able to read in any image which QuickTime understands without going through QTJava. I mean I should be able to read, say, PCX images using Toolkit.getImage or ImageIO. That way every Java application wins and developers need do nothing. All that's needed is for Apple to provide an ImageIO plugin which uses QTJava. I have written such a thing, but it isn't complete enough (all that metadata stuff is really complicated, but reading/writing the pixels is trivial). I'm being incoherent here, I know, but I think that Apple should strive to make OS X the Java platform of choice by providing these sort of extras, just as they provide AppleJavaExtensions to make it possible to give a Macintosh experience to Java applications. While I'm on a rant. for the same reasons, they should also pay Werner lots of money and bring Quaqua into Mac Java.

References:
	>Re: Apple should get behind QuickTime for Java (From: Chris Adamson <email@hidden>)