 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 242: Digital Set Top Box Profile - "On Ramp to OCAP"
JCP version in use: 2.6 Java Specification Participation Agreement version in use: 2.0 Description: The requested specification will define a J2ME profile based on the Connected Limited Device Configuration (CLDC) that is appropriate for use by small-footprint cable television set top boxes. Please direct comments on this JSR to the Spec Lead(s) Team
NOTE: due to changing market circumstances the Spec Lead does not recommend implementing this JSR in its current form. It is expected that an updated JSR will be developed in the future. Updates to the Original JSR The following changes have been made to the JSR proposal since the original submission:
2009.04.02: Maintenance Lead: Donald Bleyl, Cox Communications E-Mail Address: donald.bleyl Telephone Number: -, +49 89 46008 1248 Fax Number: - Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Original Summary: The requested specification will define a Java 2 Micro Edition (J2ME) profile based on the Connected Limited Device Configuration (CLDC) that is appropriate for use by small-footprint cable television set top boxes. Section 1. Identification Submitting Member: Cox Communications Name of Contact Person: Craig Smithpeters E-Mail Address: craig.smithpeters@cox.com Telephone Number: +1 404 269 8263 Fax Number: +1 404 269 8432 Specification Lead: Craig Smithpeters E-Mail Address: craig.smithpeters@cox.com Telephone Number: +1 404 269 8263 Fax Number: +1 404 269 8432 Initial Expert Group Membership:
Cox Communications Supporting this JSR: CableLabs Section 2: Request
2.1 Please describe the proposed Specification:The requested specification will define a Java 2 Platform, Micro Edition (J2ME) profile based on the Connected Limited Device Configuration (CLDC) appropriate for use by small-footprint, cable television set top boxes. The profile will consist of Java 2 APIs for I/O, networking, graphics, etc. appropriate for small-footprint cable television set top boxes and a subset of the Java TV API appropriate for such devices. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)The target Java platform is J2ME CLDC. Implementations of this specification are intended to be downloaded to existing deployed cable set-top boxes. They are not intended to be used in new OCAP-capable boxes, which are expected to support the full OCAP specification ( http://www.opencable.com/specifications). Please see below for an explanation of OCAP. 2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.This JSR is targeted soley at the Java 2 Micro Edition platform. The only relationship to J2SE and J2EE are the core Java langauge constructs and API's. 2.4 Should this JSR be voted on by both Executive Committees?No 2.5 What need of the Java community will be addressed by the proposed specification?The existing Java platforms are generally too large in implementation size and too demanding in functionality to be used with the majority of already-deployed cable television set top boxes in the United States and elsewhere. Java has been growing in acceptance as a programming language for next-generation platforms and interactive television applications. However, there is a pressing market need to identify a Java platform that can be used with less-capable digital cable set top boxes that are currently deployed and will remain in the field for some time. For example, the Motorola DCT 2000 has a very large installed base in the U.S. cable market, but has relatively limited graphics, processing, and memory capacity. Such devices require a more scaled-down Java platform than what has presently been defined. Multiple vendors have explored development of small-footprint Java platforms for use in cable set top boxes; each of these includes a somewhat different Java platform subset and functionality. The proposed specification will define a common API for applications that can be used by all vendors targeting the already-deployed digital cable set top box market. It will also provide a clear path of upward compatibility for content to migrate from the target low-end platform to OCAP (OpenCable Applications Platform, http://www.opencable.com), the Java middleware platform of next-generation North American cable set top boxes. OCAP is related to DVB-MHP (Multimedia Home Platform, http://www.mhp.org), the Java middleware of choice for next generation interactive television (iTV) devices in Europe and elsewhere, by the fact that OCAP and DVB-MHP are both DVB-GEM terminal specifications. DVB-GEM (Globally Executable MHP, http://www.mhp.org/index.php?id=215) is a transport neutral profile of DVB-MHP that can be extended for use by other iTV middleware specifications. The goal of this specification is to create a platform that is as forward compatible as possible with OCAP while still fitting on the most resource constrained of the currently deployed cable television set top boxes that are capable of running J2ME CLDC. 2.6 Why isn't this need met by existing specifications?Existing specifications generally require more implementation size and functionality than is available on the target platforms. The Personal Basis Profile of the Connected Device Configuration plus the Java TV API version 1.0 comes closest to addressing the constraints of such platforms. However, the CDC PBP specification requires more in networking and UI capabilities than is supportable on the currently deployed low-end set top boxes. Likewise, the Java TV API was largely designed to be implemented in the context of emerging digital television broadcast infrastructures, rather than those that are in place today. 2.7 Please give a short description of the underlying technology or technologies:Interactive television allows TV content developers to create procedural content which augments traditional television broadcasts. Potential applications include enhanced television programming, games, electronic commerce, targeted marketing, internet-like connectivity, and improved user control over the display of content. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)TBD. javax.onramp.* has been suggested for the very small number of newly defined APIs. 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No dependencies exist for specific operating systems, CPUs, or I/O devices. However, the profile must be implementable on a very resource constrained set top box such as the DCT-2000 and still have space available for some number of applications. The resource constraints of the DCT-2000 are very limiting. For example, only about 700K of ROM will be available for the profile implementation. This would include 250K for CLDC and 450K for the java.awt and java.net subset, JavaTV subset, OnRamp-specific APIs, and driver support layer. 2.10 Are there any security issues that cannot be addressed by the current security model?The CLDC provided sandbox model is believed to be sufficient. 2.11 Are there any internationalization or localization issues?Subject to the resource constraints of the target hardware, consideration will be given to internationalization and localization since the target platform will likely be deployed in multiple localities. 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No. The proposed specification is intended to meet the requirements of a different target device than what is addressed by existing specifications. 2.13 Please describe the anticipated schedule for the development of this specification.Immediate commencement, completion within 12 months.
The following schedule is preliminary: 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.Periodic face-to-face meetings and teleconferences in addition to regular email exchange. 2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.a) The specification lead will on a quarterly basis provide a brief JSR status to the JCP PMO, for publication to the Java community and public. This will include the current schedule for the JSR and notes on any major events that have occurred in the previous quarter. b) The specification lead will maintain an observer alias for JCP members that are outside of the Expert Group. The specification lead will publish periodic milestone drafts and status reports to the observer list. The Expert Group may also use the list to request feedback on key issues. 2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.The RI and TCK will be delivered as part of this profile work. 2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).N/A 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.As the specification lead, Cox will produce the TCK and RI. Cox will make the TCK and RI available for license separately:
TCK: RI:
- Annual license access fee allowing commercial use of the RI code, as well as providing access to updates and upgrades. Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.Java 2 Platform, Micro Edition ( http://java.sun.com/j2me/index.html) 3.2 Explanation of how these items might be used as a starting point for the work.The resulting profile will be based on J2ME/CLDC and be a subset of the PersonalJava and Java TV APIs present in OCAP. A clear path of upward compatibility from the proposed profile to Personal Basis Profile + Java TV and OCAP/MHP/GEM is a strong requirement. Additional APIs that would hamper such upward compatibility are to be avoided unless suitable alternatives cannot be found. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
