[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ next ]


Debian GNU/Linux Java FAQ.
Chapter 6 - Java Development

6.1 What full-fledged Java development platforms are available in Debian?

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:

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.

6.2 What free platforms are there and how can I contribute?

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:

Most free Java development is grouped under the Free Java Project. There is a list on free Java at http://www.lists.deus.net/mailman/listinfo/free-java.

6.3 Questions on platforms and license concerns

6.3.1 Java 5 and 6

There are binary packages available for the Java 5 platform for both Debian 'lenny' (currently, the testing distribution) and Debian Sid, and binary packages for Java 6. 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 /etc/apt/sources.list: 

     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

6.3.2 Sun's OpenJDK

Sun adopted in november 2006 the GPL library for almost all of the virtual machine and GPL v2 + the Classpath exception[2]for the class libraries and those parts of the virtual machine that expose public APIs.

As a consequence, the free OpenJDK code might be available in Debian in next releases.

For more information see Free and Open Source Java.

6.3.3 Java 2 SE (aka JDK1.2)

6.3.3.1 Why is Sun's Java 2 SE (aka jdk 1.2) not available?

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.

6.3.3.2 What are the problems with Suns' new license?

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.

6.3.3.3 What is the SCSL?

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".

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.

6.3.3.4 Can I use jdk1.2 while working with the free Java implementations?

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.

6.3.3.5 Why is (some) free software not implementing Java2?

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.

6.3.4 IBM's Developer Kit for Linux

6.3.4.1 Can Debian distribute IBM's jdk?

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 http://www.ibm.com/developerworks/java/jdk/linux/.

6.3.4.2 Is it possible to obtain a licence for Debian?

It would still be non-free, because of item 8 in the Debian Free Software Guidelines: "License Must Not Be Specific to Debian".

6.3.5 JRE

6.3.5.1 Can Debian distribute JRE?

(Quoted from Gene McCulley http://lists.debian.org/debian-java/1999/debian-java-199908/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

6.3.6 GPL or LGPL?

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.

6.4 How can I make a DFSG compliant Java GUI program?

Many Java programs use the Swing library for GUI development. For this there is the 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 libgnome0-java.

6.4.1 Do swing-based programs work in Debian?

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 12.1.1 how to make it work.

6.5 Making Debian packages for Java progams.

6.5.1 Can the package go into main?

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. The 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."

6.5.2 What virtual packages could I use?

6.5.3 Is there a good example Debian package?

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: http://pkg-java.alioth.debian.org/.

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: http://pkg-java.alioth.debian.org/developers.html#rules and http://pkg-java.alioth.debian.org/building.html.

6.5.4 What tools are available to make maintaining a Java packages easier?

At this moment, there is dh_javadoc, which is a tool in the gjdoc package in Debian unstable. And, there are tools in cdbs which can help build packages with ant.

[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ next ]

Debian GNU/Linux Java FAQ.


$Revision: 1.57 $ 4 November 2007Sunday, 4th November

Javier Fernández-Sanguino Peña [email protected]