Oh no, not again.
JMF, the Java Media Framework, has had a history that can honestly be described as alternating periods of ineptitude and neglect. The fact that the JMF home page has only seen three updates in the last two years, and none in the last twelve months, indicates that JMF is in the latter state.
And now this post to the JMF-INTEREST list:
I’m T— W—- and have recently taken responsibility for JMF at Sun
We are in the process of planning what to do with JMF and would like
hear from you
regarding how you are using JMF and what your needs are. Please feel
free to contact
me directly as some of the other feedback channels are currently not
Oh, where to begin?
OK, before I offer any more criticism, I need to acknowledge that I’m the author of a book on QuickTime for Java, a rival Java media framework. Some may think I’m trying to goose my own book sales. Think that if you like, but the book’s been out for a year and has probably sold most of the copies that it’s ever going to.
And let me add this: I started with JMF. If it were good, I might never have moved on to QTJ. After all, QTJ is limited by the fact that it only works on platforms with native implementations of QuickTime — meaning only Mac and Windows. An all-Java media framework would be tremendously valuable to the Java platform.
But I am absolutely convinced that Sun is in no way capable of creating such a thing.
The proof of this is in the results: since its release in 1998, JMF has gained practically no traction, and has been largely ignored since the release of JMF 2.0 in late 1999. We’ve gone six years with virtually no substantive work on the framework.
A little history as to how we got here… With no experience, credibility, or patents in the media field, one might have expected Sun to take on a partner in developing JMF, someone like Macromedia (Flash), Apple (QuickTime), or Real. Instead, they developed JMF 1.0 with Intel, and 2.0 with IBM.
JMF 1.0 was quickly pulled together to enable playback of dynamic media — audio and video — in Java desktop applications. JMF 2.0 added capture, streaming, and pluggability. But because of the high demands of media and the modest performance of late 90’s VM’s (and the capabilities of the hardware they ran on), all-Java media handling realistically needed to be bolstered by native “performance packs”, which improved JMF on supported platforms by using high-performance native code, and access to the platfrorm’s native media frameworks.
So… what’s the problem? Here are a few:
- JMF has no editing API, nor any meaningful concept of media in a stopped state. That means it can’t be used for building, say, a podcast editor (can’t trim your clips), or iTunes (no metadata API for reading the track titles). Aside: what’s the point of a capture API if there’s no way to edit the captured data (apparently, the capture is only useful for streaming applications).
- Sun made a performance pack for Solaris, that ubiquitous champion of the desktop, and not for Mac Classic or Mac OS X.
- The included codecs supported few media types in common use at the time, and those that were used in 1999 (Cinepak) have fallen out of use.
- The system for managing plug-ins, the “JMF Registry”, was extremely brittle.
- The scheme for finding an appropriate plug-in used the wildly inefficient tactic of using exceptions for program flow.
- Sun expected Macromedia to develop the Java support for the Flash format, and Macromedia lost interest, leaving JMF supporting only Flash 2.
Now it’s six years later and what’s been done? MP3 support was taken out of JMF for a few years due to licensing concerns, then put back in. Other than that, the framework has languished. Sun got interested in JMF again in July 2002, but they couldn’t actually hire anyone to work on it, and ended up not actually doing anything with it. So, developers come along, try to discover what it can do, and often wander off in disgust that it can’t work with modern formats. Some go to QTJ; many more probably call native frameworks with JNI, or just abandon Java altogether.
Now Sun wants to know what to do with it? Seriously?
Look, nobody developing a commercial application could risk Sun walking away from JMF for another six years. And given the utter lack of interest from third parties in extending this built-to-be-extended platform — it would be straightforward to bring Real to JMF via the open-source Helix platform, but nobody seems to have bothered — there’s no realistic chance of a third party coming to the rescue.
And seriously, what’s the point? Does Sun have a strategic vision for JMF? Is there some genuine value it can bring to the Java platform? Will putting dollars into new development pay off someday? Are these questions really going to be answered by casually throwing out a “Hi, what should we do with this?” to the handful of developers who are still hanging on?
For a lot of reasons, some technical, some not, JMF is a hopeless case. Unfortunately, due to the benefits of incumbency (the prominent
javax.media package), it lures developers into a Venus Fly Trap of minimal functionality and unfixed bugs.
So, Sun, do you want to know what I think you should do with JMF? Deprecate it. Stop wasting our time. Tell everyone you’re done and move on to something that might work out better.
What good could come from reviving JMF?