[arc-discuss] opensolaris.org java package name registry

[John Plocher]

James Carlson wrote:
> Peter Tribble writes:
>> Is there a registry of java package names, specifically using the
>> opensolaris.org namespace, to avoid name clashes?


The "SMI" equivalent registry has this to say:

> JavaSoft Guidelines and the SMI Java Package Namespace
> 
> In order to prevent Java package name conflicts for Sun products, we provide a Sun-wide Java package name registry. All new Java package names are required to follow the guidelines as described in this page, and to be archived in the registry to prevent future conflicts. Notification of all modifications to the registry will be sent automatically to SAC and JavaSoft's TRC.
> 
> Committed and/or released projects with existing Java package names in the namespaces described below are strongly encouraged to submit them to the registry even though they may not meet the requirements described in this opinion; such pre-existing names shall be considered grandfathered.
> 
> The (old) JavaSoft guidelines[3] were described in an email message circulated by Bill Shannon on 30 July 1997. The message described six categories of Java packages: JDK core APIs, JDK implementation classes, Java Standard Extension API, Java Standard Extension implementation, non-JDK API, non-JDK implementation. In addition, the previously used sunw.* naming prefix was deprecated. These guidelines were formalized in LSARC/1997/301 into a proposal for an SMI-wide Package Name Registry.
> 
> Note that it is preferable to avoid allocating package names in the com.sun namespace that conflict with existing names in the java.* or javax.* namespaces.
> Java Package Root Names
> Package Root Name       Description
> com.sun         Java package root for SMI Java API and implementation classes
> java    Java package root reserved for JDK core APIs [*]
> sun     Java package root reserved for JDK core implementation classes [*]
> javax   Java package root for Java Standard Extension APIs [*]
> 
> 
> [*] Controlled by JavaSoft
> 
> The global namespace for non-JDK code is partitioned by making use of domain names, thus re-using an existing namespace partitioning that can safely be assumed
> to exist anywhere Java programming is taking place. The top-level Java package name prefix is the owner/implementor's domain name in reverse lower-case format.
> Having the means to foster re-use of developed code, the project's content-scope (i.e. the functional area for the content of the project) is proposed as a means of partitioning the next level of the naming hierarchy. Although this reduces
> the likelihood of a naming conflict, in a large company like Sun it does not guarantee it. It is also recommended that where practical public and private classes should be distinguished by using package name conventions.
> 
> Because the SMI-wide package namespace is company-wide and it goes from the generic to the specific, when choosing appropriate package names, projects need to consider the applicability of the scope for the topic, as glanced from the package name, relative to the position in the namespace hierarchy.
> If the name following com.sun is general in scope, for example: tools, admin, the project needs to consider whether the scope of the project itself is 'SMI-wide'. To decide that, the project should consider whether the Java package deliverables are made available in a project-detached manner (in separate, reusable Solaris Packages, linux rpms, ...) or that they only have existence within the scope of the project deliverables.
> 
> If the conclusion is that the project's charter does not have SMI-wide scope, then it is strongly recommended that the package name selected manifest that scope with an appropriate 'deeper' name under the com.sun hierarchy. For example: if
> a project intends to register a Java package for cli content for applications that deal with networked storage, an appropriate name could be com.sun.netstorage.cli.
> 
> Thought should be given to the question whether the project topic has potential
> of 'peer' topics. In the example above of the cli, one could think about web-based interfaces. In such a case possibly preferable package names could be com.sun.netstorage.ui.cli and com.sun.netstorage.ui.web.
> 
> Projects should avoid using the product's name as part of the package name. This, because over time, the product may be discontinued, and the Java package may be featured in a differently named product. This will also help in fostering reuse of the Java code base throughout SMI.
> Java Package Name Registry Content Description
> 
> The Java Package Name Registry supports the registration of new Java package names within the com.sun namespace, as well as modification, deletion, and browsing of the registry entries. The registry also supports JavaSoft-controlled JDK Core and Standard Extension APIs, under the supervision of JavaSoft's TRC.
> 
> The registry entry for each registered Java package name contains the following
> information:
> 
>     * Full Java package name
>     * Contact (responsible manager or engineer)
>     * Group / Project Name
>     * Project description
>     * Project URL (link to project page with additional information about the project and any relevant acronyms)
>     * Group responsible for technical approval (e.g. TRC, LSARC,ASARC, PSARC, etc.)
>     * Responsible Steering Committee (or equivalent)
>     * Interest list (additional email aliases for notification of modifications)    * Entry status, one of:
>           o ACTIVE (for packages currently in use)
>           o DEPRECATED (for packages being deprecated)
>           o INACTIVE (for packages no longer shipping)
>           o GRANDFATHERED (for non-conformant pre-existing package names)
>     * Creation date (maintained automatically)
>     * Last modified date (maintained automatically)
>