JMF, wherefor art thou?
Little known to most people who've tried to put a JMF application together is the fact that it seems to now be completely unsupported by Sun. Admittedly, it's a tough API to code for. Codecs are almost unanimously covered by restrictive copyright and royalty agreements, and those that Sun could round up to implement require a great deal of processing power (not to mention the interface with the low-level audio and video hardware) to fully utilize, something that isn't really a strong point for the Java language. Yet, despite these roadblocks, the initial reference implementation looks remarkably promising... and that's where it all goes down-hill.
The remarkable ease and usability of the initial implementation gets you interested. The implementation, especially for a very limited and specific set of codecs, hardware and other intricacies, works beautifully. As there is no obvious indication that the API is no longer really supported by sun, it's also easy to believe that the next version, whenever it comes out, will have that one extra feature that you are looking for.
Reading the JMF-INTEREST mailing list show how many have fallen into this trap. If you've got a six-month project, and you only need one small addition, or one small bug-fix to JMF to complete it on time, it's fairly easy to assume that by the time the release date comes around, you'll have the next release of JMF and will be ready to go.
The next release is not coming. From the chatter on the list it has become more and more obvious that Sun has quietly abandoned JMF, but isn't willing to let the general population know about it.
Well, that's fine, because Sun's reference implementation of JMF is just that, a reference implementation... somebody out there has to be writing a commercial-quality implementation of the spec, right? Well, ignoring the fact that people are perfectly happy to use the reference implementations of Java APIs in production environments (Tomcat, for example), the answer is no... There are currently no implementations that I (or anyone I've asked, including Senor Google) am aware of.
Why is that? Well, it's just pure speculation on my part, but I'd say that's because Sun's RI does too good a job for you before you discover that it fails. If your software company were to begin the project of writing a full-scale implementation, the first thing you'd do is look at your competition, namely Sun's JMF. You'd see that it looks, from the quick, once-over perspective, to be fully functional. It'd appear to you to be a long and unpleasant road ahead of you to â€œbeatâ€ the freely available RI. This is especially true if you were led to believe that JMF is under active development, a misconception that's very easy to believe if you're just casually looking into JMF. There's not a great deal of incentive to ever start down that road, so you'd back off and turn to more fruitful options.
At this point Sun really needs to consider taking action. Either they need to begin active development on the RI again, or they need to come out, officially, and tell the world that they have dropped support for JMF's Reference Implementation. They could sit on the code, or present it to the Open Source community for further development.
Either way, an open statement to the demise of the implementation would do a world of good for everyone involved. It would let people know, before they ever get the idea in thier head, to be wary of complicated Java-based multimedia projects using JMF. It would allow either the open source community or private commercial entities to take up the torch and begin developing true JMF implementations of thier own without having to fear "competition" from Sun.
So, how about it, Sun? Where is JMF going from here?