[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ A ] [ next ]
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:
Sun's jdk 1.4 (port made by Blackdown, see How can I get Debian packages from
Blackdown?, Section 13.1 or go to
Sun's Java 5 jdk, available in the Debian 4.0 etch release in the non-free section.
Sun's Java 6 jdk, available in Debian lenny (unreleased, currently testing) and Debian sid, also as packages in the non-free.
Sun's OpenJDK 6 jdk, available since the Debian 5.0 lenny release in the main section.
Previous release of Debian included an installer package for IBM's Java Development Kit, but that is not longer available.
Since the Debian 3.1 'sarge' release, Debian provides the
free-java-sdk package which makes up a free Java Software
Development Kit (SDK). All software it depends on are DFSG compliant.
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:
gcj and libgcj:
A fast compiler written in C++ (check also
(The new license seems to be finally really free)
Free Java Compiler, this time written in Java, and GPL. Included in Kaffe
since release 1.0.5.
as a jar tool. (this link seems to be broken, anyone?)
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.
Most of the RMI classes are implemented by NinjaRMI
helps easy recompilation of Java programs.
is a free suite to test if these tools are 'compliant'.
Most free Java development is grouped under the
Free Java Project. There
is a list on free Java at
There are binary packages available for the Java 5 and Java 6 platforms since
the Debian 5.0 ('lenny') release. These packages are available in the
non-free section, so you have to configure your apt sources
appropiately. If you have the following in your
deb http://ftp.debian.org/debian etch main
you need to change it to:
deb http://ftp.debian.org/debian etch main contrib non-free
Once this is done and you have updated your package database. You can either install the Java development kit:
apt-get install sun-java6-jdk
or the Java runtime environment:
apt-get install sun-java6-jre
If you are using the Debian 4.0 'etch' release you will find Java 5 instead. Similarly, you can install the Java development kit:
apt-get install sun-java5-jdk
or the Java runtime environment:
apt-get install sun-java5-jre
Sun recommends you update the alternatives system to have Sun's tools as the default:
update-java-alternatives -s java-6-sun
Or for java 5:
update-java-alternatives -s java-1.5.0-sun
Sun adopted in november 2006 the GPL library for almost all of the virtual machine and GPL v2 + the Classpath exceptionfor the class libraries and those parts of the virtual machine that expose public APIs.
As a consequence, the free OpenJDK code is available in Debian since the 5.0 (lenny) release.
You can install the Java development kit:
apt-get install openjdk-6-jdk
or the Java runtime environment:
apt-get install openjdk-6-jre
For more information see
Free and Open Source
Due to license problems. Clause 2 of the
(check also the
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
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".
However, if you have never agreed to the SCSL, then it is still permissible, barring any patents that Sun has for the technology, for you to create your own clean room version of the 1.2 API. It is important that you never agree to the license, even for the documentation. For example, if you buy a printed book which describes the API, there is a long legal history (in the US at least), that prohibits attaching these kinds of contracts to books.
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 Classpath project) have decided to challenge Sun's legal position and are going ahead with Java2.
No, as its license does not allow redistribution. Actually, older releases (version 1.1) even restricted use of the jdk to specific distributions (and Debian was not included in the list).
You can still download it and use it in Debian yourself even Debian is not in
the list of tested (or supported) platforms, see
It would still be non-free, because of item 8 in the
Debian Free Software
Guidelines: "License Must Not Be Specific to Debian".
(Quoted from Gene McCulley
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, consider using the GPL license.
Many Java programs use the Swing library for GUI development. For this there
libswing-java. Most programs will compile against this
library, but that does not garantee it to work. Not always are all classes
implemented or implemented well.
An alternative to the Swing library is the Standard Widget Toolkit (SWT,
libswt-java) which is based on the GTK+ library.
A third alternative is the use the GUI functionality from either KDE or Gnome.
For KDE, the kdebindings tar.gz does the job (is there a deb package too?).
For Gnome there is the
Swing does work and can be installed, please note that 1.2 and 1.3 jvms include swing, otherwise you need to download it for your particular jvm. See later on Making swing work in Debian, Section 13.1.1 how to make it work.
Yes, but only if it can be build and run with Java programs/tools in main, and if it has a Debian compliant open source license. If it needs programs from contrib or non-free, then is must go into contrib or non-free, depending on the license of the program itself.
More specifically, if the program can be build and run with
free-java-sdk, then it only depends on Debian packages from main.
free-java-sdk description states: "Just install this
package, set JAVA_HOME to /usr/lib/fjsdk and try to rebuild your Java packages.
If it works - a package from contrib section can be moved to main."
java-common. It is the Mother Of All Java Packages, in the
proposed policy. It contains the text of the Policy (Docbook), as well as
utilities scripts (for instance to build a CLASSPATH from a list of jars
java-compiler-dummy.It is a small tool useful for the transition
to the new Policy. Until all compilers comply with the Policy,
java-compiler-dummy provides the following services:
Provides: java-compiler so upper packages are happy,
set CLASSPATH before calling the real compiler.
java-virtual-machine-dummy.It is a small tool useful for the
transition to the new Policy. Until all virtual machines comply with the
Policy, java-virtual-machine-dummy provides the following services:
Provides: java-virtual-machine so upper packages are happy,
set CLASSPATH before calling the real VM.
There are many Debian packages of both Java applications and libraries. These may serve as an good starting point, as it can serve as an example for making a new Debian package.
A good start would be to check out the pkg-java project on Alioth:
Note that there are many ways to make a Debian package, making use of Ant or
Makefiles does not really matter. But, some tips for good practice are given
on the pkg-java page:
At this moment, there is dh_javadoc, which is a tool in the
package in Debian unstable. And, there are tools in
can help build packages with
Debian GNU/Linux Java FAQ.$Revision: 1.57 $ 4 August 2009Sunday, 4th November