If, as reported, entertainment giant Paramount throws its weight behind the Blu-ray high-definition DVD format it would seem like a vote in favor of using Java (Sun PDF here) in digital TV entertainment.
While for some this might not seem and obvious association and might be considered a completely new departure for Java by many more, digital TV is actually very close to the origins of Java.
With the Consumer Electronics Show in Las Vegas, Nevada, I plan to look at the underpinnings of digital TV, its relationship to Java, the problems that DTV has and how - by looking to the enterprise world - Java may help over come them.
Looking back, to the origins of Java, you will find that having built a hand-held device - *7 or Star Seven - the Java development team (or rather at that time, the Oak development team) looked around for other applications for their new baby.
One of the main suggestions was to use it in TV set-top boxes (STBs). However, back in the early 90s the TV industry (both satellite and cable) was too young and embryonic to see a need for Java on the STB, so this idea died an early death. Java of course didn't, and went onto to become the success that it is now.
The idea didn't completely go away, though, while TV standards themselves have come a long way since those early days. Within the world of digital TV the Digital Video Broadcasting project (DVB) is one of the key players. This is a consortium of more than 270 organizations in 35 plus countries that have defined a host of standards. These standards include:
MHEG-5: is part of a set of international standards relating to multimedia presentations. In the UK and New Zealand it is the digital TV standard and is used with Freeview. MHEG-5 is a declarative language focussing on the presentation of text, image and video content.
MHEG-6: This was an aborted attempt to extend MHEG-5 to include Java. In this model Java applications could manipulate MHEG-5.
MHP: The Multimedia Home Platform (or MHP) is an open standard originally created by the DVB project for digital broadcasting. MHP is oriented around Java and applications are either written in Java (and called Xlets) or HTML. However, although it is being adopted in many Europe countries, MHP has not been adopted in the UK.
From the Java Community Process (JCP), meanwhile, we have Java TV API 1.1 or JSR 927. Java TV API 1.1 is a Java specification specifically oriented around digital TV. The core element of the Java TV API is an Xlet - that you may note was mentioned in the section on MHP. Indeed, all of the Java TV APIs are included in MHP. So what's the difference? Well MHP is based on the DVB project's other standards and as such is rather more tied to the underlying technologies. In contrast Java TV does not make such assumptions and describes the necessary lower-level services in terms of generic interfaces - as you might expect. Thus, Java TV can run on a wider variety of platforms.
The end result is we have a wide range of software specifications, development environments and technologies. Notice that so far we haven't even touched on the prickly subject of hardware. Thanks to the continuing pace of innovation, hardware now stretches beyond the traditional STBs to include mobile phones and PCs among other systems, with a wide range of chip sets.
Even with a language that promotes the ability to write once and run anywhere, such as Java, we are still left with a plethora of confusing acronyms and development frameworks. This reminds me of the old enterprise development world where each platform, each language and each vendor had their own competing standards.
Integration between one environment and another was unheard of, except via bespoke - and expensive - development projects. Even those attempts at create integrated environments that did succeed were expensive, clumsy and generally hard work.
Looking at all of these one can't help but wonder whether the digital TV and STB world, especially given the format wars, isn't making the same mistakes as the enterprise made a decade ago.
Surely we can learn from what has been done there. For example, could we not have a set of language-independent standards that define a set of services that a digital broadcaster works to? Using these services different implementation languages could plug into these services via a language-independent interface.
Of course, the GUI on the STB or PC or whatever device is running the client side of the broadcast would be implemented in the favored language - that could be Java or whatever - but that would then be independent of the broadcast side of things.
This would immediately remove many of the barriers to entry, the maintenance costs and the incompatibility issues that are the subject of huge amounts investment by the industry intended to overcome these issues.
All of this brings me back to "simplicity". Recently, I have argued that simplicity in software should be paramount and I think that within the DTB field this is no less true. Lessons should be, and can be learned, from the older - and arguably more mature - enterprise world.
These can be both from an architectural point of view - such as a DTB version of SOA - through platform- and language-independent transport mechanisms - the STB equivalent of SOAP/HTTP - through to the APIs themselves.
It won't be easy, as Java itself has shown with Java 2 Micro Edition (J2ME) and its many sub specifications for different types of resource limited devices. However, it is a goal worth pursuing.®