The Core Libraries Group

This Group is comprised of
developers who participate in the design, implementation, and
maintanence of the Java core libraries.

Introduction

The core libraries consist of classes which are used by many
portions of the JDK. The actual set of files has evolved over time,
but mostly they include functionality which is close to the VM and
is not explicitly included in other areas, such as Security or Networking. Also included are commonly
used tools which are either built on top of the core libraries
(such as jar) or are used by developers
working with them (such as rmic).

Feature Areas

The following table lists the feature areas of the core
libraries with their corresponding repository locations and links
to other developer documentation. (For documentation targeted for
JDK users rather than contributors, see the section End-User Documentation.)

Currently there are some libraries which appear in the name
packages as core libraries but are maintained by other groups.
These exceptions are mentioned within the corresponding table
entries.

src/share/classes/com/sun/java/util/jarsrc/share/classes/java/util/jarsrc/share/native/com/sun/java/util/jartest/java/util/jar
Not strictly part of JAR, but useful:src/share/classes/sun/net/www/protocol/jarsrc/solaris/classes/sun/net/www/protocol/jarsrc/windows/classes/sun/net/www/protocol/jartest/sun/net/www/protocol/jar

Building

Developers are strongly encouraged to perform full
builds prior to check-in of any changes. (A full build is
a build performed when there is no pre-existing build
directory; the respository should contain only the desired changes
and no auto-generated data. Simply performing make at the
top of the build tree is not a full build.) Depending on
the area, incremental builds are not a reliable indicator of
whether or not changes will compile successfully in a full build.
In particular, some files are used early in the bootstrap phase to
build components like java.lang.Object, the launcher, and
javac that are used to build the rest of the JDK. These
are later re-built once sufficient infrastructure has been
generated by the bootstrap build. Incremental builds will only
catch errors that occur in the compile after bootstrap.

Even when it appears that only java code is being
modified, it is prudent to build on multiple platform families. A
recommended minimum is one Windows and one Unix target, but
depending on the code being modified, it may be necessary to
include a wider spectrum or a specific set of platforms. This is
necessary because there is no guarantee that the java code
which depends on a change in core is identical on all platforms.
For instance, rt.jar is not portable—the classes
within it vary from platform to platform.

Testing

Tests or modifications of existing tests are required and must
accompany all changes (both new functionality and any bug fixes).
There are some exceptions. For example, it is not always possible
to provide test for fixes for performance problems or other
conditions that are difficult to simulate or require unusual
environmental conditions (such as exceptionally low memory, system
reboot, third-party software, etc.).

In addition to running the new tests, tests in the modified area
and any dependent areas should be run. Dependent areas may not be
immediately obvious. As with builds, it is necessary to run tests
on multiple platforms.

Not all areas have tests in the repository. There are two
possible reasons for this. It may be that there are no tests or
tests may exist, but have not been audited for open-sourcing. In
the latter case, the goal is to add them soon. Please ask about
appropriate testing when considering a modification.