If you are looking for an integrated, java virtual machine, compiler and runtime environment Debian does provide them. Of course that would depend on the Debian GNU/Linux version you are using, generally speaking they would be:
http://www.blackdown.org
)
kaffe
.
Please help one of the Free Java implementations if you want to use Java in Debian. There are a lot of projects that you can choose from:
http://www.kaffe.org
or
http://www.transvirtual.com
.
http://www.japhar.org
.
The Java virtual machine of "Hungry Programmer". More info in
http://www.hungry.com/products/japhar
.
http://sourceware.cygnus.com/java/
http://www.research.ibm.com/jikes/
.
A fast compiler written in C++ (check also http://www10.software.ibm.com/developerworks/opensource/jikes/
).
(The new license seems to be finally really free)
http://www.dms.at/kjc/
.Yet Another
Free Java Compiler, this time written in Java, and GPL. Included in Kaffe
since release 1.0.5.
http://fastjar.sourceforge.net/
,
as a jar tool. (this link seems to be broken, anyone?)
http://www.gnu.org/software/classpath/
or http://www.classpath.org
. Most of
the Standard classes for Java 1.2 (except Swing and RMI) are implemented by the
ClassPath project, it tries to build an alternative to jdk's 1.2 core classes.
http://www.cs.berkeley.edu/~mdw/proj/ninja/ninjarmi.html
http://www.internatif.org/bortzmeyer/autoconf-Java/
helps easy recompilation of Java programs.
http://sourceware.cygnus.com/mauve/
is a free suite to test if these tools are 'compliant'.
There is a list on free Java at http://www.lists.deus.net/mailman/listinfo/free-java
,
also look http://www.gnu.org/software/java/
for information about Free Java.
Due to license problems. Clause 2 of the license
(check also the FAQ
)
that comes with is says:
Software is confidential and copyrighted. Title to Software and all associated intellectual property rights is retained by Sun and/or its licensors. Except as specifically authorized in any Supplemental License Terms, you may not make copies of Software, other than a single copy of Software for archival purposes.
Sun has moved to a new license the Sun Community License, like the GPL it is a viral license, but making all it touches subject to Sun licensing fee. The SCSL even goes so far as to define any implementation of a Sun specification as a "Modified Work". Basically, this means that if you implement any part of the new 1.2 API or Jini API, even from scratch, Sun will "own" your implementation and you will have to pay them for the right to use it.
13. "Modification(s)" means (i) any change to Covered Code; (ii) any new file or other representation of computer program statements that contains any portion of Covered Code; and/or (iii) any new Source Code implementing any portion of the Specifications.
The SCSL is the "Sun Community Software License" that can be found
http://java.sun.com/communitysource/
.
It is not compatible with Free Software for several reasons, and agreeing to
this license (e.g. by downloading source covered by the SCSL) will make it
impossible for you to contribute to free software clean-room implementations.
According to Sun, this includes using documentation and API specifications
available only under SCSL.
To quote one open source developer, the SCSL is "about as free as the former Soviet Union".
Clause 1 of the Supplemental License Terms says:
[You] may not create, or authorize your licensees to create additional classes, interfaces, or subpackages that are contained in the "java" or "sun" packages or similar as specified by Sun in any class file naming convention;
Which seems to prevent one from making his own implementation of the standard Java classes using the JDK.
However, it is unclear whether or not the word `additional' includes reimplementations of existing classes, or whether it applies only to classes with new names.
Sun has made public statements in connection with their legal strategy in the Sun-Microsoft lawsuit that indicate that the company considers the published specifications of Java2 to be intellectual property that can not legally be used by persons involved in efforts to create Java2 clean-room implementations. For this reason, some open source projects have decided to not implement Java2 any time soon. One example is Kaffe. Some projects (like the Japhar/Classpath project) have decided to challenge Sun's legal position and are going ahead with Java2.
It seems not. It has the following license:
Program Code Consists of the IBM Developer Kit for Linux(R), Java(TM) Technology Edition, Version 1.1.8, in Binary Code form, as modified by IBM to run on the RedHat(R) 6.0 Linux or Caldera(R) OpenLinux 2.2 Operating systems. The Program Code consists of the Java virtual machine, the Java platform core classes and supporting files (also known as the Java Runtime Environment or JRE) Java Tool Kit, Documentation and Java Samples. Program Code may include soft copy documentation, readme files, program data and such like. You may only use the Program Code if you are a current licensee of Redhat 6.0 Linux or Caldera OpenLinux 2.2 Operating systems and the Program Code may only be used in conjunction with such products.
See bug #54641 for an issue about IBM JDK. You can dowload it from http://www.ibm.com/java/jdk/118/linux
.
It would still be non-free, because of item 8 in the DFSG "License Must Not Be Specific to Debian".
(from http://www.debian.org/Lists-Archives/debian-java-9908/msg00021.html
)
I don't think we can or want to distribute the JRE with Debian. The
supplemental license terms of the JRE has a few very nasty clauses:
1. License to Distribute. You are granted a royalty-free right to reproduce and distribute the Software provided that you: (i)distribute the Software complete and unmodified, only as part of, and for the sole purpose of running, your Java applet or application ("Program") into which the Software is incorporated;
We might get away with this one since we distribute it together with Java applications bundled with Debian. But we also do want to allow people to download only the jre package.
(ii) do not distribute additional software intended to replace any component(s) of the Software;
But we cannot agree to this one. We want to distribute Kaffe, Japhar, Classpath, Gcj, Kopi, Fastjar, etc which are intended to replace the JRE with a Free version. Even if we don't consider non-free part of Debian (the JRE would not go into main :) I think we should not encourage software that tries to prevent Free replacements.
[...] (v) may not create, or authorize your licensees to create additional classes, interfaces, or subpackages that are contained in the "java" or "sun" packages or similar as specified by Sun in any class file naming convention;
My example why this is a bad clause was not so good since someone pointed out that you do not want to create something that is non standard. I do agree that we want a standard implementation of the core classes, but I also think that you should have the freedom to create non-standard classes. (Or fix bugs or stupid mistakes in the standard classes.)
[...] and(vii) agree to indemnify, hold harmless, and defend Sun and its licensors from and against any claims or lawsuits, including attorneys' fees, that arise or result from the use or distribution of the Program.
And I don't think that Debian (or SPI) can or wants to do that.
So I am afraid that we also cannot distribute the Sun or Blackdown JRE. This isn't that bad since it is non-free software, but it is annoying. As I said before please help one of the (many) Free Java projects out there if you want to see a Free JVM, Standard Classes, Compiler, etc. in Debian. They are far from complete but they do work for most purposes
Java uses dynamic linking at runtime. Using the reflection API and class loading, the linking can be completely data driven, specifying classes and methods by name. This moves the legal issues of using GPL'ed Java code into the user's hands, as a violation of the GPL can not be proven from the executable itself. Unlike plugins, Java classes do not even have to have a specific structure to be used in such ways. By using native methods and selecting DLL's at runtime, this problem might also affect native code.
Example: a GPL'ed Java dependency checker using the reflection API. Java's runtime linkage, in particular the reflection API, blurrs the lines between code and data even more than e.g. native plugins.
If you want to write Java code that can be used without the user having to worry about licensing issues, consider using the Lesser GPL (LPGL). If you want to avoid seeing your classes and packages being used by non-free software,
Debian Java FAQ.
1.0 7 April 2002Thu, 7 Dec 2000 19:10:13 +0100jfs@computer.org