GNU Classpath

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

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

Not to be confused with the GPL linking exception.
GNU Classpath
GNU Classpath badge.png
<templatestyles src="Template:Hidden begin/styles.css"/>
Screenshot
GC SwingDemo.png
Demonstration of the GNU Classpath Swing
Developer(s) GNU Project
(formally held by FSF)
Stable release 0.99[1] / March 16, 2012; 12 years ago (2012-03-16)
Development status Active[2]
Written in C and Java
Operating system Cross-platform
Type Library
License GPL linking exception
Website www.classpath.org

GNU Classpath is a project aiming to create a free software implementation of the standard class library for the Java programming language. Despite the massive size of the library to be created, the majority of the task is already done, including Swing, CORBA, and other major parts.[citation needed] The Classpath developers have implemented almost all of the classes from J2SE 1.4 and 5.0. Classpath can thus be used to run popular Java-based software such as Vuze and Eclipse.

GNU Classpath has been one of the high priority directions of the GNU Project. While the source code of the "official" implementation from Sun Microsystems was available, the license did not allow distribution of any alterations. This was a major obstacle for many projects that could not progress without altering this code. The GNU Classpath development community includes institutions focused on research of Java virtual machines, as well as companies interested in providing alternative Java runtimes.

GNU Classpath is a part of the Free Software Foundation. It was originally developed in parallel with libgcj due to license incompatibilities, but later the two projects merged.

License

GNU Classpath is licensed under the GNU General Public License with a linking exception. This is a free software license. All code is formally owned by the Free Software Foundation,[citation needed] and this owner is bound by its own contractual obligations to the developers.[clarification needed]

Uses

GNU Classpath is used by many free Java runtimes (like Kaffe, SableVM, JamVM, CACAO, Jikes RVM, VMkit) because every full-featured Java virtual machine must provide an implementation of the standard class libraries.

Some other uses include:

  • The GNU Compiler for Java, which is capable of compiling Java code into native standalone executables.
  • GCJAppletViewer[3] for launching Java applets from command line if they are not supported by the browser in use.
  • IKVM.NET, which integrates Java with the .NET Framework
  • JNode, an operating system for running Java applications. This system is written in Java and assembler only.
  • Specialised virtual machines such as Jaos for integration with the Oberon programming language, and JamaicaVM for embedded systems with real-time guarantees.
  • Virtual machines for distributed computing with clusters, having up to 128 processors on Myrinet.[4]
  • The IcedTea project used GNU Classpath as a replacement for proprietary elements of OpenJDK, prior to their replacement upstream.

History

GNU Classpath development started in 1998 with five developers.[citation needed] During the history, it merged several times with other projects having similar goals (Kaffe, libgcj). In the past, GNU Classpath supplied its own virtual machine (Japhar). As Classpath was becoming a base library, shared with a lot of different projects, this virtual machine received less and less attention and is now no longer supported.[citation needed]

After implementing the majority of the official Java 1.4 API, the work in the project became more bug oriented rather than API coverage oriented. On October 24, 2006, the implementation of the last missing 1.4 class, HTMLWriter, was committed. The development speed (computed mathematically as the average number of the new lines of code per day) reached its highest ever in 2006.[citation needed]

The name GNU Classpath was originally suggested by Bradley M. Kuhn to one of the first developers, Paul Fisher. At the time, there was great concern in the Free Java implementations community about enforcement of Sun's trademark on Java against free implementations. Kuhn suggested the name $CLASSPATH, which is the environment variable used by most Java systems to indicate where the Java libraries reside on the computer. Since $CLASSPATH often expanded to a path name that included the word java (such as /usr/lib/java), it was a way to evoke the name Java without actually saying it. Fisher and other developers didn't like the unsightly use of the $ and all capital letters and settled on Classpath.

Development team

The maintainer takes care of the legal side of the project, prepares the regular project releases and does some quality management. The maintainer also grants the CVS access permissions.[citation needed]

GNU Classpath has no formal hierarchy. The work is done by the most technically capable, and there is no strict work division either. All code changes are first posted to the discussion list as patches where they can be opposed if needed. The project typically receives between five and eight patches per day.

The GNU Classpath library code coverage progress can be tracked against OpenJDK6[5] and OpenJDK7.[6]

Virtual machine integration

GNU Classpath contains classes from the official Java API namespace. Where calls to native code are necessary or highly desired, this is done from a small number of "VM" classes. The name of such a VM class matches the name of the class requiring native methods, plus the additional VM prefix: VMObject, VMString and so on. VM classes, stored separately from the rest of code, are package private and final. The methods of these classes contain the keyword native, indicating the necessity of the supporting native library. Such libraries are provided by the authors of a Java virtual machine, hence GNU Classpath can be connected to nearly any Java virtual machine if the sources of such virtual machine are available and can be modified.

Support for the new language features in Java 1.5

Before version 0.95, each GNU Classpath release consisted of two separate release tarballs; one that represented the state of the main development branch and another that contained the contents of a more experimental branch, supporting the additions, such as generics, enumerations and annotations, present in Java 1.5.[7]

Since version 0.95,[8] Java 1.5 additions like generics have been fully integrated into the main branch. The branch can be built by using the Eclipse compiler, ecj, to compile Java 1.5 source code to bytecode. In the case of GCJ, it uses ecj to perform this initial stage, then converts the bytecode to native code. From 0.95 onwards, GNU Classpath also supports compiling and running the newly GPLed open-source javac compiler using GNU Classpath and also allows the GNU Classpath class library, tools and examples to be compiled with javac itself.

Classes from the omg.org domain

File:Interoperable software.png
Sun and GNU Corba interact in a two client game[lower-alpha 1]

GNU Classpath does not accept any code that has a non-free license, or that was automatically generated from code with a non-free license. The standard Java API contains numerous classes from the omg.org domain that are normally generated from the IDL files, released by the Object Management Group. The "use, but no modify" license of these files counts as non-free. For this reason, the mentioned classes in the GNU Classpath project were written from scratch, using only the official printed OMG specifications. Hence this part of GNU Classpath is as free as any other code in the project.

See also

Notes

  1. Fosdem 2006 included this and other demonstrations of data exchange between Sun's and Classpath implementations of CORBA.[9] The source code is available[10] in the Classpath repository.

References

  1. Lua error in package.lua at line 80: module 'strict' not found.
  2. http://git.savannah.gnu.org/cgit/classpath.git/log/
  3. Lua error in package.lua at line 80: module 'strict' not found..
  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. Lua error in package.lua at line 80: module 'strict' not found..

External links

  • No URL found. Please specify a URL here or add one to Wikidata.
  • Lua error in package.lua at line 80: module 'strict' not found..
  • Lua error in package.lua at line 80: module 'strict' not found.: test runs and binary compatibility tests
  • Lua error in package.lua at line 80: module 'strict' not found..
  • Lua error in package.lua at line 80: module 'strict' not found..