#!wml --include=.. #include "include/layout.wml" ## # # Special Tags # # # answer # answer # # # the section counter # {#FAQINDEX#: . :#FAQINDEX#} . %body {#FAQINDEX#:
:#FAQINDEX#}
{#FAQINDEX#: .
:#FAQINDEX#}

.

%body
{#FAQINDEX#}

GNU Classpath is a set of essential libraries for supporting the Java programming language.

Classpath serves the same role that libc has for C, but is much richer in functionality. The broadness of the standard library is an important reason why Java has been so successful. For example, the library includes frameworks to convert between character encodings, for accessing relational databases, for building Graphical User Interfaces, for encryption, for logging, and for numerous other tasks that are needed to build complex applications.

On the GNU operating system, we want to run software independent of the programming language in which it was written. Because Java is widespread, and because Java has some nice features, we want to support Java as well.

Sun Microsystems, the company who has created Java, currently distributes the “Java Development Kit” and “Java Runtime Environment” at no cost. The former even comes with the source code of the standard class library. However, the “Sun Community Source License” does not grant essential freedoms, for example the right to distribute a modified version of the code.

Therefore, Sun’s implementation does not qualify as Free Software.

Though it would be helpful if Sun would open their sources, this is not the most important step toward a free Java. Even more important for a free Java are:

  • Access to the TCK (Technology Compatibility Kits) on acceptable terms
  • Involvement in the JCP without contamination or other unacceptable constraints
  • Easing of the requirements on subsetting. The free software community doesn't work well with the "one big perfect release" model that Sun seems to want.

There was already a lot of discussions around this topic on other sites:

GNU Classpath is a free implementation of Java’s standard library. To execute Java programs, it is also necessary to have a Java Virtual Machine (JVM). This component manages memory, enforces security restrictions, compiles Java bytecodes to the instruction set of your computer, and provides other runtime services. There exist several projects for . Most use GNU Classpath as the up-stream source for their library.

Java programs can also be compiled “ahead of time,” like C++ or other compiled languages. The GNU Compiler Collection (GCC) does this, and its Java library is mostly derived from GNU Classpath.

GNU Classpath is licensed under the GPL plus a special exception:

Linking this library statically or dynamically with other modules is making a combined work based on this library. Thus, the terms and conditions of the GNU General Public License cover the whole combination.

As a special exception, the copyright holders of this library give you permission to link this library with independent modules to produce an executable, regardless of the license terms of these independent modules, and to copy and distribute the resulting executable under terms of your choice, provided that you also meet, for each linked independent module, the terms and conditions of the license of that module. An independent module is a module which is not derived from or based on this library. If you modify this library, you may extend this exception to your version of the library, but you are not obligated to do so. If you do not wish to do so, delete this exception statement from your version.

Please check the FSF FAQ on the GNU GPL: .

If you combine GNU Classpath with independent modules to produce an executable you can copy and distribute the resulting executable under terms of your choice.

So you can use and distribute GNU Classpath as is in your program without changing the license of your software.

Direct such questions to licensing@gnu.org. The FSF is the official copyright holder of Classpath and sets the distribution terms The FSF has a GPL-compliance lab which offers consulting services for companies who are working to develop products that incorporate Free Software so that they can do so in ways that comply with the terms of the GPL and other Free Software licenses. If you are interested in this service, please write to compliance-lab@fsf.org.

See the documentation page, especially the GNU Classpath Hacker’s Guide, and pick up a from the list! No. In fact, if you read Sun's sources we can't accept any code from you. Some contributors of Classpath might be annoyed if their work was being used under conditions that are not according to the terms of the license. However, enforcing the license in court (if this was ever needed) would be easier if the Free Software Foundation can claim to speak in the name of all authors. For this reason, and for others that are specific to the intellectual property system of the United States, GNU projects tend to be a bit picky about getting signatures from all contributors. Please do not see this as a personal offence.

Giving the copyright to the FSF also gives us a clear paper trail where changes come from, which confirms our clean-room status.

See also http://www.gnu.org/licenses/why-assign.html.

For getting the assignment form, please send an e-mail with your name (as it appears in your passport) and your current postal address to the maintainer of GNU Classpath, Mark Wielaard .

Follow these steps to install GNU Classpath. Please note that you need this only if you want to work directly with it; usually JVMs contain a pre-packaged version of GNU Classpath. "> Download the current release unpack make sure you have all pre-requirements configure the distribution; use --help to get the list of options: you will usually need --prefix=dest/dir/for/classpath; use --disable-gtk-peer if you don't use gtk+/gnome. password is anoncvs The main thing this does is creating the gnu/testlet/config.java. You could also do this by hand from the config.java.in file Edit the script 'batch_runner' to set the variable COMPILER correctly (there are a couple of example settings) Edit script 'runner' to set the variable RUNTIME correctly (there are a couple of example settings) run ./batch_run and look at the results. You can also run individual tests with
- echo gnu.testlet.java.lang.String.getBytes | jamvm gnu.testlet.SimpleTestHarness
(Option flags are -verbose and -debug)
When developing a JVM that uses GNU Classpath, a copy of GNU Classpath local to the JVM is often used. To keep the Classpath sources synchronized with the main development, a few approaches are possible (we assume here that you are keeping the local copy of Classpath in your JVM revision control software):

  • Use CVS import and CVS update as explained in of the CVS manual. This works well for minor changes, but has the disadvantage of a limited control on the update / merge of the sources. In fact, most of the developers prefer merging the changes by hand.
  • libgcj, which is almost always trying to be as synchronized as possible with GNU Classpath CVS, has a script that runs daily which produces a (colored) differences overview (including patch/diffs). They also put in special markers into the source for gcj specific changes that the script recognizes.
    • Script can be found at:
    • Daily updated result:
Well consider what happens in a VM. VMThrowable.fillInStackTrace() is very fast -- it's just a chain of addresses. VMThrowable.getStackTrace() is very slow, because it has to convert all those addresses into StackTraceElements. I suspect that you can get the trace for the whole stack in less time than it takes to create a single StackTraceElement. For this reason, the vmState is stored and lazily converted to a StackTraceElement[]. (Andrew Haley)

A particular problem is posed by OutOfMemoryException: throwing it shouldn't require any memory (there's none anyway). Some propose that the VM should preallocate it at bootstrap, but this doesn't solve the problem. In Chris Gray's words "if several threads throw OOME at the same time, the stack traces can get mixed up [...snip...] This situation is less improbable than you might think, since if one thread encounters an OOM situation, all other threads should encounter one too. With some forms of co-operative multi-threading you may get away with it, but in the general pre-emptive case you could be living dangerously."

Beware: generating the complete API Documentation non-trivial and the generation of a full tree takes more then one and half hour (on a 1.4 Ghz Athlon), 150+ MB of memory, at least 25MB of tmp storage, and at least twice so much in your obj build dir.

  1. install gcj 3.3.2 (or higher)
    gjdoc CVS :pserver:anoncvs@subversions.gnu.org:/cvsroot/cp-tools module gjdoc
  2. install libxmlj
    libxmlj CVS :pserver:anoncvs@subversions.gnu.org:/cvsroot/classpathx module libxmlj
    make && make install

  3. For gjdoc add at the start of gnu/classpath/tools/gjdoc/Main.java (main):
    System.setProperty("javax.xml.transform.TransformerFactory", "gnu.xml.libxmlj.transform.TransformerFactoryImpl");
  4. There is a ant build.xml file, but you can also compile it all by hand together with the external/jaxp/source files from Classpath which can be copied in the src direcrory as follows:
    find * -name \*.java | xargs gcj -O2 -g -o gjdoc \
    --main=gnu.classpath.tools.gjdoc.Main

  5. Create a simple gjdoc script and put it in your PATH:
    #!/bin/sh
    CLASSPATH=/home/mark/src/libxmlj:/home/mark/src/gjdoc/src/resources \
    LD_LIBRARY_PATH=/usr/local/libxmlj/lib \
    /home/mark/src/gjdoc/src/gjdoc $*

  6. Configure classpah with --enable-gjdoc.
  7. Type make and go get yourself some coffe, take a shower and do some work in the garden.

There is one catch. The above setup is completely broken for some HTML entities (see [bugs #4823] HTML entities such as auml and nbsp should be put back in the API doc). So if you have spectacular and mysterious crashes then make sure that your java source files don't contain such entities.