Java Class Library

From Infogalactic: the planetary knowledge core
Jump to: navigation, search

The Java Class Library (JCL) is a set of dynamically loadable libraries that Java applications can call at run time. Because the Java Platform is not dependent on a specific operating system, applications cannot rely on any of the platform-native libraries. Instead, the Java Platform provides a comprehensive set of standard class libraries, containing the functions common to modern operating systems.

JCL serves three purposes within the Java Platform:

  • Like other standard code libraries, they provide the programmer a well-known set of useful facilities, such as container classes and regular expression processing.
  • The library provides an abstract interface to tasks that would normally depend heavily on the hardware and operating system, such as network access and file access.
  • Some underlying platforms may not support all of the features a Java application expects. In these cases, the library implementation can either emulate those features or provide a consistent way to check for the presence of a specific feature.

Implementation and configuration

JCL is almost entirely written in Java, except for the parts that need direct access to the hardware and operating system (such as for I/O, or bitmap graphics). The classes that give access to these functions commonly use Java Native Interface wrappers to access operating system APIs.

Almost all of JCL is stored in a single Java archive file called "rt.jar", which is provided with JRE and JDK distributions. The Java Class Library (rt.jar) is located in the default bootstrap classpath,[1] and does not have to appear in the classpath declared for the application. The runtime uses the bootstrap class loader to find the JCL.

The upcoming Java Module System (planned for Java 9) will break the monolithic "rt.jar" Jar file, and modularize the Java Class Library itself in several modules with specified dependencies.[2]

Conformance

Any Java implementation must pass the Java Technology Compatibility Kit tests for compliance, which includes JCL tests.

Main features

<templatestyles src="Module:Hatnote/styles.css"></templatestyles>

JCL Features are accessed through classes provided in packages.

Licensing

<templatestyles src="Module:Hatnote/styles.css"></templatestyles>

Prior licenses

Before the release of OpenJDK, the JDK was based on a proprietary license.

Following their promise to release a fully buildable JDK based almost completely on free and open source code in the first half of 2007,[3] Sun released the complete source code of the Class Library under the GPL on May 8, 2007, except some limited parts that were licensed by Sun from third parties who did not want their code to be released under an open source license.[4] Sun's goal was to replace the parts that remain proprietary and closed source with alternative implementations and make the Class Library completely free and open source.

Until December 2010, the remaining encumbered part of the JDK was made available by Sun then Oracle as Binary Plugs[5] which were required to build the JDK but not necessary to run it. as of May 2007, the only part of the Class library that remained proprietary and closed-source (4% as of May 2007 for OpenJDK 7,[6] and less than 1% as of May 2008 and OpenJDK 6[7][8]) was:[9] [10]

Since the first May 2007 release, Sun, with the help of the community, released as open source or replaced with open source alternatives almost all the encumbered code:

Open source release

Beginning in December 2010, all the so-called binary plugs were replaced by open source replacements, making the entire JDK open.[20]

Alternative implementations

GNU Classpath is the other main free software class library for Java. Contrary to other implementations, it only implements the Class Library, and is used by many free Java runtimes (like Kaffe, SableVM, JamVM, CACAO).

Apache Harmony was another free software class library. Its aim was to implement the other parts of the Java stack (Virtual Machine, Compiler, and other tools required for any Java implementation).

See also

References

  1. Lua error in package.lua at line 80: module 'strict' not found.
  2. Lua error in package.lua at line 80: module 'strict' not found.
  3. [1]
  4. Lua error in package.lua at line 80: module 'strict' not found.
  5. Lua error in package.lua at line 80: module 'strict' not found.
  6. Lua error in package.lua at line 80: module 'strict' not found.
  7. Lua error in package.lua at line 80: module 'strict' not found.
  8. Lua error in package.lua at line 80: module 'strict' not found.
  9. Lua error in package.lua at line 80: module 'strict' not found.
  10. 10.0 10.1 10.2 Lua error in package.lua at line 80: module 'strict' not found.
  11. audio-engine project page
  12. Lua error in package.lua at line 80: module 'strict' not found.
  13. Lua error in package.lua at line 80: module 'strict' not found.
  14. font-scaler projectpage
  15. 15.0 15.1 15.2 Java2D project page
  16. Lua error in package.lua at line 80: module 'strict' not found.
  17. phoneme.dev.java.net/
  18. graphics-rasterizer project page
  19. Lua error in package.lua at line 80: module 'strict' not found.
  20. Lua error in package.lua at line 80: module 'strict' not found.

External links