More generic and technical examples of which extensions are allowed and not allowed

Developers have asked for clarifications with respect to what and how the OSS through Java^TM specifications can be enhanced or extended. The OSS through Java^TM specifications were developed under the Java Community Process and are subject to the terms of the Specification License included with the specification(s). In order to facilitate further development and contributions to OSS through Java^TM the following clarifications are provided.

The Java platform is defined for the most part in the packages 'java' and 'javax'. The OSS through Java^TM APIs, for example, are at least mostly defined in the 'javax.oss' package. Additional proprietary or product APIs that are not normally included in the Java platform are strongly encouraged to be defined according to the "reverse domain" naming convention outlined in The Java Language Specification. For instance, a product written in the Java programming language by company <vendor> might use some subpackage of the 'com.<vendor>' package.

The goal of the restrictions against subsetting, supersetting, and modification is to ensure that all implementations of the platform are compatible, and in particular that with respect to the platform namespace they contain the public API their spec defines, no more and no less.

In the case of OSS through Java^TM APIs, the word 'platform' above shall be understood as the original core specifications which are all defined under javax.oss.

Examples of a disallowed OSS through Java^TM APIs subsetting:

Deleting any public subpackages, classes, or interfaces defined in the 'java' or 'javax' packages (e.g. deleting the package 'java.util', 'javax.oss.order' or the class 'java.lang.Thread')
Deleting any public or protected methods or variables defined by classes or interfaces in the 'java' or 'javax' packages (e.g. deleting the method 'java.lang.Thread.stop()')

Examples of deletions that are not OSS through Java^TM APIs subsetting:

Deleting a subpackage, class, or interface from a 'com.<vendor>' package if you work at <vendor> or are authorized by <vendor> to do so.
Deleting a subpackage, class, or interface from a 'com.<vendor>' package if you don't work at <vendor> or aren't authorized by <vendor> to do so.
Deleting a method or variable from a class or interface in a 'com.<vendor>' package if you work at <vendor> or are authorized by <vendor> to do so.
Deleting a subpackage, class, or interface from a 'com.<vendor>' package if you don't work at <vendor> or aren't authorized by <vendor> to do so.

Examples of disallowed OSS through Java^TM APIs supersetting:

Adding any public subpackages, classes, or interfaces to those defined in the 'java' or 'javax' packages (e.g. adding a package 'javax.wombat', 'javax.oss.wombat' or a class 'javax.oss.order.Wombat')
Adding any public or protected methods or variables to those defined by classes or interfaces in the 'java' or 'javax' packages (e.g. adding a method 'java.lang.Thread.wombat()')

OSS through Java^TM APIs Extensions, as the term is being used here, are additions that do not superset the platform because they stay out of the name space in which the platform is defined. Note that while platform extensions are not platform supersets, they still might be constrained by other industry conventions.

Examples of valid OSS through Java^TM APIs Extensions:

Adding a subpackage, class, or interface to a 'com.<vendor>' package

[You should have permission from <vendor> to add packages that the reverse domain naming convention defines as being in <vendor>'s name space.]

Adding a method or variable to a class or interface in the 'com.<vendor>' package

[You should have permission from <vendor> to extend packages that the reverse domain naming convention defines as being in <vendor>'s name space.]

Creating a public top-level package 'wombat'
[Breaks the reverse domain naming convention]

Examples of disallowed platform modifications and allowed modifications can be derived by treating a modification as first deleting the element to be modified and then adding the modified version of the element. If both the deletion and the addition are OK, then the net modification is OK. Otherwise it's not.

Close Window