The Core Libraries Group
This group is comprised of developers who participate in the design, implementation, and maintanence of the Java core libraries.
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).
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.
Feature Area Repository Locations More Information java.langProvides classes that are fundamental to the design of the Java programming language such as String, Math, Enum, and the wrapper classes for primitive types (e.g. Boolean, Float, Character).
Includes basic runtime support for threads.
Includes basic runtime support for creating processes and controlling process I/O.
java.lang.annotationProvides library support for the Java programming language annotation facility. (These are closely related to the Compiler API and javax.lang.model, which are owned by the Compiler Team.
java.lang.instrumentProvides services that allow Java programming language agents to instrument programs running on the JVM. These APIs are owned by the Serviceability Team
- See the Serviceability Team
java.lang.managementProvides the management interface for monitoring and management of the JVM as well as the operating system on which the JVM is running. These APIs are owned by the Serviceability Team
- See the Serviceability Team
java.lang.refProvides reference-object classes, which support a limited degree of interaction with the garbage collector.
java.lang.reflectProvides classes and interfaces for obtaining reflective information about classes and objects.
java.ioProvides for system input and output and the file system.
Supports encoding of objects to and from byte streams.
Tool retrieves the serialVersionID for a class.
Provides buffers to contain data of primitive type.
Defines channels, an abstraction for devices capable of performing I/O operations; defines selectors for multiplexed, non-blocking I/O.
Defines charsets, decoders, and encoders, for translating between bytes and Unicode characters
Tool converts files to and from native encodings.
java.utilProvides the collections framework, formatted printing and scanning, array manipulation utilities, event model, date and time facilities, internationalization, and miscellaneous utility classes.
Includes all classes which implement the Collection interface such as data structures implementing lists, queues, maps, and sets.
Includes support for internationalization and locale-specific output of dates, times, and currencies. These APIs are owned by the Internationalization Team
src/share/classes/sun/util/*.java (except PreHashedMap.java)
java.util.concurrent.locksProvides utility classes used in concurrent programming, including support for atomic updates of single variables and a locking framework which supplements language-level synchronization.
Provides classes for reading and writing the JAR (Java ARchive) file format.
Not strictly part of JAR, but useful:
Tool creates and accesses the contents of a .jar file.
Tool detects conflicts between a target .jar file and the currently installed extension .jar files.
java.util.loggingProvides support to maintain and service software at customer sites.
java.util.regexProvides classes for matching character sequences against patterns specified by regular expressions.
java.util.prefsProvides classes to store and retrieve user and system preference and configuration data.
java.util.spiService provider classes for the java.util package. These APIs are owned by the Internationalization Team
- See the Internationalization Team
java.util.zipProvides classes for reading and writing the standard ZIP and GZIP file formats.
java.mathProvides classes for performing arbitrary-precision integer arithmetic (BigInteger) and arbitrary-precision decimal arithmetic (BigDecimal).
Provides support for remote communication between programs written in Java.
Tool generates stub, skeleton, and tie classes for remote objects using either the JRMP or IIOP protocols, and generates OMG IDL.
Tool starts the activation system daemon that allows objects to be registered and activated in a VM.
Tool starts a remote object registry on the specified port on the current host.
Provides the API for accessing and processing data stored in data source.
Provides access to Naming and Directory Service such as DNS and LDAP.
javax.scriptProvides interfaces and classes that define Java Scripting Engines and a framework for their use in Java applications.
Tool provides a command line script shell both both interactive and batch modes of script execution.
This tool is experimental and unsupported.
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 workspace 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, the contents of make/java/java 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.
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.
The following links reference the canonical end-user documentation for the JDK. The features areas listed above will have documentation in the corresponding sections of these references.
- JDK 6
The features areas listed above will have documentation in the corresponding sections of this reference which includes release notes describing the history of feature updates.
- The Java
The majority of core functionality is described in the section "Trails Covering the Basics". Additional topics may be found in the "Specialized Trails and Lessons" section.
- Core libraries bloggers
- Alan Bateman
Specification Lead for JSR 203 - "More New I/O APIs for the Java Platform ("NIO.2")"
- Joe Darcy
Specification Lead for JSR 269 - "Pluggable Annotation Processing API" and Floating-point Czar
Implementation Lead for JSR 233 - "Scripting for the Java Platform" and a member of the Serviceability Team
- Alan Bateman