One subtask of the JDK migration from the legacy bug tracking system to JIRA was reclassifying bugs from a three-level taxonomy in the legacy system, (product, category, subcategory), to a fundamentally two-level scheme in our customized JIRA instance, (component, subcomponent).
In the JDK JIRA system, there is technically a third project-level
classification, but by design a large majority of JDK-related bugs
were migrated into a single "JDK" project.
In the end, over 450 legacy subcategories were simplified into about
120 subcomponents in JIRA. The 120 subcomponents are distributed among 17
components. A rule of thumb used was that a subcategory had to have at
least 50 bugs in it for it to be retained.
Below is a listing the component / subcomponent classification of the
JDK JIRA project along with some notes and guidance on which OpenJDK
email addresses cover different areas.
Eventually, a separate incidents project to host new issues filed at
bugs.sun.com will use a slightly simplified version of this scheme.
The preponderance of bugs and subcomponents for the JDK are in
library-related areas, with components named foo-libs and
subcomponents primarily named after packages.
While there was an overall condensation of subcomponents in the
migration, in some cases long-standing informal divisions in core
libraries based on naming conventions in the description were promoted
to formal subcomponents. For example, hundreds of bugs in the
java.util subcomponent whose descriptions started with "(coll)" were
moved into java.util:collections. Likewise, java.lang bugs starting
with "(reflect)" and "(proxy)" were moved into java.lang:reflect.
- client-libs (Predominantly discussed on
- core-libs (See core-libs-dev.)
(Discussed on nio-dev.)
- javax.naming (JNDI)
- security-libs (See security-dev.)
- javax.crypto (JCE: includes SunJCE/MSCAPI/UCRYPTO/ECC)
- javax.crypto:pkcs11 (JCE: PKCS11 only)
- javax.net.ssl (JSSE, includes javax.security.cert)
- other (When no other subcomponent is more appropriate; use judiciously.)
Most of the subcomponents in the xml component are related to jaxp.
- javax.xml.parsers (JAXP)
- javax.xml.stream (JAXP)
- javax.xml.transform (JAXP)
- javax.xml.validation (JAXP)
- javax.xml.xpath (JAXP)
- jaxp (JAXP)
- org.w3c.dom (JAXP)
- org.xml.sax (JAXP)
For OpenJDK, most JVM-related bugs are connected to the HotSpot Java virtual machine.
The full JDK bug database contains entries related to legacy virtual
machines that predate HotSpot as well as retired APIs.
- jit (Sun Exact VM)
- jit_symantec (Symantec VM, before Exact VM)
- jvmdi (JVM Debug Interface )
- jvmpi (JVM Profiler Interface )
- runtime (Exact VM Runtime)
Notable command line tools in the $JDK/bin directory have corresponding subcomponents.
Some aspects of JDK infrastructure directly affect JDK Hg repositories, but other do not.
(See build-dev and
- licensing (Covers updates to the third party readme, licenses, and similar files.)
- release_eng (Release engineering)
- staging (Staging of web pages related to JDK releases.)
The specification subcomponent encompasses the formal language and virtual machine specifications.
- language (The Java Language Specification)
- vm (The Java Virtual Machine Specification)
The code for the deploy and install areas is not currently included in OpenJDK.
In the JDK, there are a number of cross-cutting concerns whose
organization is essentially orthogonal to other areas. Since these
areas generally have dedicated teams working on them, it is easier to
find bugs of interest if these bugs are grouped first by their
cross-cutting component rather than by the affected technology.
The list of subcomponents will no doubt grow over time, but my inclination is to resist that growth since the addition of each subcomponent makes the system as a whole more complicated and harder to use.
When the system gets closer to being externalized, I plan to post more blog entries describing recommended use of various custom fields in the JDK project.