The Java Community Process(SM) Program - JSRs: Java Specification Requests

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy

JSR

Community

Expert Group

Summary | Proposal | Detail (Summary & Proposal)

JSRs: Java Specification Requests

JSR 235: Service Data Objects

Updates to the Original JSR

The following information has been updated from the original proposal.

2007.12.20:

Specification Leads: Radu Preotiuc-Prieto, Kelvin Goodson

E-Mail Address: radup@bea.com, kelvin_goodson@uk.ibm.com

Telephone Number: +1 425 896 4116, +44 1962 818178

Fax Number: +1 206 675 8250, -

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: BEA Systems, Inc. and IBM Corporation

Name of Contact Person: Rahul Patel & Mike Edwards

E-Mail Address: rahulp@bea.com & mike_edwards@uk.ibm.com

Telephone Number: +1 408 570 8720 & +44 1962 818014

Fax Number: +1 415 402 7213 & +44 1962 818999

Specification Lead: Rahul Patel & Stephen Brodsky

E-Mail Address: rahulp@bea.com & sbrodsky@us.ibm.com

Telephone Number: +1 408 570 8720 & 1 408 463 5659

Fax Number: +1 415 402 7213 & 1 408 463 3873

Initial Expert Group Membership:

BEA Systems, Inc.
IBM Corp.

Supporting this JSR:

BEA Systems, Inc.
IBM Corp.

Section 2: Request

2.1 Please describe the proposed Specification:

This specification will define core infrastructure APIs for heterogeneous data access that supports common application patterns and supports higher-level tools and frameworks.

An established best-practice in J2EE programming is encapsulating business data passed between tiers of an n-tier application in a by-value Java object that is independent of the technologies used to implement the tiers (note that these tiers are sometimes purely logical - that is, in the same Java VM). [1] [2] [3] [5] [7] This pattern, called "Data Transfer Object" [1] [5] [7] and "Transfer Object" [2] [3], will be called Service Data Objects (SDOs) here. SDOs are used in several standard patterns.

In simple scenarios, Service Data Objects can be implemented simply by defining a straightforward Java class. However, supporting more sophisticated scenarios can be very challenging and requires more than a simple JavaBean-based approach. This proposed specification for Service Data Objects addresses a range of more sophisticated scenarios:

1. Change History.
It is a common pattern for a client to receive an SDO from another tier, make updates to the SDO, and then pass the modified SDO back to the other tier. To support this scenario, it is often important for the tier receiving the modified SDO to know what modifications were made. In simple cases, knowing whether or not the SDO was modified may be enough. For other cases, it may be necessary (or at least desirable) to know which fields (or bean properties) were modified. Some standard optimistic collision detection algorithms require knowledge not only of which columns changed, but also what the previous values were. Service Data Objects will support full change history.

2. Compound Data Objects.
It is common to have to deal with "complex" or "compound" Data Objects. This is the case where the SDO is the root of a tree, or even a graph of objects. An example of a tree would be a SDO for an Order that has references to other SDOs for the Line Items. If each of the Line Items had a reference to a SDO for Product Descriptions, the set of objects would form a graph. When dealing with compound data objects, the change history is significantly harder to implement because inserts, deletes, adds and removes, and reordering have to be tracked as well as simple changes. Service Data Objects will support arbitrary graphs of SDOs with full change summaries.

3. Navigation
An important aspect of SDO is the ability to navigate from one SDO to another by API or by expression. Within a graph of SDOs, all objects are reachable by successive API calls or by constructing and processing a path expression. SDO supports navigation between data objects using a path expression subset of the XPath 1 [8] specification.

4. Dynamic APIs, with support for generated APIs
SDOs will commonly have typed Java interfaces (i.e., the common JavaBeans that application programmers are familiar with). However, sometimes it is either impossible or undesirable to create Java interfaces to represent the SDOs. One common situation in which this occurs is where the data being transferred is defined by the output of a query. Examples would be a relational query against a relational persistence store, or EJBQL queries against an EJB entity bean domain model, or XML Query queries against an XML source. In these situations, it is necessary to use a dynamic store and associated API. One simple approach in these situations is to use an implementation of java.util.Map [2]. However, this implementation does not provide any change history (see above), meta-data (see below), validation and constraints (see below) or relationship integrity (see below). Service Data Objects will have the ability to represent SDOs through a standard dynamic API without the need to generate Java classes. Dynamic SDO classes will support the full meta-data, validation and relationship integrity features of code-generated SDO classes. SDO can also be used in conjunction with systems that generate static Java APIs, such as class generated by JAXB from an XML Schema Definition. The generated implementation classes will then support both the familiar JavaBeans interface as well as the dynamic APIs.

5. Meta-Data
Many applications are coded with built-in knowledge of the shape of the data being returned. These applications know which methods to call or fields to access on the Service Data Objects they use. However, in order to enable development of generic or framework code that works with SDOs, it is important to be able to "introspect" to retrieve metadata for these objects. If the SDOs are implemented using Java classes, normal Java introspection will return basic information about fields, methods or Java Bean properties. However, Java introspection will not return information about the expected types of objects in collections, containment, inverse relationships, or constraints. It is very desirable to have this extended metadata. Service Data Objects will support simple meta-data that describes types, their attributes, their relationships, containment, multiplicity, sequences, use of settings in properties, and constraints. This metadata can be populated from various metadata models, such as XML Schema [10], the Essential Meta Object Facility (EMOF) [9], etc.

6. Faithfully represent the semantics of business data without exposing the details of underlying storage technology.
It is an accepted best practice that the client should not be exposed to the implementation technologies used by the provider. For example, a data persistence tier should not expose to the client whether the underlying persistence technology is a relational database, an XML database, an OO database, files, or a set of interactions with an Enterprise Information System. The interface to the persistence layer should expose all the semantics of the underlying business data without loss. Service Data Objects will use only technology-neutral data-types and other technology-neutral meta-data concepts while supporting data semantics rich enough to cover relational data, XML data, EJB data, JCA data and other popular data representations.

7. Support for XML, XML Schema and Web Services
The content of XML data is more complex from that of relational data and object data. For instance, XML data includes the properties of order of elements, and content models can allow "mixed content". The SDO model will support the necessary concepts from XML to be able to represent XML data. This will enable Web services messages to be accessible using SDOs (i.e., Web services messages can be viewed as serializations of SDOs). The SDO meta-data API will also support a small and simple client view of the schema language underlying the XML (e.g., W3C XML Schema). This will allow SDO to be integrated with other Java-XML technologies, such as XML-Java data binding solutions (e.g., JAXB) and Java-based Web services (e.g., JAX-RPC). Note that this specification does not define integration with these technologies. Rather, the goal of this specification is to enable these integrations for the future.

8. Import/generation from popular interface definition formats
In order to support implementation of objects that support data transfer between tiers, it is necessary to be able to create definitions of data transfer objects from the popular interface technologies of each of those tiers. This includes WSDL/XML Schema as discussed above, EJB entity beans, relational database schemas, JCA connectors, JMS message formats etc. In addition, import from design descriptions such as UML is desirable. Service Data Objects will support import of Service Data Object definitions from popular formats. Note that this specification does not define the import mechanisms itself; this will be left up to implementations and possibly future specifications.

9. Validation and Constraints
When representing data exchanged with a tier, it is important not to lose information about the semantics of that data. When SDOs are implemented directly as Java objects, basic type information can be preserved. This information is lost with java.util.Map implementations. In addition to basic type information, for both static and dynamic implementations, it is important to preserve and enforce information about other constraints. Examples are information about maximum String lengths (e.g. for properties corresponding to columns in a relational database table), or constraints on value ranges (e.g. for properties whose types are defined by XML Schema simple type restrictions). Service Data Objects will support a set of standard constraints designed to support the popular constraints expressible in relational databases and XML schema, and will also provide an extensible mechanism for adding new constraint types as well as validation capability for those constraints.

10. Relationship integrity
An important special case of constraints is the ability to define relationships between objects and to enforce the integrity of those constraints, including cardinality, ownership semantics and inverses. For example, consider the case where an employee has a relationship to its department and a department inversely has a list of its employees. If the value of the department is set for an employee, the employee should be automatically removed from the list of employees held by the department it is currently in, and the employee should be added to the list of employees for the new department. Service Data Object relationships use regular Java objects as opposed to primary and foreign keys with external relationships. Support for containment tree integrity is also important.

11. Integration with presentation-tier technologies
One of the important scenarios for SDOs is passing data between a presentation tier and a business logic tier. In order to be useful with standard J2EE presentation tier technologies such as JSTL and JSF, without copying or creation of wrappers, the Service Data Objects specification will have as its goal good integration with these technologies.

12. Serialization
The Java serialization of SDOs should have an on the wire format independent of implementation for interoperability. Service Data Objects will follow an XML serialization format and implementation classes will implement the java.io.Serializable interface. Relationships to other JSRs:

JSR 12 JDO
JDO is a way of transparently persisting JavaBeans. SDO is a way of representing data that is received from or sent to a "service" or "tier", especially but not exclusively a data persistence "tier". SDO could be used to pass data back and forth between a JDO-based persistence tier and a business logic tier or presentation tier

JSR 31 JAXB 1.0
JSR 222 JAXB 2.0
The SDO specification defines dynamic data APIs and metadata APIs; it does not define static Java interfaces for XML Schema. Thus, SDO could be used in conjunction with JAXB.

JSR 40 - JMI
The JMI 1.0 specification defines Java APIs for the OMG MOF 1.4 specification, which provides a comprehensive object-based metadata model. The SDO specification creates a very small metadata model designed specifically for common use cases that clients applications need. We expect that other metadata models, such as MOF, XML Schema, etc. can be used by data mediator services.

JSR 114 - RowSet Implementations
JSR-114 provides a type of JDBC RowSet called CachedRowSet that provides a disconnected model of data access for relational data. While both CachedRowSet and SDO support the disconnected model, SDO is meant for data from heterogeneous sources, not just relational data sources. In particular, RowSet, and CachedRowSet, have the following limitations that make it unsuitable for the use cases SDO is addressing: * Lets underlying relational persistence concepts show through o SQL types o Relational organization (rows) o JDBC-specific meta-data * Mixes multiple different roles in a single object (Data Transfer Object/SDO, Data Access Object/DMS, Iterator) * Does not support and is not easily extended to other data sources such as XML, JCA, EJBs etc. * Does not naturally support generation of statically-typed Java classes for accessing data * Cannot be easily used directly with JSTL or JSF * Does not directly support containment, object relationships, and inverses.

JSR-227 -- A Standard Data Binding & Data Access Facility for J2EE JSR-227 proposes a facility to declaratively bind Web user interface components to heterogeneous back-end data sources. For example, JavaServer Faces components (e.g., a grid component) could be bound to relational data or XML data from a Web service. The SDO specification provides the lower-level primitives that could be used by JSR-227. [1] EJB Design Patterns: Advanced Patterns, Processes, and Idioms, by Floyd Marinescu, 2002. [2] Core J2EE Patterns, Best Practices and Design Strategies, second edition, by Deepak Alur, John Crupi, Dan Malks, 2003. [3] Core J2EE Patterns Transfer Object http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html [4] Core J2EE Patterns Data Access Object http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html [5] Patterns of Enterprise Application Architecture, by Martin Fowler 2003. Data Transfer Object Pattern http://www.martinfowler.com/eaaCatalog/dataTransferObject.html [6] Patterns of Enterprise Application Architecture, by Martin Fowler 2003. Remote Facade Pattern http://www.martinfowler.com/eaaCatalog/remoteFacade.html [7] Enterprise Solution Patterns, Data Transfer Object http://msdn.microsoft.com/practices/type/Patterns/Enterprise/DesDTO [8] XPath 1.0 specification http://www.w3.org/TR/xpath [9] EMOF compliance point from Meta Object Facility 2.0 Core Final Submission, http://www.omg.org/cgi-bin/doc?ad/2003-04-07 [10] OMG MOF 2.0 XMI specification http://www.omg.org/docs/ad/03-04-04.pdf [11] XML Schema part 1: Structures, http://www.w3.org/TR/xmlschema-1

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

Java 2 Standard Edition

2.3 What need of the Java community will be addressed by the proposed specification?

Data Transfer Objects are an established J2EE application development pattern. The Service Data Objects proposed specification standardizes Data Objects in terms of change history, compound data objects, dynamic and generated API, meta-data, support for XML and Web Services, neutral representation of business data, import/export from common formats, validation and constraints, relationship integrity, and navigation.

2.4 Why isn't this need met by existing specifications?

This area of technology is not covered by existing standards.

2.5 Please give a short description of the underlying technology or technologies:

This is described in section 2.1.

2.6 Is there a proposed package name for the API Specification? (i.e., `javapi.something`, `org.something`, etc.)

javax.sdo

2.7 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

2.8 Are there any security issues that cannot be addressed by the current security model?

2.9 Are there any internationalization or localization issues?

2.10 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

2.11 Please describe the anticipated schedule for the development of this specification.

This specification timeframe should allow possible inclusion in the Java 1.6 Standard Edition.

Winter 2003: Expert Group Formed
Early Summer 2004: Release Community Draft
Late Summer 2004: Release Public Review Draft
Fall 2004: Final Release

2.12 Please describe the anticipated working model for the Expert Group working on developing this specification.

IBM will lead the specification and implementation work, with experts contributing to the API specification.
This will include email discussions, monthly phone calls and possibly a F2F meeting. The environment of the expert group will be totally non-confidential. We will also use or create an open mailing list for discussions by other interested people outside the expert group. As the outbound licenses will be royalty free (see section 2.15), expert group members will need to ensure that their contributions are similarly made on that basis. Non-EG contributors to the mailing list will also be requested to provide that assurance.

2.13 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 made available in stand-alone form at the time of the final release. There will most likely be earlier versions of the RI and TCK that are developed as this JSR progresses.

The RI will be generic to any particular container and not use any proprietary interfaces, and therefore should work with existing container implementations.

IBM will be responsible for developing the TCK, although contributions from any Expert Group member would be welcome.
BEA will be responsible for developing the RI, although assistance from any Expert Group member would be welcome.

2.14 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).

Not applicable.

2.15 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

The Specification will be offered under royalty-free terms and thus be freely implementable. This license will comply with the terms defined by the JSPA. For an approximation of the Specification license, please see the license statements included in the specifications listed in section 3.1.

The intention is to release the RI and TCK under licenses of a form of the draft licenses included as Exhibit A and Exhibit B in section 4.1, respectively. At this stage it is expected that IBM and BEA will strive to use a common license for the RI and similarly for the TCK.

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.

The following specification will serve as input into the expert group:
http://dev2dev.beasys.com/technologies/commonj/sdo/index.jsp
http://www.ibm.com/developerworks/library/j-commonj-sdowmt/

3.2 Explanation of how these items might be used as a starting point for the work.

This specification will serve as a starting point for expert group discussion.

Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.

Exhibit A
Reference Implementation License

BY DOWNLOADING OR USING THE SOFTWARE AND/OR DOCUMENTATION DESCRIBED IN EXHIBIT A HERETO (COLLECTIVELY THE "SOFTWARE"), YOU AGREE TO THE FOLLOWING TERMS AND CONDITIONS ("AGREEMENT"). IF YOU DO NOT AGREE TO THE TERMS AND CONDITIONS OF THIS AGREEMENT, YOU MAY NOT DOWNLOAD OR USE THE SOFTWARE.

License Grant. International Business Machines Corporation or one of its subsidiaries collectively ("IBM") hereby grants you (an individual or an entity) a non-exclusive, non-transferable, worldwide, royalty free license to modify and prepare derivative works of the Software and to use, reproduce, distribute object code versions of, display, and perform the Software and such derivative works. The above license includes the right to sublicense the above rights to third parties acting on your behalf. To the extent IBM provides you with error corrections, upgrades, enhancements, additions, improvements, extension or other modifications to the Software such error corrections, upgrades, enhancements, additions, improvements, extension or other modifications shall be considered Software and shall be subject to the terms and conditions of this Agreement.
You agree not to remove any of the copyright statements or disclaimers contained in the Software. You agree to defend, indemnify, hold harmless IBM and its suppliers from and against any claims, lawsuits, demands, liabilities, damages, costs and expenses including, without limitation, attorney fees, in any way related to, connected with, or arising out of, your use, modification, reproduction, distribution and/or sublicensing of the Software.

Compatibility Claims. You agree that you will distribute, or sublicense others to distribute, the Software and derivative works thereof only if you or such third party have tested the Software and derivative works thereof with the applicable JSR __ TCK and such Software and derivative work have complied with the relevant portions of such TCK. You may not claim that the Software or derivative works thereof pass the applicable TCK, and therefore is compatible with the applicable JSR __ specification, unless it is capable of passing the most current version of the TCK available 120 days prior to the date of shipment. You will make available information regarding the version of the TCK passed, upon request. Additional rules, if any, regarding your ability to make claims regarding your use of the TCK or any result there from can be found at __________________. As a condition to your license, you agree to abide by all such rules.

Support. Although IBM may try to answer technical support questions you may have regarding your use of the Software, IBM has no obligation to provide error corrections, upgrades, enhancements, additions, improvements, extension or other modifications to the Software or to provide any end user or technical support for the Software. You shall be responsible for any and all maintenance, end-user support and technical support with respect to the Software.

No Warranties. THE SOFTWARE AND ANY SUPPORT ARE PROVIDED "AS IS" WITHOUT WARRANTY OR CONDITION OF ANY KIND EITHER EXPRESS, IMPLIED, OR STATUTORY, INCLUDING, BUT NOT LIMITED TO, ANY IMPLIED WARRANTIES OR CONDITIONS OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. ALL WARRANTIES AND CONDITIONS, EXPRESS, IMPLIED, AND STATUTORY ARE HEREBY DISLCAIMED. THE ENTIRE RISK ARISING OUT OF THE USE OR PERFORMANCE OF THE SOFTWARE AND SUPPORT REMAINS WITH YOU.
No Liability. IN NO EVENT WILL IBM OR ITS SUPPLIERS BE LIABLE FOR ANY LOST PROFITS, LOST SAVINGS, LOST REVENUE, LOST DATA, PROCUREMENT OF SUBSTITUE GOODS, OR FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, PUNITIVE, OR CONSEQUENTIAL DAMAGES, EVEN IF IBM OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH LOSSES OR DAMAGES. IN ADDITION IBM AND ITS SUPPLIERS WILL NOT BE LIABLE FOR ANY DAMAGES CLAIMED BY YOU BASED ON ANY THIRD PARTY CLAIM.

Some jurisdictions do not allow the exclusion of implied warranties, or the limitation for consequential damages, so the above may not apply to you.
Note to U.S. Government Users - Documentation related to Restricted Rights - Use, duplication, or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corporation.

Covenant Not to Assert. To the extent that you have any patents which cover the use of the Software in any manner permitted under this Agreement, you hereby agree not to assert any such patents against the developers or distributors of the Software or any other parties who have entered into a license substantially similar to this Agreement for the licensed use of the Software.
Reciprocity. You may have, or may have in the future, the ability to reference implementations developed or distributed pursuant to the Java Community Process ("Java Materials"). You acknowledge that under this license you are receiving the Software under reasonable royalty-free terms. While you are not obligated to make Java materials available, if you do so and do not license them under reasonable royalty-free terms, the licensor reserves the right to revoke this license upon reasonable notice. In the event this occurs, the licensor will make available to you a substitute license under commercial terms, including possibly royalties and other restrictions. For the purpose of this paragraph, terms are not reasonable terms if they are more restrictive than this license or if they discriminate against any individual or group of JCP members or against implementers of independent implementations or open source implementations.

General.

You agree to comply with applicable export laws and regulations.

No other rights or licenses are granted by implication, estoppel or otherwise.

If any provision of this Agreement is invalid or unenforceable under applicable law, it shall not affect the validity or enforceability of the remainder of the terms of this Agreement, and without further action by the parties hereto, such provision shall be reformed to the minimum extent necessary to make such provision valid and enforceable.

Your rights under this Agreement shall terminate if you fail to comply with any of the material terms or conditions of this Agreement and do not cure such failure in a reasonable period of time after becoming aware of such noncompliance. If all your rights under this Agreement terminate, you agree to cease use of the Software immediately.

This Agreement is governed by the laws of the State of New York and the intellectual property laws of the United States of America. No party to this Agreement will bring a legal action under this Agreement more than one year after the cause of action arose. Each party waives its rights to a jury trial in any resulting litigation.

This Agreement is the only understanding and agreement we have with respect to the Software. It supersedes all other communications, understandings or agreements (oral or written) that we may have had with respect to the Software prior to this Agreement. Only a written agreement signed by both of us can modify this Agreement.

Exhibit B

Technology Compatibility Kit License Agreement

License Grant. You are hereby granted a personal, non-transferable and non-sublicenseable, nonexclusive, world-wide, royalty free license to use the JSR __ Technology Compatibility Kit (including software and documentation) (the "TCK") solely for the purpose of testing compliance with the relevant portions of specifications or standards to which it applies (the "Specification"). You may not modify or create derivative works of any of the TCK except as is necessary to fulfill the purpose described above. You may not distribute copies of the TCK to other parties for any purpose, including for the purpose of allowing such other party to use the TCK. Nor may you modify or incorporate the TCK into any other software.
No Warranties. The TCK contained herein is provided on an "AS IS" basis and to the maximum extent permitted by applicable law, this material is provided AS IS AND WITH ALL FAULTS, and the developers of this material hereby disclaim all other warranties and conditions, either express, implied or statutory, including, but not limited to, any (if any) implied warranties, duties or conditions of merchantability, of fitness for a particular purpose, of accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION, CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT WITH REGARD TO THIS MATERIAL.

Limitation of Liability. IN NO EVENT WILL ANY AUTHOR, DEVELOPER, LICENSOR, OR DISTRIBUTOR OF THIS MATERIAL BE LIABLE TO ANY OTHER PARTY FOR THE COST OF PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL, CONSEQUENTIAL, DIRECT, INDIRECT, PUNITIVE, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS MATERIAL, WHETHER OR NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.

Covenant Not to Assert. As a material condition to this license you hereby agree, to the extent that you have any patents which cover the use of the TCK in any manner permitted under this License, not to assert any such patents against the developers or distributors of the TCK or any other parties who have entered into a license substantially similar to this License for the licensed use of the TCK.
Reciprocity. You may have, or may have in the future, the ability to license specifications and/or test suites developed or distributed pursuant to the Java Community Process ("Java Materials"). You acknowledge that under this license you are receiving the TCK under reasonable royalty-free terms. While you are not obligated to make Java Materials available, if you do so and do not license them under reasonable royalty-free terms, the licensor reserves the right to revoke this license upon reasonable notice. In the event this occurs, the licensor will make available to you a substitute license under commercial terms, including possibly royalties and other restrictions. For the purpose of this paragraph, terms are not reasonable terms if they are more restrictive than this license or if they discriminate against any individual or group of JCP members or against implementers of independent implementations or open source implementations.
Compatibility Claims. You may not claim that any version or release of software passes the TCK, and therefore is compatible with the Specification, unless it is capable of passing the most current version of the TCK available 120 days prior to the date of its first shipment to customers. You will make available information regarding the version of the TCK passed, upon request. You agree that any claims regarding compliance with the Specification will be factually accurate and will not be misleading.

General.
No other rights are granted by implication, estoppel or otherwise.

Your rights under this Agreement shall terminate if you fail to comply with any of the material terms or conditions of this Agreement and do not cure such failure in a reasonable period of time after becoming aware of such noncompliance. If your rights under this Agreement terminate, you agree to cease use of the TCK immediately and cease making any claims of compatibility regarding the Specification based on the use of the TCK.

Exhibit C

NOTE: participants in this expert group must sign a supplemental license agreement to enable an external specification, which has already been published with royalty free patent grants for essential claims, to remain in sync with any enhancements done by the expert group while the expert group completes its work. To that end, the supplemental agreement changes the timing of some of the IP grants that EG members must make. The agreement may be downloaded here.