Java TV is a Java-based software framework designed for use on TV set-top boxes, based on components called Xlets. It is currently used only on the Connected Device Configuration, specifically for iTV applications development.

The API includes the Xlet classes in the package javax.tv.xlet. Other packages of the public API include

  1. javax.tv.graphics - provides a simple rendering canvas
  2. javax.tv.locator - provides a locator in the style of a URL for services and media, such as service:/SERV1
  3. javax.tv.service - defines a mechanism for service information (SI) databases and APIs representing the SI elements, such as the TV channels and media available for playback.

Criticisms edit

While the framework is general, Sun currently provides support only on Java ME. For some subjects, such as media locators, it is in effect superseded by other locator standards on platforms such as BD-J.

A point of confusion is that in platforms supported as of 2008, examples such as the SvcDispXlet example from the introduction to the API, written circa 2001, are not deployable because it uses AWT widgets such as java.awt.Button. Most iTV platforms, along with BD-J, implement Personal Basis Profile with no AWT widgets, as opposed to Personal Profile which includes the widgets.[1]

Sun's reference implementation for Java TV attempts to limit its exposure to support issues to the full Java Media Framework by having its own small version of JMF that is internally referred to as "jmflite". As with the limitations of the MIDP emulators that Sun provides, the Java TV reference implementation provided by Sun has not been updated to make provisions for later JDK's such as removing calls to Thread.stop(). The Thread.stop() method was made a "final" method in Java 1.5 (meaning that classes which extend Thread and override stop() will fail at runtime under JRE 1.5 when the class is loaded). This implies that Sun has not yet committed to public plans or a roadmap for taking Java ME beyond JRE 1.3. If such an upgrade were to take place, it would require significant work on the part of all vendors of Java ME-enabled devices.[2][3]

See also edit

External links edit

References edit