Cable provider Cox Cmmunications has submitted Java Specification Request 242, Digital Set Top Box Profile to the Java Community Process. (JCP). "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." We've finally come full circle.
Sun has submitted JSR 243, Java Data Objects 2.0 - An Extension to the JDO specification, to the JCP. According to the JSR,
The JDO API was released in spring of 2002 and had one maintenance release late in 2003. The initial release provided a database abstraction that permitted API access to datastores without detailed knowledge of the underlying datastore API.
This technology has been used to develop implementations for file storage and relational and object databases. Over a dozen commercial implementations have been developed to date. Additionally, the technology has been exploited to develop EJB Container Managed Persistence (CMP) for application servers.
Features to be added to the JDO specification include:
- Relational Database Mapping:
- The programmer's view of the datastore hides the details of the underlying datastore, which is attractive but leads to some issues. Different JDO vendors have implemented mappings to relational databases differently, and the mappings are not portable among vendors. This JSR will address a common mapping format to allow a higher degree of portability of applications.
- Disconnected operation:
- A primary use-case for JDO is in a middle tier of a multi-tier architecture. Rich clients (http clients running applets, web services clients, and ORB clients) may wish to extract a subset of values from the database in a structured (domain model) format, and update this information. Once updated, the information is sent back to a middle tier, where the changes are applied to the datastore. This JSR will address the APIs in the middle tier to facilitate this use-case.
- Broaden the range of implementations:
- Certain JDO 1.0 specification restrictions reduce the acceptance of the API by potential JDO vendors. Limitations include a requirement for binary compatibility to the Reference Enhancement contract and a requirement that only classes, not interfaces, can be persistent. This JSR will address these limitations. Alignment with J2EE:
- While the JDO technology is suitable as a component in the J2EE architecture, certain services are required from the server that are not currently standardized. Part of this JSR will recommend standard APIs to provide these services. Part of this alignment will specify the portable behavior of transaction completion in the web and ejb containers.
- Extensions to JDO queries:
- JDOQL provides a standard way to access persistent instances based on values and relationships, but is limited in what can be returned as the result. This JSR will extend the range of return values to include projected fields, collections of instances identified in navigational expressions, and aggregate data such as MIN, MAX, SUM, AVG, and COUNT. Additional methods will be defined to perform string manipulations in filters.
- Relationships:
- The JDO object model does not specify bidirectional or composition relationships among object classes. This JSR will consider issues regarding managed bidirectional relationships and composition relationships including cascade delete semantics.
- Maximize JDO backward compatibility:
- Many applications and deployments have significant investments in the JDO technology. Any improvements to the API will attempt to maintain backward compatibility to all previous JDO specifications.
- Minor usability features:
- A number of usability features will be considered, based on feedback from user discussions on sites such as TheServerSide and JDOCentral.