The Freedom for Media in Java (FMJ) project released an initial 0.1 version of its open-source, clean-room implementation of Sun’s Java Media Framework (JMF). The goal of the FMJ project is to create a drop-in replacement for the Java Media Framework in order to "fill the cross-platform vacuum left by Sun’s abandonment of JMF," says FMJ project lead Ken Larson in an email interview with Artima.

FMJ aims beyond Sun’s JMF by extending platform-specific support, or performance packs, for Mac OSX and 64-bit Linux, providing modern codecs, such as MPEG4, improving overall performance, and simplifying installation. Codes support is addressed in FMJ by wrapping a platform’s native media applications, such as DirectShow, Quicktime and Gstreamer. "That provides support for any major desktop system, uses the native codecs that are available, and achieves native performance," notes Larson. Installation will be simplified by allowing applications to bundle the jars and native libraries together with a desktop application.

The FMJ project has implemented about three-quarters of the original JMF code-base. Unlike Sun’s JMF, the code is released under a modified BSD license that "aims to [en]able use of FMJ in commercial software, while remaining GPL-compatible for projects like GNU classpath," according to the project’s online documentation.

Is the Network Really the Computer?

While Sun has touted the vision of the network as the computer, most users interact directly not with the network, but with a device more or less resembling, well, a computer. "If you believe the network is the computer, then Java on the desktop presents no problems, since Java provides capable UI frameworks now, and has good networking ability," notes Larson. "But if you think that a desktop offers something more than a connection to the network— interaction with cameras, scanners, CD drives, serial and USB ports for communicating with assorted hardware—then there is a problem, since Java generally provides little or no help with a unified API for these [tasks] across all major platforms. JMF has similarly failed to deliver for multimedia."

Larson believes that client-side developers are particularly hurt by Java’s weakness in desktop media support. "Sun's recent efforts on the desktop, while laudable, still fall short of what is needed for a lot of desktop apps. Developers working on desktop applications should be concerned because sooner or later, they will hit one of these limitations." He notes that Windows developers, by contrast, don’t have to contend with such limitations.

The current state of the Java Media Framework is hurting Sun, too. While the last release of Sun’s Java Media Framework dates from May 5, 2003, JMF figures prominently in the company’s nascent efforts into desktop computing. JMF is currently the default media player on Sun’s Java Desktop System—often with unpleasant results. In the July 14, 2005, issue of eWeek Channel Insider, for instance, reviewer Sean Gallagher faults JMF for the Java Desktop System’s poor audio support on Sun’s Sun Ray thin client: "I tested the [thin] clients on my network with a variety of applications that included audio support; the only places where the configuration failed were when JDS's [Java Desktop System] Java media player had to get involved," noted Gallagher in his review, Sun Adds Glamour to Thin Clients. "The media player choked on MP3 and QuickTime files; the MP3 files actually locked up the player, and I had to use the system monitor to kill the Java process and log out to get audio back."

Larson speculates that business and technical reasons both contributed to the Java Media Framework’s lack of recent progress. "Java's stronghold has not been on the desktop... I think Microsoft's dominance there has caused [Sun] to be a bit half-hearted about [desktop Java]. It makes business sense for [Sun] to put the most effort into the areas they can more easily succeed in. In addition, the licensing and legal issues for various codecs probably made things difficult or expensive for [Sun]. The sheer effort of trying to keep up with the latest codecs in pure Java may have proven too much. Finally, maintaining performance packs for a wide variety of platforms was probably also not appealing."

Larson sees an open-source community formed around the Freedom for Media in Java framework to fill these gaps. "This is where the open-source community comes in... If we all chip in, [a high-quality Java media framework] becomes feasible. And if we succeed, we not only have something that matches the ability of a native Windows app [for example], but it may exceed that, because it is cross-platform, and uses a cleaner design with an abstracted API."

A Clean-Room Implementation

Larson believes that, in spite of its problems, JMF provides a good foundation for new Java media efforts. "We don't so much need a new implementation of JMF as some kind of [a] cross-platform, high-performance media API that supports a range of modern platforms and codecs," says Larson. "I chose the JMF API as a starting point because it seemed much easier than starting an entire API from scratch. There are books out there, sample code, projects—although not that many—using JMF. I do expect that we will at some point hit some of the design limitations of JMF, and I am open to the idea of deviating from the standard in order to achieve our goals."

FMJ developers follow the tenets of the GNU Classpath project of not looking at the existing Sun code base prior to implementing a feature, resulting in a clean-room implementation. "It is a bad idea to write free code while looking at someone else's non-free code, since you just create potential legal entanglements for the team and anyone downstream who uses the code.

Do you believe that with better multimedia support, Java on the desktop will gain greater user acceptance?