[java-common] 01/01: Imported Debian version 0.47+deb7u1
Markus Koschany
apo-guest at moszumanska.debian.org
Thu Mar 24 18:14:24 UTC 2016
This is an automated email from the git hooks/post-receive script.
apo-guest pushed a commit to branch wheezy-lts
in repository java-common.
commit 465d403eac4bb844ac257dbb112e450c7acced9b
Author: Markus Koschany <apo at debian.org>
Date: Thu Mar 24 18:59:19 2016 +0100
Imported Debian version 0.47+deb7u1
---
Makefile | 91 ++
debian-java-faq/Makefile | 42 +
debian-java-faq/debian-java-faq.it.sgml | 1953 +++++++++++++++++++++++++++
debian-java-faq/debian-java-faq.sgml | 605 +++++++++
debian/README.Debian | 15 +
debian/README.gcj-native-transition | 30 +
debian/changelog | 183 +--
debian/compat | 2 +-
debian/control | 76 +-
debian/copyright | 67 +-
debian/default-jdk-doc.lintian-overrides | 4 -
debian/gcj-native-helper.lintian-overrides | 1 -
debian/gcj-native-helper.preinst | 13 -
debian/java-common.dirs | 1 +
debian/java-common.doc-base.faq | 13 +
debian/java-common.doc-base.policy | 13 +
debian/java-common.docs | 1 +
debian/java-common.examples | 1 +
debian/java-common.install | 3 -
debian/java-common.lintian-overrides | 1 +
debian/java-common.manpages | 1 -
debian/java-common.postrm | 4 +-
debian/java_defaults.mk | 69 -
debian/rules | 181 ++-
dummy/README | 2 +
dummy/java-compiler-dummy.control | 12 +
dummy/java-virtual-machine-dummy.control | 13 +
dummy/java1-runtime-dummy.control | 13 +
dummy/java2-compiler-dummy.control | 12 +
dummy/java2-runtime-dummy.control | 13 +
examples/classpath-from-jars-1 | 12 +
html.dsl | 29 +
patches/0.16-policy.author | 7 +
patches/0.16-policy.patch | 56 +
patches/0.18-jni-policy.author | 1 +
patches/0.18-jni-policy.patch | 52 +
policy.xml | 524 +++++++
scripts/completion/update-java-alternatives | 65 -
scripts/update-java-alternatives | 7 +-
scripts/update-java-alternatives.8 | 6 +-
40 files changed, 3713 insertions(+), 481 deletions(-)
diff --git a/Makefile b/Makefile
new file mode 100644
index 0000000..515a599
--- /dev/null
+++ b/Makefile
@@ -0,0 +1,91 @@
+#!/usr/bin/make -f
+
+# Good info at: info make "Quick Reference"
+# $^ All prerequisites
+# $< First prerequisity
+# $@ Target
+
+# Some default variables
+DOC = usr/share/doc
+DVIPS=dvips
+PUBLISHDIR=$(DESTDIR)/$(DOC)/java-common
+#DSLF=work.dsl
+#DSL=-d $(DSLF)
+# Default language to use
+LANGUAGE=
+LANG=C
+LC_CTYPE=C
+
+all: debian-java-policy debian-java-faq-gen
+
+# Policy part
+MAKEOUT=policy.txt policy.ps
+OUTPUTS=$(MAKEOUT) policy.xml
+MAKEDEP=$(MAKEOUT) policy.html
+
+debian-java-policy: $(MAKEDEP)
+update: debian-java-faq-update
+
+policy.tex: policy.xml
+ jw $(DCL) -b tex $(DSL) policy.xml
+
+policy.dvi: policy.xml
+ jw $(DCL) -b dvi $(DSL) policy.xml
+
+policy.ps: policy.dvi
+ $(DVIPS) -f $< > $@
+
+policy.html: debian-java-policy/index.html
+
+debian-java-policy/index.html: policy.xml
+ # docbook and dsl file needs to be in that dir for things to work.
+ # The png file is copied there so it can be referenced in a proper way.
+ #
+ # This is no longer true.
+ mkdir -p debian-java-policy
+ jw -b html $(DSL) -o debian-java-policy $<
+ # To make that file the intdex.
+ (cd debian-java-policy; rm -f $^)
+
+policy.txt: policy.xml
+ #jw -u $< > dump.html
+ #lynx -force_html -dump dump.html > $@
+ #-rm -f dump.html
+ jw -b txt $(DSL) $<
+
+install: debian-java-policy-install debian-java-faq-install dummy-install script-install
+
+dummy-install:
+ mkdir -p $(PUBLISHDIR)/dummy-packages
+ cp dummy/README $(PUBLISHDIR)/dummy-packages
+ cp dummy/*.control $(PUBLISHDIR)/dummy-packages
+
+script-install:
+ mkdir -p $(DESTDIR)/usr/sbin
+ install -m 755 scripts/update-java-alternatives $(DESTDIR)/usr/sbin/
+ mkdir -p $(DESTDIR)/usr/share/man/man8
+ install -m 755 scripts/update-java-alternatives.8 $(DESTDIR)/usr/share/man/man8/
+
+debian-java-policy-install:
+ install -m 0444 $(OUTPUTS) $(PUBLISHDIR)
+ cp -a debian-java-policy $(PUBLISHDIR)
+ ln -s debian-java-policy $(PUBLISHDIR)/html
+
+clean: debian-java-faq
+ -rm -Rf debian-java-policy
+ -rm -Rf policy.html
+ -rm -f $(MAKEOUT)
+ -rm -f policy.dvi
+ (cd $<; make clean)
+
+debian-java-faq-gen: debian-java-faq
+ (cd $<; make debian-java-faq.html/index.html)
+
+# Change the publish dir if you want to send it to a new package.
+debian-java-faq-install: debian-java-faq debian-java-faq-gen
+ (cd $<; make publish PUBLISHDIR=$(PUBLISHDIR))
+
+debian-java-faq-update: debian-java-faq
+ svn export svn://svn.debian.org/svn/ddp/manuals/trunk/java-faq/ faq-update/
+ cp faq-update/* $</
+ rm -fr faq-update/
diff --git a/debian-java-faq/Makefile b/debian-java-faq/Makefile
new file mode 100644
index 0000000..75c2ec5
--- /dev/null
+++ b/debian-java-faq/Makefile
@@ -0,0 +1,42 @@
+# Makefile for a manual in the Debian Documentation Project manuals.sgml
+# tree.
+
+# The directory in which this makefile resides must also contain a file
+# called <directoryname>.sgml, which is the top-level file for the manual
+# in this directory.
+
+# What is the current manual's name
+#MANUAL := $(shell basename $(shell pwd))
+MANUAL := debian-java-faq
+# Where are we publishing to?
+# (this can be overriden by a higher level makefile)
+PUBLISHDIR := /org/www.debian.org/www/doc/manuals
+
+# What do we want by default?
+all: publish
+
+# This target installs the generated HTML in the published directory.
+publish: $(MANUAL).html/index.html
+# fail if there is no PUBLISHDIR
+ [ -d $(PUBLISHDIR) ] || exit 1
+ rm -f $(PUBLISHDIR)/$(MANUAL)/*.html
+ install -d -m 755 $(PUBLISHDIR)/$(MANUAL)
+ install -m 644 --preserve-timestamps $(MANUAL).html/*.html \
+ $(PUBLISHDIR)/$(MANUAL)/
+
+generate: $(MANUAL).html/index.html
+
+$(MANUAL).html/index.html: $(wildcard *.sgml)
+ debiandoc2html $(MANUAL).sgml
+
+# ensure our SGML is valid
+# (add this to $(MANUAL).html rule to prevent building if not)
+validate:
+ nsgmls -gues $(MANUAL).sgml
+
+clean:
+ rm -rf $(MANUAL).html
+
+distclean: clean
+
+.PHONY: all publish clean distclean validate
diff --git a/debian-java-faq/debian-java-faq.it.sgml b/debian-java-faq/debian-java-faq.it.sgml
new file mode 100644
index 0000000..26cce53
--- /dev/null
+++ b/debian-java-faq/debian-java-faq.it.sgml
@@ -0,0 +1,1953 @@
+<!doctype debiandoc system>
+
+<book>
+
+<titlepag>
+<title>Debian Java FAQ</title>
+<author>
+<name>Javier Fern�ndez-Sanguino Pe�a </name>
+<email>jfs at computer.org</email>
+</author>
+
+<author>Per la traduzione si veda l'Appendice <qref id="traduzione">B</qref></author>
+
+<version>$Revision: 1.3 $
+<date>luned�, 28 luglio 2003 22:52:30 +0200
+
+<abstract>
+Risposte alle FAQ (domande pi� frequenti) su Debian e Java
+(Nota bene: alcune di queste informazioni non sono aggiornate).
+Qualunque modifica o correzione a queste FAQ � gradita: si prega di
+inviare qualunque suggerimento al responsabile che attualmente si
+occupa di questo progetto.
+</abstract>
+
+<copyright>
+Questo documento pu� essere liberamente ridistribuito o modificato
+in qualunque forma, a condizione che gli eventuali cambiamenti siano
+documentati.
+
+Questo documento pu� essere ridistribuito a pagamento
+o gratuitamente, pu� essere modificato (per modifica si intende anche
+la trasposizione da un mezzo o da un formato di file ad un altro, o la
+traduzione da una lingua all'altra) a condizione che ogni cambiamento
+rispetto all'originale sia adeguatamente segnalato.
+</copyright>
+
+
+</titlepag>
+
+
+<toc>
+
+
+<chapt>Introduzione
+<p>
+
+<sect>Introduzione alle FAQ di questo documento
+
+<P>
+Javier Fern�ndez-Sanguino il 1� febbraio 2000 ha cominciato a raccogliere
+queste FAQ dopo aver arditamente postato alla debian-java mailing list un
+messaggio che aveva come oggetto "Che ne pensate di una raccolta di FAQ
+su Java per Debian?". Chiaramente, dal momento che "ogni idea implica
+una responsabilit�", ha dovuto scorrere l'archivio di tre mesi della
+neonata mailing list.
+
+<p>
+Lo scopo di questa raccolta di FAQ � diventare un documento in cui cercare
+ogni genere di domanda che uno sviluppatore o un semplice utente possa
+porre per quanto riguarda Java e Debian. Comprende problemi con le
+licenze, pacchetti di sviluppo disponibili e programmi relativi alla
+costituzione di un ambiente Java libero.
+
+<p>
+Un ringraziamento a tutti (e sono molti) coloro che hanno contribuito
+attraverso la mailing list debian-java, perch� hanno permesso che fosse
+possibile scrivere questo documento. Senza le loro conoscenze questa
+raccolta di FAQ non sarebbe stata possibile, dal momento che io ho
+solo una vaga idea di ci� di cui essi parlano quando consulto la lista.
+
+<p>
+Un ringraziamento speciale a Paul Reavis, che ho scoperto aver scritto
+precedentemente la pagina informativa di Debian-JDK, che io ho usato
+per aggiungere altre informazioni e che ha fornito utili suggerimenti per
+questo documento. Ringrazio anche Peter Moulder che ha revisionato le
+FAQ e ha fornito molti suggerimenti; Juergen Kreileder, manutentore
+dei pacchetti debian di Blackdown, che ha indicato alcuni errori;
+ed Egon Willighagen, che ha fornito molte giuste correzioni per
+aggiornare il suo contenuto.
+
+<p>
+Questo documento non � dedicato ad altre distribuzioni Linux o a problemi
+che non siano specificamente relativi a Debian. Vedi le
+<url id="http://www.blackdown.org" name="pagine di Blackdown">
+per queste informazioni. Per informazioni pi� specifiche si possono
+controllare le
+<url id="http://www.blackdown.org/java-linux/docs/support/faq-release/FAQ-java-linux-1.html" name="Java Linux FAQ">.
+
+
+<sect>Pubblicazione delle FAQ
+
+<p>
+Questa raccolta di FAQ � reperibile presso il Debian Documentation Project
+<url id="http://www.debian.org/doc/manuals/debian-java-faq/">.
+<package>java-common</package> (disponibile in
+<url id="http://packages.debian.org/java-common">), fornisce una versione
+HTML per la lettura offline. Al momento la versione del pacchetto
+non fornisce le versioni in formato testo o PDF, per chi desiderasse
+tali versioni si consiglia di riportare un bug "wishlist" al pacchetto.
+Inoltre, la versione del pacchetto reperibile in internet potrebbe essere pi�
+aggiornata di quella non in linea.
+
+
+<sect>Segnalare difetti di queste FAQ
+
+<p>
+Si tenga conto di come questa FAQ sia molto datata (si veda
+<url id="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=156547"
+ name="Bug report #156547">)
+e della necessit� di un manutentore dell'archivio.
+Chi voglia dedicarvisi e sia esperto di Java in Debian, contatti
+l'attuale curatore. In ogni caso, � benvenuta ogni correzione
+ad informazioni ormai datate (meglio ancora se relativa agli ultimi
+<url id="http://cvs.debian.org/ddp/manuals.sgml/java-faq/?cvsroot=debian-doc"
+name="sorgenti CVS">).
+
+<p>
+Eventuali difetti di questa FAQ devono essere segnalati all'attuale
+manutentore, sempre che riguardino la sua ultima versione, disponibile presso
+<url id="http://www.debian.org/doc/manuals/debian-java-faq/index.en.html">.
+Le traduzioni, ove disponibili, potrebbero essere leggermente datate rispetto
+alla versione originale inglese; si controlli la versione inglese, prima di
+segnalare un difetto trovato in una traduzione.
+
+
+
+<chapt>Introduzione a Java
+
+<sect>Cos'� Java?
+<p>
+Java � un linguaggio di programmazione orientato agli oggetti,
+fortemente tipizzato ed indipendente dalla piattaforma usata,
+viene spesso associato al World Wide Web. Java � stato sviluppato
+dalla <url id="http://www.sun.com" name="Sun Microsystems"> per
+applicazioni embedded, ma da allora si � sviluppato, diventando un
+linguaggio di programmazione generico. Il codice sorgente di Java
+pu� essere compilato sia in byte-code indipendente dalla macchina
+in uso che funzionare con la Java Virtual Machine, o pu� essere
+compilato direttamente in codice eseguibile da un certo numero di
+piattaforme, incluse Linux, Win32 e altri.
+
+<p>
+Una comune API fornita da tutti i gli ambienti di sviluppo Java, che
+fornisce il supporto per i socket, un insieme di componenti per realizzare
+interfacce grafiche, tool per disegno grafico, eventi IO standardizzati,
+funzioni matematiche, interfacce verso database e multithreading, per
+nominarne alcuni.
+
+<p>
+Il supporto multithreading pu� avvenire sia nei kernel thread che in
+quelli utente, in base all'implementazione della
+Java virtual machine in uso.
+
+<p>
+Naturalmente, Java � anche il nome di una popolare isola dell'Indonesia:
+potete verificarlo presso la pagina
+<url id="http://www.gnu.org/software/java/java.html#TOCOriginalJava"
+ name="GNU Java">.
+
+
+
+<sect>Perch� essere curiosi di Java?
+
+<p>
+Java � largamente usato in applicazioni per serventi e clienti, distribuite su
+larga e piccola scala. È divertente da usare. Il tool javadoc crea
+documentazione da commenti nel codice, cosicch�, commentando, si ottiene la
+documentazione gratis.
+
+
+
+<sect>Cos'� un JIT?
+
+<p>
+JIT � un acronimo di Just In Time. Si riferisce ad un plugin per la
+VM che velocizza l'esecuzione della VM nella compilazione in
+bytecode del codice sorgente nativo.
+
+
+<sect>Dove trovare altre informazioni su Java?
+
+
+<p>
+Naturalmente, <url id="http://java.sun.com"> sarebbe la prima fonte
+in cui trovare informazioni su Java, dal momento che si tratta della
+compagnia che ha dato origine al progetto (Sun). Comunque, altre
+buone fonti di informazioni per Java e Linux possono essere le seguenti:
+
+
+<list>
+<item>Le pagine della Sun <url id="http://java.sun.com/linux/" name="Java Technology on Linux">.
+<item>Blackdown's <url id="http://www.blackdown.org/java-linux/docs/support/faq-release/FAQ-java-linux.html" name="Java and Linux FAQ">.
+<item>GNU <url id="http://www.gnu.org/software/java/" name="Java software">
+<item>Enterprise in a Nutshell di Gary Meyer: <url id="
+http://en.tldp.org/HOWTO/Enterprise-Java-for-Linux-HOWTO.html">.
+Qui viene spiegato come realizzare un ambiente che comprenda JDK,
+web server, servlet Java, accesso JDBC ad un database ed a EJB.
+Per chi � interessato, si veda anche Java Enterprise in a Nutshell:
+<url id="http://www.oreilly.com/catalog/jentnut/">.
+<item>Il <url id="http://www.linuxjournal.com/" name="Linux Journal Magazine">,
+vale la pena di leggere i seguenti articoli:
+<list>
+<item>Numero 105 <url id="http://www.linuxjournal.com/article.php?sid=4860"
+name="Compiling Java with CGJ">
+<item><url id="http://www.linuxjournal.com/article.php?sid=6290"
+name="Getting Started with Java on Linux">
+<item>Numero 94 <url id="http://www.linuxjournal.com/article.php?sid=5612"
+name="Embedded Linux and Java--Wave of the Future?">
+<item><url id="http://www.linuxjournal.com/article.php?sid=4819"
+name="Using and Writing Java Servlets">
+<item>Numero 66 <url
+id="http://www.linuxjournal.com/lj-issues/issue66/3119.html"
+name="Java servlets"> e <url
+id="http://www.linuxjournal.com/lj-issues/issue66/3224.html"
+name="Java 2 SDK">.
+
+</list>
+
+<item>La <url id="http://www.linuxgazette.com/" name="Linux Gazette
+Magazine">, i seguenti articoli potrebbero essere utili:
+<list>
+<item>Numero 87 <url id="http://www.linuxgazette.com/issue87/jenkins.html"
+name="A Keep-Alive Program You Can Run Anywhere">
+<item>Numero 69 <url id="http://www.linuxgazette.com/issue69/peda.html"
+name="Installing Tomcat on Linux">
+<item>Numero 48 <url id="http://www.linuxgazette.com/issue48/lane.html"
+name="Linux, Java and XML">
+<item>Numero 45 <url
+id="http://tldp.org/LDP/LG/issue45/gibbs/Linux_java.html"
+name="Setting Up A Java Development Enviroment For Linux">
+<item>Numero 33 <url id="http://tldp.org/LDP/LG/issue33/burtch.html">
+<item>Numero 32 <url id="http://tldp.org/LDP/LG/issue32/rojansky.html"
+ name="Java and Linux">
+<item>Numero 25 <url id="http://tldp.org/LDP/LG/issue29/hamilton.html">
+</list>
+
+
+<!-- No longer available
+<item>Linux users worlwide includes information on how to use Java an
+Linux <url id="http://linuxusers.webprovider.com">.
+-->
+
+<!-- Pretty old and not very much maintainted ATM
+<item>Linux Java Tips and Hints at <url
+id="http://www.parnasse.com/java.shtml">.
+-->
+
+<!-- no longer available
+<item>The Java and Linux Page <url id="http://www.geocities.com/SiliconValley/Platform/8187/java/Linux_java.html">
+-->
+
+<item><url id="http://www.linuxfocus.org/" name="LinuxFocus">, un giornale libero disponibile in pi� lingue:
+<list>
+
+<item>marzo 2003: <url
+id="http://www.linuxfocus.org/English/March2003/article285.shtml"
+name="Accessing PostgreSQL through JDBC via a Java SSL tunnel">
+
+<item>gennaio 1999: <url
+id="http://www.linuxfocus.org/English/January1999/article78.html"
+name="Programming with Java, part II">
+
+<item>luglio 1998: <url
+id="http://www.linuxfocus.org/English/July1998/article57.html"
+name="Programming with Java, part I">
+</list>
+
+<item>Il Java-CGI HOWTO di David H. Silber:<url
+id="http://en.tldp.org/HOWTO/Java-CGI-HOWTO.html">
+Qui viene spiegato come impostare il proprio server in modo da far
+funzionare le CGI Java. Vale forse la pena di dare un'occhiata alle servlet.
+<item>Java Programming on Linux di Nathan Meyers,
+con sito presso <url id="http://www.javalinux.net/">, libro dedicato
+all'uso di Java in Linux (anche se non c'� una sua versione in linea).
+
+</list>
+
+Altri siti web riguardanti Java potrebbero essere:
+<list>
+<item>The Java Lobby <url id="http://www.javalobby.org">.
+<item>Brewing Java: un piccola guida, presso <url
+id="http://metalab.unc.edu/javafaq/javatutorial.html">.
+
+</list>
+
+Per informazioni gratuite su Java, si pu� consultare la rete con Google; per
+applet con codice sorgente,
+<url id="http://javaboutique.internet.com/javasource.html">.
+Si veda anche <ref id="free"> per puntatori disponibili alle piattaforme
+java gratuite, che potrebbero anche non essere riportati nelle pagine GNU in
+rete dedicate a Java.
+
+
+<sect>Dove posso fare domande su java in Debian?
+
+<p>
+Il posto giusto dove porre domande �
+<email>debian-java at lists.debian.org</email>. È possibile
+iscriversi presso la pagina delle
+<url id="http://www.debian.org/MailingLists/subscribe"
+ name="iscrizioni alle mailing list">.
+
+
+
+
+<chapt>La situazione di Java in Debian GNU/Linux 3.0 (Woody)
+
+
+
+<sect>Dove sta andando Java?
+
+<p>
+Innanzitutto, � fondamentale capire che la strategia nella concezione di
+Debian � di ottenere una piattaforma che sia al 100% software libero.
+Per questo motivo, alcuni dei tool non sono disponibili
+
+<footnote>
+Notevoli i port su Linux del Sun Java Developer Toolkit (SDK) o del
+Java Runtime Environment (JRE) di Blackdown.
+Per quelli che si possono recuperare da Blackdown, si veda in
+<ref id="blackdown-pack">.
+
+</footnote>
+
+nella distribuzione standard di Debian per motivi concernenti le licenze e
+non per motivazioni tecniche (si veda in <ref id="license-concerns">).
+
+<p>
+Detto questo, sostanzialmente tutte le tecnologie sulle quali ci si
+volesse informare possono essere o sono disponibili per Debian da subito.
+Per rispondere in modo costruttivo ai perch� di questa questione, �
+opportuno inquadrarla nella prospettiva di disponibilit�
+Open Source.
+
+<p>
+Per chi � <em>veramente</em> interessato, si consiglia di leggere: <url
+id="http://lists.debian.org/debian-java/1999/debian-java-199912/msg00015.html">
+e <url
+id="http://lists.debian.org/debian-java/1999/debian-java-199910/msg00017.html">.
+Questa sezione � un sunto delle informazioni in essi contenute.
+
+
+<sect>È disponibile un compilatore Java1 (da .java a .class)?
+
+
+<p>
+Esiste il Kopi Java Compiler, scritto in Java ed il super veloce
+Jikes scritto in C++.
+
+<p>
+Gcj pu� anche compilare i .java in .class. Attualmente la versione CVS
+gestisce le classi interne come ogni altro costrutto jdk 1.1, ma potrebbe
+non essere in grado di compilare un programma complicato
+come l'elaboratore XSL xt.
+È scritto in C, quindi � abbastanza veloce;
+genera bytecode abbastanza buono e naturalmente l'essere in grado di
+utilizzare lo stesso compilatore da .java a .class e da .java a codice
+nativo ha i suoi vantaggi.
+
+
+<sect>È disponibile Java1 JVM o JIT?
+
+<p>
+Kaffe 1.0.5 � completo in gran parte ed ora include il supporto per
+RMI. Non � chiaro se la serializzazione di Kaffe abbia in tutti i casi la
+"compatibilit� binaria" con le implementazioni di Sun; per questo
+motivo, � possibile che si presentino problemi di interoperabilit�.
+Kaffe � dotato di una estesa libreria di classi.
+
+<p>
+È disponibile anche Japhar.
+
+<p>
+libgcj (la libreria run-time per gcj) adesso include interprete e
+ClassLoader.
+
+<p>tya, un compilatore JIT, � adesso disponibile.
+
+
+<sect>È disponibile un compilatore nativo Java1?
+
+
+<p>
+GCC, la GNU Compiler Collection include GCJ, il compilatore Gnu per Java.
+
+
+<sect1>Compilatore nativo Java2
+
+
+<p>
+Non � chiaro se il compilatore nativo si riferisca alla capacit�
+adattiva di JIT in Java2 o ad un compilatore che interpreti la
+semantica di Java2. In entrambi i casi, la strategia del JIT di Kaffe
+non � adattiva ma � correttamente performante e si pensa che,
+perfezionandolo, il Jikes compiler di IBM possa interpretare i
+concept Java2 cos� come i riferimenti deboli.
+
+
+
+<sect>Debian ha le fondamentali librerie Java2?
+
+
+<p>
+Molti di questi componenti sono stati clonati sotto licenze
+per software libero. Kaffe fornisce molte di queste routine,
+compresa un'implementazione RMI up-to-date. Comunque, ci sono
+senza dubbio dei difetti. Swing, per quanto se ne sappia,
+non � stato clonato.
+
+
+
+<sect>È disponibile un debugger Java (equivalente a jdb)?
+<p><package>jswat</package>
+
+
+<p>
+Gdb pu� fare il debug del codice nativo prodotto da Gcj. Stuart Grossman
+(Cygnus) ha anche scritto un supporto a Gdb per il debug di altre VM
+utilizzando JVMDI. Quest'ultimo non � ancora stato rilasciato, perch�
+gli internals di Gdb sono stati cambiati contemporaneamente e nessuno ha avuto
+la possibilit� di reintegrare i cambiamenti. Probabilmente � possibile
+che Cygnus rilasci il vecchio codice, nel caso qualcuno fosse
+interessato a studiare il modo di farlo funzionare con gli attuali
+internals di Gdb (un lavoro di una difficolt� non trascurabile).
+
+<p>
+Si veda <url id="http://sourceware.cygnus.com/java/gdb.html"> su come fare
+il debug di programmi Java compilati con gcj.
+
+
+
+<sect1>Quali sono gli editor interattivi/grafici,
+liberi, disponibili in Debian?
+
+<p>jde, ddd, altri?
+
+<p>
+Una delle pi� interessanti caratteristiche di jde � l'autoindentazione e
+l'evidenziazione della sintassi, ma supporta anche il
+debugging e la compilazione.
+
+
+<sect1>Problemi conosciuti
+
+<p>
+La mia versione di <prgn>jdb</prgn> (versione jdb del 01/06/1998) termina
+dopo la fine dell'esecuzione di un programma e devo resettare tutti
+i breakpoint se intendo eseguire di nuovo il programma. Ci� rende l'uso
+di jdb particolarmente frustrante. Jdb non � in grado di scrivere
+(facilmente) i valori in un array che abbia pi� di tre elementi.
+Ddd mi permette di aggirare questi problemi.
+
+<p>
+<prgn>ddd</prgn> 3.1 e precedenti andavano in "sospensione" quando
+ricevevano certi inserimenti con strani nomi di thread da jdb. Ci�
+rende l'uso di ddd assieme a jdb estremamente difficoltoso.
+Questo problema � stato risolto con ddd 3.2. Pare che ddd 3.2 non sia
+ancora stato pacchettizzato. Temo che la versione pacchettizzata corrente
+di ddd non funzioni con jdb.
+
+
+<sect>È disponibile un tool appletviewer?
+
+<p>
+Ci sono molte possibilit� per quanto riguarda i programmi appletviewer:
+
+<list>
+<item>Blackdown appletviewer (in jdk1.1).
+<item>Kaffe's appletviewer.
+<item>Ibm appletviewer (in ibm-jdk).
+</list>
+
+
+<sect>È disponibile un tool Jar?
+
+<p>
+<package>FastJar</package> che � davvero molto veloce.
+<package>Kaffe</package> ha anche un tool jar.
+
+
+<sect>È disponibile un tool Javadoc?
+
+<p>
+<package>doc++</package> pu� funzionare con C++ e Java.
+In pi�, ci sono i pacchetti <package>gjdoc</package> e
+<package>gjdoc-native</package>.
+
+
+
+<sect>Debian supporta Enterprise Java Beans (EJB)?
+
+<p>
+C'� attivit� in questo campo: degna di nota pi� di tutte �
+l'implementazione Open Source EJB di Bull, in Francia, che prende
+il nome di Jonas. Ho lavorato con questo sistema e posso dire che
+fornisce un buon inizio per avere le funzionalit� di un EJB completo.
+Fornisce, in particolare, un monitor transazionale e
+un'implementazione di persistenza basata sul tipo di contenitore. Ho usato
+questo sistema su Linux con database liberi come Postgresql.
+Non sono in grado di rendere il sistema interamente funzionante
+con Kaffe. Inoltre, il sistema dipende da molte API della Sun
+che non sono ancora state clonate (JTA, JNDI e EJB stesso).
+
+
+
+<sect>Cos'� JAIN?
+
+<p>
+Sembra essere un sistema che controlla infrastrutture di comunicazione
+integrate su larga scala, modificando gli eventi con tali reti tramite
+le API di JavaBeans. Lo sforzo � grande e unisce il lavoro di molte
+organizzazioni. Si tratta di un lavoro nuovo e pare che si colleghi alla
+strategia di SCSL di Sun, che mi porta a credere che non ci sia poco di
+Open Source in questo campo. Alcuni protocolli come l'H.323, comunque,
+sono assolutamente open e anche clonati, cos� che sia possibile che grosse
+parti del sistema JAIN possano esistere in modo sparso. Non si sa nulla di
+una seria implementazione con software libero di RTP o delle infrastrutture
+H.323 in Java.
+
+
+
+<sect>Cos'� Jini?
+
+<p>
+Jini presenta un grosso problema in termini di software libero. Jini �
+disponibile in sorgente solo da Sun e questo sorgente � disponibile solo
+sotto SCSL, che non � compatibile in nessun modo n� con i meccanismi
+legali del software libero n� tantomeno con il suo spirito politico.
+L'SCSL rende anche illegale clonare le API di un'implementazione SCSL
+che preclude ad una reimplementazione compatibile di Jini.
+Per chi fosse interessato alle implementazioni del tipo spazio di tuple,
+esistono opzioni Open Source.
+
+
+<sect>C'� una lista completa di pacchetti?
+
+<p>
+Segue una lista di pacchetti reperibili in Debian 3.0 (aka Woody), che non
+specifica quali siano inclusi in contrib o in non-free.
+
+<!-- Segue una lista di pacchetti (che non evidenzia quelli
+residenti nella sezione main) reperibili in Debian 3.0 (ovvero, Woody). -->
+
+<p>
+
+<list>
+ <item>Ambiente Virtual Machines runtime.
+ <list>
+ <item><package>jdk1.1</package> (Sun JDK 1.1.8)
+ <item>IBM JDK 1.1.8 (pacchetto con installer)
+ <item><package>kaffe</package>
+ <item><package>kissme</package>
+ </list>
+ <item>Tool
+ <list>
+ <item>Compilatori
+ <list>
+ <item><package>jikes</package> (anche <package>jikes-1.14</package>, <package>jikes-gij</package>,
+ <package>jikes-kaffe</package>)
+ <item><package>jdk1.1</package>
+ <item><package>gcj</package>
+ <item><package>tya</package> (compilatore JIT)
+ </list>
+ <item>Tool per il debugger ed il testing
+ <list>
+ <item><package>jswat</package>
+ <item><package>junit</package>
+ </list>
+ <item>IDE ed editor
+ <list>
+ <item><package>jedit</package>
+ <item><package>jde</package>
+ </item>
+ <item>Build tools
+ <list>
+ <item><package>ant</package>
+ <item><package>jmk</package>
+ <item><package>mmake</package>
+ </list>
+ <item>Altri
+ <list>
+ <item><package>fastjar</package>
+ <item><package>jad</package> (decompilatore)
+ </list>
+ </list>
+<item>Ant
+</list>
+<item>Librerie
+ <list>
+ <item><package>lib-dom-java</package>
+ <item><package>lib-gnu.getopt-java</package>
+ <item><package>lib-gnu.regexp-java</package>
+ <item><package>lib-saxon-java</package>
+ <item><package>libavalon-excalibur-java</package>
+ <item><package>libavalon-framework-java</package>
+ <item><package>libbcel-java</package>
+ <item><package>libbsf-java</package>
+ <item><package>libcrimson-java</package>
+ <item><package>libcommons-beanutils-java</package>
+ <item><package>libcommons-collections-java</package>
+ <item><package>libcommons-digester-java</package>
+ <item><package>libjdom-java</package>
+ <item><package>libjunitperf-java</package>
+ <item><package>libldap-java</package>
+ <item><package>liblog4j</package>
+ <item><package>liblogkit-java</package>
+ <item><package>libnbio-java</package>
+ <item><package>liboro-java</package>
+ <item><package>libpgjava</package>
+ <item><package>libreadline-java</package>
+ <item><package>libregexp-java</package>
+ <item><package>libservlet2.3-java</package>
+ <item><package>libservlet2.2-java</package>
+ <item><package>libsoap-java</package>
+ <item><package>libtomcat4-java</package>
+ <item><package>libxalan-java</package>
+ <item><package>libxalan2-java</package>
+ <item><package>libxerces-java</package>
+ <item><package>libxerces2-java</package>
+ <item><package>libxt-java</package>
+ </list>
+</list>
+
+
+
+<chapt>Situazione di Java in Debian GNU/Linux Testing/Unstable
+
+<sect>Ci sono molti cambiamenti?
+<p>
+Decisamente! Negli ultimi tempi per quanto riguarda java in in Debian
+ci sono state interessanti novit�; sembra che, lentamente, venga
+sviluppata una serie di strumenti volti al mantenimento di pacchetti
+Debian contenenti applicazioni e librerie Java. Al momento, pare che
+ci sia solo dh_javadoc, contenuto nel pacchetto
+<package>gjdoc</package>; tuttavia, nel gruppo di discussione su
+debian-java, nel 2003, si � parlato di altri strumenti.
+
+<p>
+Inoltre, sembra esserci anche un incentivo a includere
+<package>ant</package> in main, cosa che dovrebbe consentirvi
+l'inclusione di altri pacchetti.
+
+<p>
+Il pacchetto <package>eclipse</package> sembra piuttosto stabile; nei
+primi giorni dell'agosto 2003, la squadra del gcj � riuscita a
+compilare l'IDE in codice nativo, usando solo modificazioni di scarsa
+importanza.
+
+<p>
+Consultare, come prima cosa, la sezione su Java in Debian GNU/Linux
+Woody � molto utile (dato che i pacchetti di woody sono anche nella
+testing), ma ci sono dei cambiamenti, che vengono elencati qui di
+seguito:
+
+<list>
+ <item><package>eclipse</package> una IDE
+ <item><package>sablevm</package> una Virtual Machine
+ <item><package>free-java-sdk</package> Un Java SDK libero
+ (compilato con strumenti Java compatibili con DSFG)
+ <item><package>libgnome0-java</package> Binding Java alla libreria
+ della GUI di Gnome
+ <item><package>gjdoc</package> Un sostituto di Javadoc 1.3
+ (implementa 90% delle Doclet API)
+</list>
+
+
+<chapt>Lo sviluppo di Java
+<p>
+
+
+<sect>Quali piattaforme di sviluppo complete, per Java, sono
+ disponibili in Debian?
+
+
+<p>
+Se si stanno cercando una java virtual machine integrata, un compilatore
+ed un ambiente in runtime, Debian effettivamente li fornisce. Certo, questo
+dipende dalla versione Debian GNU/Linux che si usa, generalmente sono
+le seguenti:
+
+<list>
+<item>jdk 1.1 Sun (port a cura di Blackdown, si veda in
+ <ref id="blackdown-pack"> o presso il relativo sito web:
+ <url id="http://www.blackdown.org">)
+<item><prgn>kaffe</prgn>.
+<item>jdk di ibm (si veda in <ref id="installer">)
+</list>
+
+<p>
+Debian Sid ha il pacchetto <package>free-java-sdk</package> che
+fornisce una versione libera del Java Software Development Kit (SDK).
+Tutto il software da cui dipende � conforme alle DFSG Debian.
+
+
+
+<sect id="free">Quali piattaforme libere ci sono per Debian e come posso
+contribuire allo sviluppo?
+
+<p>
+Per chi desidera utilizzare Java su Debian c'� la possibilit�
+di aiutare nelle implementazioni libere di Java. Ci sono svariati
+progetti tra i quali si pu� scegliere:
+
+<list>
+
+<item>kaffe: <url id="http://www.kaffe.org">.
+<item>Japhar: <url id="http://www.japhar.org">. La Java virtual
+machine di "Hungry Programmer". Altre informazioni in <url
+id="http://www.hungry.com/products/japhar">.
+<item>gcj e libgcj: <url id="http://sourceware.cygnus.com/java/">
+
+<item>jikes: <url id="http://www.research.ibm.com/jikes/">. Un compilatore
+veloce scritto in C++ (si controlli anche <url
+id="http://www10.software.ibm.com/developerworks/opensource/jikes/">).
+ Sembra che le nuove licenze sia definitivamente libere
+<item>kopi: <url id="http://www.dms.at/kjc/">. Ancora un'altro compilatore
+libero per Java, scritto in Java e GPL. Incluso in Kaffe fin dalla versione
+1.0.5.
+<item>FastJar <url id="http://fastjar.sourceforge.net/">, un tool jar
+ (questo link sembra non essere corretto, suggerimenti?).
+<item>Classpath <url id="http://www.gnu.org/software/classpath/"> o
+<url id="http://www.classpath.org">.
+Molte delle classi standard per Java 1.2 (fatta eccezione per Swing e RMI)
+sono implementate dal ClassPath project, che cerca di creare
+un'alternativa all'insieme delle classi di jdk 1.2.
+<item>Molte delle classi RMI sono implementate da NinjaRMI
+<url id="http://www.cs.berkeley.edu/~mdw/proj/ninja/ninjarmi.html">.
+<item>Autoconf macros <url
+id="http://www.internatif.org/bortzmeyer/autoconf-Java/">
+� utile per una facile ricompilazione di programmi Java.
+<item>Mauve <url
+id="http://sourceware.cygnus.com/mauve/"> � una suite libera per testare
+se questi tool siano o meno compatibili.
+
+</list>
+
+<p>
+Gran parte dello sviluppo libero di Java viene svolto da gruppi
+che collaborano col <url
+id="http://www.gnu.org/software/java/" name="Free Java
+Project">. Esiste una mailing list sul Java libero: <url
+id="http://www.lists.deus.net/mailman/listinfo/free-java">.
+
+
+<sect id="license-concerns">Domande sulle piattaforme per Debian e tutto
+ci� che concerne le licenze
+
+
+<sect1>Java 2 SE (detto anche JDK1.2)
+<p>
+<sect2>Per quale motivo Java 2 SE di Sun (detto anche jdk 1.2) non �
+disponibile?
+
+
+<p>
+Ci� avviene a causa di problemi con le licenze. La seconda clausola della
+<url id="http://www.sun.com/software/communitysource/java2/license.html"
+name="licenza"> (si controllino anche le <url
+id="http://www.sun.com/software/communitysource/faq.html" name="FAQ">)
+che recita:
+
+<example>
+Il software � segreto e soggetto a copyright. I diritti sul
+software e tutti i diritti di propriet� intellettuali sono
+detenuti da Sun e/o dai possessori di sue licenze. Ad
+eccezione di speciali autorizzazioni contenute in licenze
+supplementari � possibile copiare il software in un'unica
+copia solo a scopo di archiviazione.
+</example>
+
+
+<sect2 id="scsl">Quali sono i problemi con la nuova licenza della Sun?
+
+<p>
+Sun si � spostata su un nuovo tipo di licenza, la
+<em>Sun Community License</em>, che come la GPL � una licenza virale, ma
+prende in considerazione anche argomenti come il pagamento delle licenze
+della Sun. La SCSL arriva al punto di definire qualsiasi implementazione
+di una specifica Sun come "opera modificata". Ci� significa, in sostanza,
+che chi implementa una qualsiasi parte della nuova API 1.2 o una API Jini,
+anche da zero, la Sun sar� "proprietaria" di tale implementazione e
+anche chi ha realizzato tale implementazione dovr� pagare per avere
+diritto di usufruirne.
+
+<example>
+13. "Modifica(che)" significa (i) qualsiasi cambiamento al
+ codice protetto; (ii) qualsiasi nuovo file o altra
+ rappresentazione di un'istruzione di un programma per
+ computer che contenga una parte qualunque del codice
+ protetto; e/o (iii) qualsiasi nuovo codice sorgente
+ che implementi una qualsiasi parte delle specifiche.
+</example>
+
+
+<sect2> Cosa � la SCSL?
+
+<p>
+SCSL � la "Sun Community Software License" che si pu� trovare all'URL
+<url id="http://java.sun.com/communitysource/">. Non � compatibile con
+il software libero per svariate ragioni ed accettando tale licenza (per es.
+scaricando codice sorgente coperto da SCSL) diviene impossibile
+contribuire al software libero neanche con reimplementazioni che
+partano da zero.
+Secondo la Sun, questo comprende anche l'uso della documentazione e delle
+specifiche API disponibili solo sotto SCSL.
+
+
+<p>
+Per citare uno sviluppatore Open Source, la SCSL � "pressappoco libera
+quanto la passata Unione Sovietica".
+
+<p>
+Ad ogni modo, senza sottostare alla SCSL, � ancora ammissibile,
+escludendo qualunque brevetto di Sun per la tecnologia, creare una
+propria reimplementazione della versione 1.2 dell'API. È
+importante non accettare mai tale licenza, neanche per la
+documentazione. Per esempio, nel caso si compri un libro stampato
+che descriva l'API, esiste un lungo precedente legale (per lo meno,
+negli Stati Uniti), che proibisce di allegare questo genere di
+contratti ai libri.
+
+
+<sect2>È possibile usare jdk1.2 lavorando con le implementazioni
+libere di Java?
+
+<p>
+La Clausola numero 1 delle Supplemental License Terms recita:
+
+<example>
+ Non si possono creare o autorizzare i concessionari di licen_
+ za a creare classi addizionali, interfacce, o sotto pacchetti
+ che siano contenuti nei pacchetti "java", "Sun" o simili,
+ come specificato da Sun, in ogni convenzione che d� il nome
+ ai file delle classi;
+</example>
+
+<p>
+Questo, pare eviti che chiunque faccia implementazioni proprie
+degli standard delle classi Java utilizzando le JDK.
+
+<p>
+Non � chiaro, comunque, se la parola "addizionale" includa o meno le
+reimplementazioni di classi esistenti o se si applichi solo alle
+classi che portano nuovi nomi.
+
+
+
+<sect2>Perch� (alcuni) software liberi non implementano Java2?
+
+<p>
+Sun ha dichiarato pubblicamente, in riferimento alla propria strategia per
+l'azione legale Sun-Microsoft, che la compagnia considera le specifiche
+pubblicate di Java2 come una propriet� intellettuale che non pu� essere
+legalmente usata da persone coinvolte in tentativi di creare
+reimplementazioni di Java2. Per questo motivo alcuni progetti Open Source
+hanno deciso di non implementare Java2, per il momento. Un esempio � Kaffe.
+Alcuni progetti (come il Japhar/Classpath project) hanno deciso di
+sfidare la posizione legale di Sun procedendo con l'implementazione di Java2.
+
+
+<sect1 id="ibm-jdk1.1">La jdk1.1 di IBM
+<P>
+<sect2>Debian pu� distribuire la jdk1.1 di IBM?
+<p>
+Pare di no. Di seguito la licenza:
+
+<example>
+Program Code
+
+Consiste nella IBM Developer Kit per Linux(R), Java(tm)
+Technology Edition, versione 1.1.8, in forma di codice
+binario, cos� come modificato da IBM per funzionare sui
+sistemi operativi RedHat(R), 6.0 Linux o Caldera(R)
+OpenLinux 2.2. Il Program Code consiste nella Java
+virtual machine, nelle Java platform core classes e nei
+file di supporto (detti anche Java Runtime Environment
+o JRE), nel Java ToolKit, nella documentazione e i Java
+Samples. Program Code pu� comprendere documentazione
+soft copy, file readme, program data e simili.
+
+È possibile utilizzare il Program Code solo se si �
+in possesso di una licenza dei sistemi operativi Linux
+Redhat 6.0 o Caldera OpenLinux 2.2 e il Program Code �
+utilizzabile solo insieme a questi prodotti.
+</example>
+<p>
+Si veda il bug #54641 per un problema circa il JDK IBM. È possibile
+scaricarlo da <url id="http://www.ibm.com/java/jdk/118/linux">.
+
+
+<sect2>C'� la possibilit� di ottenere una licenza per Debian 2.1?
+
+
+<p>
+Non sarebbe libera, per il punto 8 della DFSG: "Le licenze non possono
+essere specifiche per Debian".
+
+
+<sect1>JRE
+<p>
+<sect2>Debian pu� distribuire JRE?
+
+<p>
+(da Gene McCulley: <url
+id="http://lists.debian.org/debian-java/1999/debian-java-199908/msg00021.html">).
+Non penso che si possa voler distribuire il JRE con Debian. I termini
+supplementari della licenza del JRE hanno alcune clausole piuttosto
+antipatiche:
+
+<example>
+ 1.Licenza per la distribuzione. Viene concesso il diritto
+ di riprodurre e distribuire, libero da royalty, il
+ software fornito che venga: (i) distribuito come
+ software completo e non modificato, solo come parte di
+ e all'unico scopo di far funzionare una propria applet
+ Java o un'applicazione ("programma") in cui il software
+ sia incluso;
+</example>
+
+<p>
+Si potrebbe passarla liscia con questa clausola, dal momento che lo
+distribuiamo insieme alle applicazioni Java che fanno parte di Debian.
+Ma occorre anche consentire a chiunque di scaricare il solo il pacchetto jre.
+
+<example>
+ (ii) non distribuire software aggiuntivo inteso come
+ sostituto di qualunque componente del software;
+</example>
+
+<p>
+Non � possibile acconsentire su questo punto. L'intenzione � di distribuire
+Kaffe, Japhar, Classpath, Gcj, Kopi, Fastjar, ecc. che intendono sostituire
+il JRE con una sua versione libera. Anche se non si considerasse
+una parte non libera di Debian (il JRE non andrebbe nella principale :)),
+ritengo che non si dovrebbe incoraggiare il software che cerca di
+prevenire sostituzioni libere.
+
+<example>
+ [...](v) non si possono creare, o autorizzare i concessionari
+ di licenza a creare classi addizionali, interfacce, o
+ sottopacchetti che siano contenuti nei pacchetti "java", "Sun"
+ o simili, come specificato da Sun in ogni convenzione che d�
+ il nome ai file delle classi;
+</example>
+
+<p>
+L'esempio riportato precedentemente, sul motivo per cui questa sia
+una cattiva clausola non era cos� centrato, dal momento che
+qualcuno ha notato che non si vuole creare qualcosa che non sia
+standard. Concordo col fatto che si desideri un'implementazione
+standard del nucleo delle classi, ma ritengo anche che si
+dovrebbe essere liberi di creare classi non standard (oppure
+fissare bug e stupidi errori nelle classi standard).
+
+<example>
+ [...] e (vii) acconsentire a risarcire, a rendere inoffensivi
+ e difendere Sun e chi rilascia le licenze, da qualsiasi
+ rivendicazione o azione legale, comprese le spese legali, che
+ derivano o sono il risultato dell'uso o della distribuzione
+ del programma.
+</example>
+
+
+<p>Non credo che Debian (o SPI) possa o voglia far questo.
+<p>
+
+<p>
+Sono perci� dispiaciuto del fatto che non si possa distribuire il JRE
+di Sun o di Blackdown; ci� non � negativo, dal momento che si tratta di
+software non libero, ma � seccante. Come gi� detto prima, � necessario
+aiutare uno dei (tanti) progetti di Java liberi se si desidera vedere
+una JVM libera, delle classi standard, un compilatore ecc. in Debian.
+Sono lungi dall'essere completi, ma funzionano per la maggior parte degli
+scopi.
+
+<sect1>GPL or LGPL?
+<p>
+Java usa un linking dinamico al runtime. Usando una reflection API ed un
+caricatore di classi, il linking pu� essere guidato completamente dai dati,
+specificando classi e metodi tramite i nomi. Ci� crea problemi legali
+nell'uso del codice Java sotto GPL in possesso dell'utente, come una
+violazione della GPL non pu� essere dimostrata dall'eseguibile stesso. A
+differenza dei plugin, le classi Java non devono avere una struttura
+specifica per essere usate in questo modo. Usando metodi nativi e
+selezionando le DLL al runtime, questo problema pu� essere riscontrato
+anche nel codice nativo.
+
+<P>
+Esempio: un checker di dipendenza Java sotto GPL che usa una reflection API.
+Il collegamento al runtime di Java, in particolare la reflection API, rende
+illeggibili le istruzioni tra codice e dati anche pi� dei plugin nativi
+esemplificati.
+
+<p>
+Chi desidera scrivere codice Java che possa essere usato senza che l'utente
+debba preoccuparsi di problemi relativi alle licenze, pu� prendere in
+considerazione la Lesser GPL (LPGL). Questo per evitare di vedere le
+proprie classi ed i propri pacchetti utilizzati come software non libero.
+
+
+<sect>Come si crea un programma Java, con interfaccia grafica, compatibile
+ con DFSG?
+
+<p>
+Molti programmi Java usano la libreria Swing per lo sviluppo di interfacce
+grafiche; per questo c'� <package>libswing-java</package>.
+La maggior parte dei programmi si compilano tramite questa libreria,
+ma ci� non ne garantisce il funzionamento.
+Non sempre sono eseguite, o eseguite bene, tutte le classi.
+
+<p>
+Lo Standard Widget Toolkit (SWT, <package>libswt-java</package>),
+basato sulla libreria GTK+, � un'alternativa alla libreria Swing.
+
+<p>
+Una terza possibilit� � costituita da funzionalit� ad interfaccia grafica di
+KDE o GNOME. Per KDE, c'� il pacchetto kdebindings tar.gz (ci sar� anche
+un deb?), per GNOME il <package>libgnome0-java</package>.
+
+<sect1>I programmi basati su swing funzionano in Debian?
+
+<p>
+Swing funziona e pu� essere installato, da notare che le JVM 1.2 e 1.3
+includono swing; altrimenti � necessario scaricarlo per la propria
+particolare JVM. Si veda oltre, in <ref id="swing-run">, per scoprire
+come farlo funzionare.
+
+
+<sect>Creare pacchetti Debian per programmi Java.
+<p>
+
+<sect1>È possibile inserire il pacchetto in main?
+
+<p>
+S�, <em>ma solo qualora</em> possa essere creato ed eseguito principalmente con
+programmi/tool Java presenti in main ed abbia una licenza Open Source
+compatibile con Debian. Se necessita di programmi provenienti dalle sezioni
+contrib o non-free, allora <em>deve</em> essere collocato in esse, a seconda
+della propria licenza.
+
+<p>
+Pi� specificatamente, se il programma pu� essere creato ed eseguito con
+<package>free-java-sdk</package>, allora dipende solo da pacchetti
+provenienti da main. La descrizione di <package>free-java-sdk</package>
+specifica:
+"Si installi questo pacchetto, impostando JAVA_HOME in /usr/lib/fjsdk e
+cercando di ricreare i propri pacchetti Java: se funziona, i pacchetti
+possono essere spostati dalla sezione contrib alla main".
+
+
+<sect1>Quali pacchetti virtuali si potrebbero usare?
+<p>
+<list>
+<item><package>java-common</package>. È la madre di tutti i
+pacchetti Java, nella politica proposta. Contiene la Policy (Docbook),
+cos� come gli script di utility, per esempio per costruire una
+CLASSPATH da una lista di jar (sono gradite proposte).
+<item><package>java-virtual-machine</package>
+<item><package>java-compiler</package>
+<item><package>java-compiler-dummy</package>. È un piccolo
+tool utile per la transizione verso la nuova Policy, finch� tutti
+i compilatori non vi si conformeranno. Il java-compiler-dummy
+offre i seguenti servizi:
+
+<list>
+
+<item>fornisce il java-compiler, in modo tale che pacchetti
+ superiori non abbiano problemi;
+<item>imposta CLASSPATH prima di chiamare la vera VM.
+
+</list>
+<item><package>java-virtual-machine-dummy</package>. È un piccolo
+tool utile per la transizione verso la nuova Policy, finch� tutte le
+virtual machine non vi si conformeranno. Il java-virtual-machine-dummy
+offre i seguenti servizi:
+
+<list>
+<item>fornisce la java-virtual-machine, in modo tale che pacchetti
+ superiori non abbiano problemi;
+<item>imposta CLASSPATH prima di chiamare la vera VM.
+</list>
+
+</list>
+
+<sect1>C'� un buon esempio di pacchetto Debian?
+
+<p>Ci sono molti pacchetti Debian, sia di applicazioni, sia di
+librerie Java, che possono servire da buon punto di partenza, come
+esempio per farne dei nuovi.
+
+<p>A tal proposito, si controlli sul progetto pkg-java
+(pkg.java-project), presso il sito della Alioth:
+<url id="http://pkg-java.alioth.debian.org/">.
+
+<p>Si noti che ci sono molti modi per realizzare un pacchetto debian, non
+importa se tramite Ant o Makefile. Alcuni suggerimenti, utili per
+impratichirsi, sono riportati sul sito di pkg-java:
+<url id="http://pkg-java.alioth.debian.org/developers.html#rules"> e
+<url id="http://pkg-java.alioth.debian.org/building.html">.
+
+
+<sect1>Ci sono strumenti per facilitare il mantenimento di pacchetti Java?
+
+<p>Attualmente, solo dh_javadoc, presente nella distribuzione unstable
+di Debian, nel pacchetto <package>gjdoc</package>.
+
+
+
+<chapt>Compilatori Java
+<p>
+
+
+<sect>Quali compilatori Java sono disponibili per Debian?
+<p>
+
+<list>
+
+<item>
+<package>guavac</package>, il compilatore della Effective Edge Technologies.
+Questo compilatore � privo di upstream; per un corretto funzionamento si pu�
+usare gcj o jikes.
+<item><package>tya</package>, un compilatore just-in-time, usato per
+compilare codice Java in byte code.
+<item><package>jikes</package>, che viene descritto funzionare bene con
+tutte le JDK (dalla 1.1 alla 1.3); si suggerisce di usare -E quando
+si compila con <prgn>Emacs</prgn>.
+<item><package>bock</package>. Compilatore da Java a C.
+<item><package>gcj</package>. Compila sorgenti Java in codice nativo,
+codice sorgente in bytecode, o bytecode in codice nativo.
+<item><package>gck</package>. È disponibile?
+<item><prgn>kjc</prgn> � incluso in <prgn>kaffe</prgn> 1.0.5.
+Attualmente non ci sono pacchetti separati.
+
+</list>
+
+
+
+
+<chapt>Java Virtual Machines (JVM)
+<p>
+
+
+
+<sect>Quali JVM funzionano in Debian?
+
+<p>
+Attualmente, la JVM di Blackdown, quella di Sun e di Ibm funzionano con
+Debian. Per programmi semplici come quelli usati per l'insegnamento, la
+VM libera di kaffe pu� essere sufficiente. Un'altra soluzione �
+usare gcj e compilare in codice nativo, per risolvere il problema delle VM.
+
+<p>
+Tutte queste possono essere scompattate in /usr/local con link in
+/usr/local/bin: in questo modo funzionano in qualsiasi configurazione
+e versione di Debian, il solo problema potrebbe essere la presenza
+o meno di versioni delle glibc basate sulle libc5 (le versioni pi�
+vecchie di Debian non avevano il supporto alle glibc finch� non �
+stato incluso in Debian 2.1, nome in codice slink).
+
+
+<sect>Quali JVM libere sono disponibili per Debian?
+<p>
+
+<list>
+
+<item><package>kaffe</package>. Non fa funzionare tutti i programmi,
+anche se si presume che funzioni con Jigsaw (una distribuzione da 10Mb),
+si veda in <url
+id="http://lists.debian.org/debian-java/1999/debian-java-199911/msg00038.html">.
+
+<item><package>sablevm</package>.
+</list>
+
+
+<sect>Che tipo di API forniscono queste JVM?
+
+<p>
+È da notare che fornire un API non significa che tutto sia completato,
+tanto meno che lo sia in modo corretto; perfino nell'SDK della Sun, nessuno
+dei quattro difetti confermati � stato corretto. Quindi non � da disprezzare
+l'implementazione libera perch� presenta difetti o � realizzata solo in parte.
+
+<p>Molte API sono messe a confronto per GNU Classpath, GNU gcj,
+Kaffe e Wonka con
+<url name="japitools" id="http://rainbow.netreach.net/~sballard/japi/">.
+
+
+<sect>In che misura le API sono implementate dalle JVM?
+
+<p>Si d� qui un riassunto dei risultati delle prove
+
+
+<sect>Ci sono problemi noti?
+
+<p>
+S�, alcuni, segnalati come difetti relativi a Debian, si possono consultare
+sul <url id="http://www.debian.org/Bugs/" name="Debian Bug Track System">,
+sistema Debian di ricerca dei bug.
+Ecco alcuni pacchetti, come collegamento veloce:
+
+<list>
+
+<item><url id="http://bugs.debian.org/kaffe" name="kaffe">
+<item><url id="http://bugs.debian.org/gcj" name="gcj">
+<item><url id="http://bugs.debian.org/sablevm" name="sablevm">
+
+</list>
+
+<p>
+Come di norma nell'ambito del progetto Debian, gli sviluppatori apprezzano
+relazioni (bug reports) circostanziate sui problemi riscontrati. Questo
+include la descrizione del problema, il comando che lo provoca, gli errori
+causati dall'esecuzione del comando ed ogni altra informazione rilevante. Uno
+strumento appropriato per segnalare i difetti � <package>reportbug</package>.
+
+
+<sect>In Debian, per eseguire un programma java � davvero necessaria una JVM?
+<p>
+No, si pu� provare ad eseguire le applicazioni senza una jvm, basta
+compilare il codice sorgente in codice nativo.
+
+
+
+<sect1>Come compilo il codice nativo?
+
+<p>
+Si dovrebbe essere in grado di usare <prgn>gcj</prgn> o <prgn>jikes</prgn>
+(che sono entrambi programmi liberi), per compilare il programma e
+usare <prgn>gcj</prgn> per convertire bytecode in codice nativo.
+L'intera catena di software � libera.
+
+
+
+<sect1>Si tratta di un approccio riuscito?
+
+<p>Senz'altro, si veda in<url
+id="http://lists.debian.org/debian-java/1999/debian-java-199911/msg00044.html">
+come � stato fatto per il parser XML <prgn>xp</prgn>.
+<example>
+ezili:~/infosystems/XML/Java> gcj --main=UnTag UnTag.java UnTagHandler.java
+/usr/share/java/repository/org/xml/sax/helpers/*.class
+/usr/share/java/repository/org/xml/sax/*.class /usr/share/java/repository/com/j
+clark/xml/sax/*.class /usr/share/java/repository/com/jclark/xml/parse/*.class
+/usr/share/java/repository/com/jclark/xml/tok/*.class
+/usr/share/java/repository/com/jclark/util/*.class
+/usr/share/java/repository/com/jclark/xml/parse/base/*.class
+</example>
+
+<sect1>Ci sono stati problemi con tale approccio?
+
+<p>
+S�, ci sono stati anche alcuni problemi.
+
+<p>
+<prgn>gcj</prgn> non supporta completamente JNI. Tom Tromey � il
+responsabile per l'implementazione di JNI. Nell'aprile del 2000
+mancava ancora un aspetto (non si pu�, attualmente, compilare un
+file .class che usa funzioni JNI per implementare i suoi metodi
+nativi), ma Tom ci sta lavorando e spera di completarlo "presto".
+
+<p>
+Il fatto che manchi JNI incide sull'uso di Classpath (per es. come
+alternativa a libgcj) cos� come una piccola applicazione standalone
+che sostituisca AWT con qualche GUI veramente semplice (come l'uso di
+curses, per es. per piccoli installer). Incide anche sui progetti che
+hanno codice nativo per motivi di performance. Al momento, gcj forza
+in sostanza una porta CNI. L'unica alternativa di cui siamo certi �
+TowerJ, che pu� andare bene per progetti commerciali, ma non offre
+nulla al software libero.
+
+
+<sect1>Funziona con architetture diverse dall'i386?
+
+<p>È possibile di no, dal momento che libgcj non funziona su sparc
+e nessuno ci ha provato.
+
+
+
+<chapt>Plugin Java per browser
+
+<p>La prossima sezione descrive come utilizzare Java all'interno dei
+browser, per eseguire le <tt>applet</tt> pubblicate nei web server.
+
+<sect>Si pu� usare qualsiasi JVM come plugin Java?
+
+<p>
+Questa � una domanda problematica. La mia risposta �: "In genere no,
+ma tentar non nuoce" (non si tralasci di inoltrare le proprie scoperte,
+per consentire l'aggiornamento di questo scritto).
+
+
+<sect>Si pu� usare Java in Konqueror?
+
+<p>
+In Konqueror 3.1.1, s�, dal menu Preferenze->Navigazione
+web->browser Konqueror: il Modulo di Controllo, reso open,
+ha un sezione Java&JavaScript in cui scrivere la
+collocazione della propria JVM.
+La configurazione dovrebbe somigliare a:
+
+<list>
+ <item>"Abilita java globalmente" - Selezionato
+ <item>"Mostra la console Java" - Selezionato
+ <item>"Percorso dell'eseguibile Java" indicante /usr/bin/java
+</list>
+
+<p>
+Dicendo <file>/usr/bin/java</file> ci si affida al meccanismo
+dell'<prgn>update-alternatives</prgn> per puntare ad una
+JVM che funzioni da plugin. Se si � installato J2RE, il
+"percorso di Java" potrebbe anche essere
+<file>/usr/local/j2sdk1.4.1/jre/bin/java</file>.
+
+
+<sect>Si pu� usare java in Netscape 6.x/7.x?
+
+<p>
+S�: basta creare un link simbolico verso il plugin per Java
+nella <file>/path/to/netscape/plugins</file>, come si evince nel
+J2RE della Sun:
+<example>
+/usr/local/netscape/plugins $ ls -la
+total 960
+drwxr-sr-x 2 root staff 4096 Apr 30 09:46 .
+drwxr-sr-x 9 root staff 4096 Apr 8 20:26 ..
+-rw-r--r-- 1 root staff 2363 Feb 8 07:47 ShockwaveFlash.class
+-rw-r--r-- 1 root staff 946108 Feb 8 07:47 libflashplayer.so
+lrwxrwxrwx 1 root staff 64 Apr 30 09:46 libjavaplugin_oji.so -> /usr/local/j2sdk1.4.1/jre/plugin/i386/ns610/libjavaplugin_oji.so
+-rwxr-xr-x 1 root staff 19396 Feb 8 07:47 libnullplugin.so
+</example>
+
+<p>
+Se si � installato J2RE di Blackdown, il link simbolico deve essere
+creato verso
+<file>/usr/lib/j2se/1.4/jre/plugin/i386/mozilla/javaplugin_oji.so</file>.
+
+<sect>Si pu� utilizzare Java in Mozilla 1.x?
+
+<p>S�, seguendo un procedimento identico a quello adottato per Netscape
+- la cartella dei plugin, per�, in questo caso sar�
+<file>usr/lib/mozilla/plugins</file>.
+
+
+
+<chapt>Servlet Java
+<p>
+<sect>Come far funzionare le servlet Java?
+<p>Si pu� usare:
+<list>
+ <item><package>gnujsp</package>
+ <item>Apache <package>jserv</package>. <url id="http://java.apache.org/jserv/index.html">.
+ <item>Apache <package>tomcat</package> da
+ <url id="://jakarta.apache.org/tomcat/">.
+</list>
+Altri non pacchettizzati per Debian, ma che presto saranno inclusi, sono:
+
+<list>
+
+<item>jigsaw da <url id="http://www.w3.org/Jigsaw/">.
+<item>Jetty <url id="http://mortbay.com/software/Jetty.html"> (testato
+con successo su una macchina con un sistema Debian Potato)
+
+</list>
+
+
+<sect>Le servlet funzionano con kaffe?
+<p>
+La <file>servlet.jar</file> in Kaffe non funziona. È solo una shell.
+Esiste un'altra implementazione LGPL scritta da Paul e Mark Wielaard.
+Disponibile in <url id="http://www.euronet.nl/~pauls/java/servlet">
+dovr� essere (lo � stato?) aggiunto il pacchetto Apache JServ in modo
+tale che l'utente non debba scaricare nuovamente le classi Sun.
+
+
+<sect>È necessaria una versione di Java non libera per far funzionare
+le servlet?
+
+<P>Nessuna conosciuta. Possibilmente, no, ma � necessaria una spiegazione.
+
+
+
+
+<chapt>Le politiche di Java
+<p>
+<sect>È disponibile una politica Java per Debian?
+
+<p>
+È ancora in fase di elaborazione. L'attuale linea di condotta si
+rivolge solo ad <em>alcuni</em> problemi e non � stata rilasciata
+ufficialmente: � reperibile all'indirizzo
+<url id="http://www.debian.org/doc/packaging-manuals/java-policy/"> ed
+anche nel pacchetto <package>java-common</package>.
+
+
+
+<sect>Ci sono delle imperfezioni nella politica di Java?
+
+<p>
+S�, su alcuni punti la discussione � aperta. Per favore, si veda in
+<url id="http://bugs.debian.org/java-common" name="bugs against the
+java-common package">. Cos� � <em>veramente</em> sconveniente
+usare diversi compilatori di virtual machine
+prima che sia impostata la CLASSPATH per ognuno di essi.
+
+
+
+
+<chapt>Altre alternative Java per Debian
+<p>
+Se i pacchetti Java forniti in Debian non fossero sufficienti alle nostre
+esigenze, si potrebbe aver bisogno di cercare delle alternative.
+Occorre comprendere che queste alternative non sono supportate dal
+progetto Debian direttamente, ma � possibile trovare supporto dalla
+mailing list debian-java in caso ci fossero problemi.
+
+<p>
+Alcune di queste alternative utilizzano pacchetti Debian, cosa che non crea
+problemi, dal momento che l'utente o l'amministratore non devono
+preoccuparsi per problemi nell'installazione. Ad ogni modo, mischiare
+pacchetti che provengono da sorgenti che non sono del progetto Debian
+potrebbe, a volte, causare conflitti con l'installazione. Naturalmente,
+Debian cerca di integrare pi� software libero possibile, in modo che
+alcune delle alternative descritte qui sotto possano (licenza permettendo)
+essere incluse in Debian in un prossimo futuro.
+
+
+
+<sect id="blackdown-pack">Come procurarsi pacchetti da BlackDown
+
+<p>
+Se la release fornita non � sufficientemente recente, �
+possibile installare i file scaricati dai mirror di Blackdown.
+È possibile anche usare i pacchetti Debian forniti da
+Blackdown o scaricare i file tar.
+
+<p>
+(contributo di Federico Mennite) Se si desidera utilizzare i loro pacchetti,
+occorre aggiungere la seguente riga
+
+<footnote>
+È necessario usarne una sola, potrebbe essere per
+<em>potato</em> o <em>woody</em>, in base alla versione di Debian
+in uso, o potrebbe anche essere <em>testing</em> o <em>unstable</em>
+se si tratta di una release in sviluppo.
+</footnote>
+
+in <file>/etc/apt/sources.list</file>:
+
+<example>
+deb proto://url/debian potato main non-free
+deb proto://url/debian woody main non-free
+deb proto://url/debian testing main non-free
+deb proto://url/debian unstable main non-free
+</example>
+
+<p>
+Dove <em>proto://url</em> � uno dei mirror disponibili dalla lista
+in <url id="http://www.blackdown.org/java-linux/mirrors.html">.
+
+<footnote>
+È necessario l'archivio <em>main</em>, dal momento
+che ora l� c'� un pacchetto <package>j2se-common</package>.
+Se sono gi� state installate le j2sdk quando non esistevano
+le dipendenze di cui sopra, si otterranno dei warning
+quando vengono eseguiti i comandi <prgn>apt-get update</prgn>
+o <prgn>apt-get upgrade</prgn>.
+</footnote>
+
+Ad esempio, in Debian 3.0, che usa il mirror di Metalab si usa:
+
+<example>
+deb ftp://metalab.unc.edu/pub/linux/devel/lang/java/blackdown.org/debian woody main non-free
+</example>
+
+<p>Poi:
+
+<example>
+$ apt-get update
+$ apt-get install j2sdk1.3
+</example>
+
+<P>Si noti che, al momento della stesura di questo scritto, ci
+sono pacchetti di Blackdown, in fase beta, solo per la versione
+<em>unstable</em> di Java 1.4.
+
+
+<p>
+(contributo di Paul Reavis) Scaricare e installare le JDK dai
+file tar.gz, scompattarli in <file>/usr/local/jdk1.1.x</file> e
+usare dei link simbolici per creare <file>/usr/local/jdk</file> ed i
+link ai binari in <file>/usr/local/bin</file> o equivalenti.
+Non � affatto difficile fare tale installazione. Ad ogni modo,
+si possono avere dei segfault in alcuni casi, a seconda delle
+librerie che si hanno.
+
+<p>
+Ecco una lista dei rilasci che certamente funzionano con ciascuna
+versione di Debian e di tutto il software necessario perch�
+funzionino, se esiste.
+
+<list>
+<item>rex/bo: 1.1.5v7 (libc5).
+<item>hamm:1.1.5v7 (glibc), ha bisogno dell'ultima glibc di slink.
+<item>slink: 1.1.6-test2 (glibc).
+</list>
+
+
+<sect1 id="swing-run">Far funzionare swing in Debian
+
+
+<p>
+(da Paul Reavis) [Una cosa fatta in fretta per far s� che
+Swing funzioni davvero sotto Debian o qualsiasi altro Linux]
+
+<p>
+S�, funziona con le JDK Linux; Swing � al 100% Pure Java (tm)(c)(SFD)
+e per questo dovrebbe andare con qualsiasi JVM compatibile.
+Reavis lo ha ottenuto convertendo un'applicazione commerciale
+(350 e pi� classi) in un'interfaccia grafica totalmente Swing.
+Io non ho avuto alcun problema.
+
+<p>
+Chi usa la jdk 1.1.3 o inferiori, ha solo bisogno dei file class.
+Perci� la cosa pi� semplice da fare � prendere la distribuzione
+solaris in formato tar.Z da javasoft. In base alla fase lunare, viene
+chiamato swing o JFC 1.1 (per distinguerlo dall'1.2, che � parte di
+Java 1.2). La versione attuale � Swing 1.2 (da non confondersi con
+Java 1.0.2!). Se si usa jdk 1.2.2 non si deve scaricare Swing (�
+gi� integrato nella jdk).
+
+<p>
+Non ho l'archivio sotto mano, cos� lo chiameremo
+swing.tar.Z. Si consiglia di installarlo in /usr/local cos�:
+
+<example>
+ skronk# cd /usr/local
+ skronk# tar xzf /tmp/swing.tar.Z
+</example>
+
+<p>
+Ora � necessario avere una directory /usr/local/swing. Per fare un test,
+assicurarsi che la propria variabile JAVA_HOME sia impostata, che
+CLASSPATH invece non lo sia e far andare lo script "runnit" in ciascun
+esempio. Giusto per essere terribilmente ovvi, si agisca in questo modo:
+
+<example>
+ skronk$ cd /usr/local/swing/examples/SwingSet
+ skronk$ echo $JAVA_HOME
+ /usr/local/jdk
+ skronk$ unset CLASSPATH
+ skronk$ echo $CLASSPATH
+
+ skronk$ ./runnit
+</example>
+
+<p>
+Naturalmente le directory, il prompt della shell e le esperienze fatte
+potranno differire.
+Per utilizzare le proprie applicazioni, basta aggiungere gli jar che
+servono al proprio classpath.
+
+
+
+<sect1>Far funzionare Java 2 in Debian
+
+<p>
+Se si desidera usare la jdk 1.2 di Sun o di Blackdown in Debian, occorre
+scaricare i pacchetti forniti da Blackdown (disponibili in directory
+usabili da <prgn>apt</prgn>) dai diversi mirror disponibili qui:
+<url id="http://www.blackdown.org/java-linux/mirrors.html">
+(si controllino le subdirectory debian).
+Attualmente ci sono pacchetti i386 per le Java SDK e RE, JAI, Java3D e
+JMF. È raccomandato seguire questo metodo, per ulteriori
+informazioni si veda in <ref id="blackdown-pack">.
+
+<P><em>O</em>, se si desidera fare da soli e scaricarsi gli
+archivi (quindi tar.gz e non pacchetti .deb), si pu� anche seguire
+quest'altra strada:
+
+<list>
+<item>Creare una directory in <file>/usr/local</file>
+ (per esempio <file>/usr/local/sun</file>).
+<item> Scaricare l'archivio in questa directory e scompattarlo. Verr�
+ creata una directory jdk1.X
+ <footnote><em>X</em> dipender� dalla versione del Java 2
+ state trasferendo, potr� essere 1.2.1, 1.2.2, 1.3 o
+ persino 1.4</footnote>.
+<item> Sistemare le alternative perch� funzioni correttamente:
+<example>
+ update-alternatives --install /usr/bin/javac javac /usr/local/sun/jdk1.2.2/bin/javac 120
+ update-alternatives --install /usr/bin/java java /usr/local/sun/jdk1.2.2/bin/java 120
+</example>
+<item> Controllare le proprie alternative con "type"
+<example>
+ type javac
+ type java
+</example>
+</list>
+
+A questo punto si dovrebbe avere un ambiente jdk 1.X perfettamente
+funzionante, inclusi una virtual machine ed un compilatore.
+
+<p>Potrebbe essere necessario cambiare il proprio
+ <file>/etc/profile</file> aggiungendovi le variabili d'ambiente
+ (<tt>CLASSPATH</tt>, <tt>JAVA_COMPILER</tt> and <tt>JAVA_HOME</tt>)
+ che i programmi Java cercheranno nell'installazione. Il seguente
+ esempio mostra come impostare le cose nel caso aveste il jdk
+ 1.2.2 della Sun:
+
+<example>
+# JDK 1.2.2 (.tar)
+export CLASSPATH=.:/usr/local/sun/jdk1.2.2/lib:/usr/local/sun/jdk1.2.2/jre/lib
+export JAVA_COMPILER=javacomp
+export JAVA_HOME=/usr/local/sun/jdk1.2.2
+export PATH=$PATH:/usr/local/sun/jdk1.2.2/bin
+</example>
+
+<p>
+Nota: Come Juergen Kreileder mi ha correttamente fatto notare, il nome
+preferenziale per versioni >= 1.2 � Java 2 SE (Standard Edition).
+La jdk1.3 ora si chiama "Java2 SDK v1.3" o "J2SDK 1.3".
+La jre1.3 ora si chiama "Java2 RE v1.3" o "J2RE 1.3".
+
+
+
+
+
+<sect>Come integrare J2SE SDK con Debian Testing?
+
+<p>
+Ce lo spiega Warren Dodge: anzitutto, scaricare i componenti di J2SE
+SDK da <url id="http://java.sun.com/j2se/downloads.html"> in
+<file>/var/install/java/1.4.1</file>, per esempio, assicurarsi di
+avere il permesso di scrittura sulla cartella e rendere eseguibile
+il programma d'installazione <prgn>./j2sdk-1_4_1_02-linux-i586.bin</prgn>;
+la sua esecuzione creer� la cartella <file>j2sdk1_4_1_02</file>, che
+pu� essere spostata in <file>/usr/local/lib</file>. Quindi, creare un
+link simbolico
+<tt>ln -s /usr/local/lib/j2sdk1_4_1_02 /usr/local/lib/jdk</tt>, che
+permette di utilizzare la collocazione pi� recente nel riferimento
+all'ambiente Java e rende molto pi� semplice un futuro aggiornamento.
+
+<p>Siccome Debian non ha un programma d'installazione di pacchetti
+per J2SE della Sun, occorre creare un pacchetto fittizio che informi
+Debian dell'avvenuta installazione di J2SE medesimo, in questo modo;
+per soddisfare le dipendenze, si dovranno usare i file di controllo del
+pacchetto fittizio forniti da <package>java-common</package>:
+
+<tt>
+cd /var/install/java
+mkdir pkg
+cp /usr/share/doc/java-common/dummy-packages/*.control /var/install/java/pkg
+equivs-build java-compiler-dummy.control
+equivs-build java-virtual-machine-dummy.control
+equivs-build java1-runtime-dummy.control
+equivs-build java2-compiler-dummy.control
+equivs-build java2-runtime-dummy.control
+</tt>
+
+Ora, in <file>/var/install/java/pkg</file> dovrebbero esserci cinque
+pacchetti installati.
+
+<p>
+Per scegliere il pacchetto da usare, fra molti che possano svolgere
+la stessa funzione, in Debian si usa il comando
+<prgn>update-alternatives</prgn> ("Java" � fornito anche da kaffe,
+Blackdown [cfr. sopra], ecc.); per maggiori dettagli, si veda
+"man update-alternatives". Per installare i programmi desiderati,
+si usi tale comando con questi ordini:
+<tt>
+update-alternatives --verbose --install /usr/bin/java java /usr/local/lib/jdk/bin/java 500 \
+ --slave /usr/share/man/man1/java.1 java.1 /usr/local/lib/jdk/man/man1/java.1
+</tt>
+
+<p>
+Per consentire la creazione di cartelle per le preferenze di sistema
+e per verificare il corretto funzionamento di <prgn>java</prgn> della
+Sun, lo si esegua una volta da root:
+<tt>
+ java -version
+</tt>
+
+
+
+<sect>Come integrare J2SE SDK della Sun con Debian Stable?
+<p>
+Con la stessa procedura descritta per Debian Testing (cfr. sopra);
+tuttavia, il pacchetto java-common della versione stable� non ha
+i file *.control, perci� occorre installare quello di testing o
+di unstable. Le versioni 0.19 e 0.20 possono essere installate
+tranquillamente e richiedono l'installazione del pacchetto
+equivs, anche la versione di stable, comunque, va benissimo.
+
+
+
+
+<sect>Altri programmi Java che non sono ancora disponibili per Debian
+
+<p>
+I programmi che non sono ancora stati pacchettizzati per Debian o che non
+hanno ancora un installer sono i seguenti. Ci sono molti programmi Java
+e questa lista non pu� dirsi esaustiva, in quanto include solo programmi
+che <em>potrebbero</em> essere pacchettizzati per Debian o quelli per i
+quali qualcuno sta preparando un installer:
+
+<list>
+
+<item>BlueJ. Un ambiente di sviluppo per Java con un editor, un compilatore,
+ una virtual machine ed un debugger. Si veda in
+ <url id="http://bluej.monash.edu.au/">
+<item>Jacob (Java Commando Base): project maintainer e visualiser
+ per Java in Emacs. Si veda in
+ <url id="http://home.pages.de/~kclee/clemens/jacob">.
+<item>Emacs in Java. Si veda in <url id="http://jemacs.sourceforge.net/">.
+<item>Netbeans developer, ora chiamato <em>Forte</em>. Basato
+ sull'architettura Javabeans. Si veda in
+ <url id="http://www.netbeans.com">. Recentemente Sun ha annunciato
+ che intende renderlo Open Source. Si veda in
+ <url id="http://www.sun.com/forte/tools4dotcom/opensource.html">.
+<item>AnyJ. Ambiente grafico per sviluppare applicazioni, applet e
+ servlet. Per maggiori informazioni:
+ <url id="http://www.netcomputing.de">.
+<item>Free Builder. Un IDE Java scritto in Java e distribuito sotto
+ GPL <url id="http://www.freebuilder.org">.
+
+<item>CodeGuide. <url id="http://www.omnicore.com">. Licenza non libera, ma
+ non ci sono spese in caso di uso non commerciale (da controllare).
+
+</list>
+
+
+
+
+<sect>Installer di pacchetti
+<p>
+<sect1 id="installer">Quali programmi Java hanno un installer?
+<p>
+<list>
+
+<item><prgn>vajava</prgn> � un IDE per Java. Lo si pu� trovare in
+ <url id="http://software.ibm.com/ad/vajava">.
+ <em>TODO: controllare il copyright</em>.
+<item><prgn>ibm-jdk1.1</prgn>. Installer per l' IBM Developer Kit per Linux,
+Java(tm) Technology Edition. Installa la versione alfa 1.1.6 dell'IBM
+Developer Kit. L'IBM Developer Kit � un ambiente di sviluppo per
+scrivere applet ed applicazioni che siano conformi al nucleo delle API di
+Java 1.1. Il suo compilatore e gli altri tool si lanciano da
+shell e non hanno un'interfaccia grafica.
+<p>
+L'IBM Developer Kit include la IBM JIT (libjitc.so), usata da tutti
+i tool predefiniti. Si veda in <url id="http://master.debian.org/~doko">.
+Necessita un aggiornamento alla 1.1.8. Sembra comunque che fornire
+un installer possa violare la loro licenza (si veda in <ref id="ibm-jdk1.1">).
+
+<item><prgn>jdk1.2-installer</prgn>. Si veda, per questo, in <url
+id="http://www.pobox.com/~julio/debian/jdk1.2-installer/">.
+Quest'ultima funziona con la versione pre-release e occorre
+fare un po' di lavoro per installare la release candidate version.
+(Aggiornamento, aprile 2000, il link sembra non essere corretto, suggerimenti?)
+
+</list>
+
+
+
+<sect1>Quali programmi Java si potrebbero sviluppare con un installer?
+<p>
+
+Un importante programma di installazione mancante � quello per
+J2SDK serie 1.4 della Sun.
+
+<p>
+Alcuni altri sono:
+
+<list>
+<item><prgn>jdk-1.2.2</prgn> SE Standard Edition
+ <url id="http://www.javasoft.com/products/jdk/1.2/download-linux.html">.
+<item><prgn>jbuilder3</prgn>. Un IDE Java da Inprise (scritto in
+java) <url
+id="ftp://ftp.inprise.com/pub/jbuilder/jb3foundation/sol_linux/">.
+Funziona bene.
+<item><prgn>netbeans</prgn>. Un altro IDE Java (anch'esso scritto in java)
+<url id="http://www.netbeans.com/"> per scrivere piccole applicazioni
+grafiche.
+
+</list>
+
+
+
+<appendix>Versioni pi� vecchie di Debian GNU/Linux
+
+<p>Questa appendice � inclusa per ragioni di carattere puramente
+storiografico e contiene informazioni fornite, di solito, nella
+FAQ (come infatti avviene!).
+
+
+<sect>Debian 2.2 "potato"
+<p>
+<list>
+
+<item>Librerie
+<list>
+<item>lib-fop-java
+<item>lib-gnu.getopt-java
+<item>lib-gnu.regexp-java
+<item>lib-openxml-java
+<item>lib-rxtx-java
+<item>lib-sax-java
+<item>lib-xp-java
+<item>lib-xslp-java
+<item>lib-xt-java
+<item>lib-dom-java
+<item>libpgjava
+<item>libgcj0
+</list>
+
+<item><package>bock</package> Bootstrap-only compiler kit per un
+sottoinsieme di Java(tm)
+
+<item><package>doc++</package> Un sistema di documentazione per C/C++ e Java
+
+<item><package>fastjar</package> un completo sostituto per le utility
+jar scritto in C sotto licenza GPL <url
+id="http://www.engr.orst.edu/~burnsbr/fastjar/"> (controllare <url
+id="http://lists.debian.org/debian-java/1999/debian-java-199908/msg00015.html">).
+
+<item><package>java2html</package> Sorgenti Java evidenziati per
+presentazioni WWW.
+
+<item><package>gcj</package> Il compilatore GNU per Java(tm).
+
+<item><package>global</package> Ricerca e consultazione di codice sorgente.
+
+<item><package>guavac</package> Un compilatore Java.
+
+<item><package>jikes</package> Un veloce compilatore Java aderente al
+linguaggio e alle specifiche delle VM.
+
+<item><package>jikes-pg</package> Jikes Parser Generator.
+
+<item><package>oo-browser</package> Object Oriented (X)Emacs Class Browser.
+
+<item><package>mmake</package> Un generatore di Makefile per programmi
+Java.
+
+<item><package>cocoon</package> Una servlet XML/XSL per publishing framework.
+
+<item><package>bsh</package> Un'ambiente Java scripting.
+<item><package>cup</package> LALR generatore parser per Java.
+<item><package>freetds-jdbc</package>. Un driver Java JDBC per MS SQL
+e Sybase.
+
+<item><package>gnujsp</package> Un'implementazione libera del
+Sun Java Server Pages (JSP 1.0)
+
+<item><package>jlex</package> Un generatore di analisi lessicali Lex-style
+per Java.
+
+<item><package>jserv</package> Un motore Java Servlet 2.0 con un modulo
+opzionale per Apache.
+
+<item><package>tya</package> Un compilatore JIT per Java.
+
+<item><package>ibm-jdk1.1-installer</package>. Installer per l'IBM
+Developer Kit per Linux, Java(tm) Technology Edition. (vedere <ref
+id="installer">).
+
+<item><package>jdk1.1</package>.JDK 1.1.x (Java Development Kit) -
+Solo runtime.
+
+<item><package>jdk1.1-dev</package> JDK 1.1.x (Java Development Kit)
+
+<item><package> biss-awt</package> Un'applicazione GUI per la
+programmazione Java in framework.
+
+<item><package>jdk1.1-native</package> JDK 1.1.x Runtime - estensioni
+dei thread nativi.
+
+<item><package>jdk1.1-native-dev</package> JDK 1.1.x - estensioni
+dei thread nativi.
+
+<item><package>vrwave</package> VRML 2.0, un browser basato su java.
+
+</list>
+
+<p>Molti editor (jed, elvis, vim, emacs, fte, xcoral, zed ....) hanno
+il supporto per la sintassi Java.
+
+<sect>Debian 2.1 "slink"
+<p>
+<list>
+<item><package>jdk 1.1.5v5</package>
+<item><package>vrwave</package>. Un browser VRML Java.
+<item><package>icq-java</package>. Un installer per programmi ICQJava.
+<item><package>jde</package>. Un Java Development Enviroment per Emacs
+<url id="http://sunsite.auc.dk/jde">.
+<item><package>jlex</package>. Un generatore di analisi lessicale simile
+allo UNIX <prgn>lex</prgn>.
+<item><package>mmake</package>. Un generatore di Makefiles per
+programmi Java. Ulteriori informazioni presso
+<url id="http://www.tildeslash.com/mmake">
+<item><package>libpgjava</package>. Una classe Java che abilita le
+comunicazioni con il database PostgreSQL usando JDBC.
+<item><package>cup</package>. Un parser simile a <prgn>yacc</prgn>.
+<item><package>ilu-javadev</package>. Header e librerie di sviluppo per
+l'Inter-Language Unification System.
+</list>
+
+
+<sect1>
+Ho installato l'ultimo pacchetto jde... cosa devo fare affinch� Emacs entri
+in jde-mode automaticamente, al caricamento di un file di codice sorgente Java?
+
+<p>
+Come viene spiegato in <file>/usr/doc/jde/README.Debian</file>, tutto
+quello che occorre fare � inserire:
+
+<example>
+ (require 'jde)
+</example>
+nel proprio file <file>~/.emacs</file>.
+<p>
+Da notare che altri pacchetti add-on per Emacs non sono abilitati in modo
+predefinito, per esempio, AucTeX.
+
+<sect>Debian 2.0 "hamm"
+<p>
+<list>
+<item><package>jdk 1.1.5v5</package>
+</list>
+
+<sect>Debian 1.3.1 "bo"
+<p>
+<list>
+<item><package>jdk 1.0.2</package>
+</list>
+
+
+
+
+<appendix id="traduzione">Traduzione
+
+<p>
+
+La traduzione del documento � stata effettuata da
+Chiara Bianchi <email/piposkj at yahoo.it/, l'aggiornamento
+alla presente versione da CarloS <email/enne.enne at tiscalinet.it/,
+la conversione in SGML e la revisione da
+Ferdinando Ferranti <email/zappagalattica at inwind.it/.
+
+</appendix>
+
+
+</book>
diff --git a/debian-java-faq/debian-java-faq.sgml b/debian-java-faq/debian-java-faq.sgml
new file mode 100644
index 0000000..f9e0689
--- /dev/null
+++ b/debian-java-faq/debian-java-faq.sgml
@@ -0,0 +1,605 @@
+<!doctype debiandoc system>
+
+<book>
+
+<titlepag>
+<title>Debian Java FAQ.</title>
+<author>
+<name>Torsten Werner</name>
+<email>twerner at debian.org</email>
+</author>
+<author>
+<name>Niels Thykier</name>
+<email>niels at thykier.net</email>
+</author>
+<author>
+<name>Javier Fern�ndez-Sanguino Pe�a</name>
+<email>jfs at debian.org</email>
+</author>
+<version>$Revision: 7431 $, $Date: 2010-06-27 23:59:00 +0200 (Sun, 27 Jun 2010) $
+
+<abstract>
+Answers to Frequently Asked Questions on Debian and Java
+(Note: some information is not up-to-date). Any changes/corrections to this
+FAQ are appreciated. Please send them to the Debian Bug Tracking System as
+described in <ref id="bugs">.
+</abstract>
+
+<copyright>
+This document may be freely redistributed or modified in any form
+provided your changes are clearly documented.
+
+This document may be redistributed for fee or free, and may be modified
+(including translation from one type of media or file format to another
+or from one spoken language to another) provided that all changes
+from the original are clearly marked as such.
+</copyright>
+
+
+</titlepag>
+
+
+<toc>
+
+
+<chapt>Introduction
+<p>
+
+<sect>Introduction to this FAQ
+
+<P>This FAQ was started by Javier Fern�ndez-Sanguino who on
+February 1st, 2000 was (bold?) enough to send a message to the debian-java
+mailing list with the subject "How about a Debian-Java-FAQ?". Of
+course, since "every idea is a responsibility" he had to do this himself
+looking through the three month-long archive of the newborn mailing list.
+
+<p>The purpose of this FAQ is to be a place to look for all kinds of
+questions a developer or user might have regarding Java as far as Debian
+is concerned. It includes license issues, development packages available,
+and programs related to building a Free Software Java environment.
+
+<p>Thanks go to all the (many) contributors from the debian-java mailing list,
+who have made this document possible. Without their knowledge this
+FAQ would not be at all possible since I only have a vague knowledge
+of what they're talking about when I browse the list.
+
+<p>Special thanks go to Paul Reavis, whose previous Debian-JDK
+informational page I used to add more information, and who made useful
+suggestions to this document. Also to Peter Moulder who revised
+thoroughly the FAQ and provided many suggestions, to Juergen
+Kreileder, maintainer of Blackdown's debian packages who pointed out
+some mistakes, and to Egon Willighagen, who has provided quite a lot
+of proper patches to update its content.
+
+<p>This document does not address issues with other Linux
+distributions, or with non-Debian-specific problems.
+
+
+<sect>Location of this FAQ
+
+<p>This FAQ is published under the Debian Documentation Project
+at <url id="http://www.debian.org/doc/manuals/debian-java-faq/">.
+The <package>java-common</package> (available at
+<url id="http://packages.debian.org/java-common">) provides an
+HTML version for offline reading. The package version does not provide Text and
+PDF versions currently (if you want them please submit a bug
+'wishlist' to the package). Also, the web version might be more up-to-date
+than the package's offline version.
+
+<sect id="bugs">Sending bugs on this FAQ
+
+<P>Please note that this FAQ is still outdated but gets updated step by step.
+
+<p> Please file bug reports against the java-common package if you find errors
+or have suggestions on how to improve this document. However, make sure you
+have read the latest online version of the english text available at <url
+id="http://www.debian.org/doc/manuals/debian-java-faq/index.html"> before
+filing a bug report. Translations, if available, and the offline version in
+the java-common package might be out of date.
+
+<sect>What is Java?
+<p>
+Java is a programming language originally developed by James Gosling at
+Sun Microsystems (which is now a subsidiary of Oracle Corporation) and
+released in 1995 as a core component of Sun Microsystems' Java platform.
+More information can be found at <url
+id="http://en.wikipedia.org/wiki/Java_%28programming_language%29"
+name="Wikipedia">.
+
+<sect>Where can I ask questions about Java on Debian?
+
+<p>The appropriate place to ask such questions is <email>debian-java
+at lists.debian.org</email>. You can subscribe at the <url
+id="http://lists.debian.org/debian-java/" name="Debian Mailing Lists"> page.
+
+<sect id="moreinfo">Complementary information
+
+<p>Users might want to access some online sources to complement the
+information available in this FAQ which might be, sometimes, too out
+of date. The main source of information is the
+<url id="http://wiki.debian.org/Java" name="Java entry"> at the Debian's wiki.
+
+<p>Since Ubuntu is based on Debian, some users might find it helpful
+to check the tips on <url id="https://help.ubuntu.com/community/Java"
+name="Installing Java"> on Ubuntu's wiki.
+
+<sect id="pending">Uncovered issues
+
+<p>This FAQ does not describe some issues due to lack of time and/or
+information. If you are able to help in any of these, please, provide
+them to the documentation maintainer:
+
+<list>
+
+<item>Information on how to use <prgn>update-alternatives</prgn> to handle
+Java and how to work with <file>/etc/java</file>.
+
+<item>Information on how to setup a fully working Servlet engine (Application
+Server) using Apache and Tomcat or information on how to setup non-free
+application servers (such as WebSphere) in Debian.
+
+<item>Specific information targeted for non-i386 users (PowerPC users and AMD64 users), some can be found in Ubuntu's wiki.
+
+</list>
+
+
+<chapt id="debian-java-lenny">Status of Java in Debian GNU/Linux 5.0 (Lenny)
+
+<sect>What is new in Lenny?
+
+<p>The <em>Lenny</em> release was the first one to provide Sun's OpenJDK
+environment (see <ref id="openjdk">). Lenny ships OpenJDK 6 with the IcedTea
+patches in version 1.1. Lenny updated GCJ to the new major version 4.3 and Ant
+to version 1.7. It provides Maven 2.0 but Maven cannot yet be used to build
+official Debian packages because it downloads random binaries from its central
+repository during build time. The java-common package provides new meta
+packages default-jdk and default-jre which declare dependencies to the
+appropriate gcj and gij packages. The new source package javatools contains
+useful helper tools for packaging Java software for Debian.
+
+<p>Thanks to the development that happened in gcj and classpath and thanks to
+the availability of openjdk many Java packages could be moved from contrib to
+main.
+
+<p>There are two new source packages glassfish and jbossas4 but they build only
+some core libraries and do not work as full JEE application servers yet. The
+main reason is that many free Java libraries are not yet packaged for Debian
+but are needed as (build) dependencies. But at least there is Hibernate 3
+available in the contrib component.
+
+<chapt id="debian-java-squeeze">Status of Java in Debian Squeeze
+
+<sect>What is new in Squeeze?
+
+<p>Squeeze ships with OpenJDK 6 and its IcedTea patches 1.8. The default ant
+version is 1.8 but there is a compatibility package with version 1.7.
+Java-common has switched to OpenJDK as the default-jdk on most architectures.
+Squeeze has updated GCJ to version 4.4. The new Debian Orbital Alignment Team
+has updated Eclipse to version 3.5.2.
+
+<p>Squeeze ships a fully working Tomcat 6 and Jetty 6 but both Glassfish and
+JBossAS 4 are still incomplete. Thanks to OpenJDK and the switch to OpenJDK as
+the default JDK even more Java packages in the contrib component (e.g.
+Hibernate 3) could be moved to main.
+
+
+<p>Maven has been updated to version 2.2 and it is accompanied by new helper
+packages: maven-repo-helper, maven-debian-helper, and several Maven plugins. It
+is now possible to build Debian packages with Maven because Debian has its own
+repository of POM files.
+
+
+<sect>What are the most important changes in the Java policy?
+
+<p>
+The -gcj packages are now deprecated but we keep them if the are good reason.
+The virtual package java-virtual-machine is gone and packages must not depend or
+recommend java-virtual-machine. Please check the policy for more details.
+
+<p>
+Javadoc packages are now expected to link their javadoc against system
+installed javadocs. This means that javadocs will now provide local
+links instead of remote links. Javadoc packages will recommend on
+other javadoc packages; this will install the dependency docs by
+default, but allow users to avoid installing a lot of large javadoc
+packages (e.g. by asking APT to not include recommends).
+</p>
+
+<sect>What have been removed in Squeeze?
+
+<p>This is an incomplete list of packages removed from Squeeze:
+
+<list>
+<item><package>kaffe</package></item>
+<item><package>cacao</package></item>
+<item><package>jamvm</package></item>
+<item><package>liblogkit-java</package> (Replaced by <package>libexcalibur-logkit-java</package>)</item>
+<item><package>liblucene-java</package> (Replaced by <package>liblucene2-java</package>)</item>
+<item><package>jmp</package> (Replaced by <package>tijmp</package>)</item>
+<item><package>pja</package></item>
+<item><package>slide-webdavclient</package></item>
+<item><package>java-package</package></item>
+<item><package>java-gcj-compat</package></item>
+<item><package>classpath</package></item>
+</list>
+</p>
+
+<chapt>Java Development
+<p>
+<sect>What full-fledged Java development platforms are available in Debian?
+
+<p> 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:
+
+<list>
+<item>The deprecated Kaffe in Debian 5.0 Lenny.
+
+<item>The deprecated Sun Java 5 jdk, available in the Debian 5.0 <em>Lenny</em>
+release in the <em>non-free</em> component.
+
+<item>Sun's Java 6 jdk, available in Debian <em>Lenny</em> and Debian
+<em>Squeeze</em>, also as packages in the <em>non-free</em> component.
+
+<item>Sun's OpenJDK 6, available since the Debian 5.0 <em>Lenny</em>
+release in the <em>main</em> section.
+
+<item>The combination GCJ, GIJ, and Classpath in the <em>main</em> section.
+</list>
+
+<p>It is recommended to install one of the default-jdk or default-jre meta
+packages which either installs OpenJDK or GCJ depending on the architecture and
+Debian version.
+
+<sect id="free">What free platforms are there and how can I contribute?
+<p>
+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:
+<list>
+
+<item>openjdk: <url id="http://openjdk.java.net/"></item>
+
+<item>gcj and libgcj: <url id="http://gcc.gnu.org/java/"></item>
+
+<item>FastJar <url id="http://savannah.nongnu.org/projects/fastjar">, as a jar
+tool.</item>
+
+<item>Classpath <url id="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. (NB: This was removed from Squeeze)</item>
+
+<item>Mauve <url
+id="http://sources.redhat.com/mauve/"> is a free suite to test if
+these tools are 'compliant'.</item>
+
+</list>
+
+<p>Most free Java development is grouped under the <url
+id="http://www.gnu.org/software/java/" name="Free Java
+Project">.
+
+<sect id="license-concerns">Questions on platforms and license concerns
+
+<sect1 id="java56">Java 5 and 6
+
+<p>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
+<em>non-free</em> section, so you have to configure your apt sources appropriately. If
+you have the following in your <file>/etc/apt/sources.list</file>:
+
+<example>
+deb http://ftp.debian.org/debian lenny main
+</example>
+
+you need to change it to:
+
+<example>
+deb http://ftp.debian.org/debian lenny main contrib non-free
+</example>
+
+Once this is done and you have updated your package database. You can either
+install the Java development kit:
+
+<example>
+apt-get install sun-java6-jdk
+</example>
+
+or the Java runtime environment:
+
+<example>
+apt-get install sun-java6-jre
+</example>
+
+<p>Similarly, you can install the Java 5 development kit:
+
+<example>
+apt-get install sun-java5-jdk
+</example>
+
+or the Java 5 runtime environment:
+
+<example>
+apt-get install sun-java5-jre
+</example>
+
+<p>You might want to update the alternatives system to have Sun's tools as the
+default:
+
+<example>
+update-java-alternatives -s java-6-sun
+</example>
+
+Or for java 5:
+
+<example>
+update-java-alternatives -s java-1.5.0-sun
+</example>
+
+<sect1 id="openjdk">Sun's OpenJDK
+
+<p>Sun adopted in november 2006 the GPL license for almost all of the virtual
+machine and GPL v2 + the <em>Classpath exception</em><footnote>This is similar
+to GCC linking exception in that it allows non-GPL code to be linked with the
+GPL code. This exception was developed by the <url
+id="http://www.gnu.org/software/classpath/license.html" name="Classpath
+project"></footnote>for the class libraries and those parts of the virtual
+machine that expose public APIs.
+
+<p>As a consequence, the free OpenJDK code is available in Debian since the
+5.0 (lenny) release.</p>
+
+<p>You can install the Java development kit:
+
+<example>
+apt-get install openjdk-6-jdk
+</example>
+
+or the Java runtime environment:
+
+<example>
+apt-get install openjdk-6-jre
+</example>
+
+<p>For more information see <url id="http://www.sun.com/software/opensource/java/faq.jsp" name="Free and Open Source Java">.
+
+
+<sect>Making Debian packages for Java programs.
+
+<sect1>Can the package go into main?
+
+<p>Yes, <em>but only if</em> 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 <em>must</em>
+go into contrib or non-free, depending on the license of the program itself.
+
+<sect1>Is there a good example Debian package?
+
+<p>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.
+
+<p>A good start would be to check out the pkg-java project on
+Alioth: <url id="http://pkg-java.alioth.debian.org/">.
+
+<p>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:
+<url id="http://pkg-java.alioth.debian.org/developers.html#rules"> and
+<url id="http://pkg-java.alioth.debian.org/building.html">.
+
+
+<sect1>What tools are available to make maintaining a Java packages easier?
+
+<p>Both cdbs and debhelper (dh7) have support for ant scripts. There
+are also a number of specialized tools or build helpers. Have a look
+at <package>javahelper</package>
+or <package>maven-debian-helper</package>. <package>gcj-jdk</package>
+also has a dh_javadoc tool.</p>
+
+<sect1>Linking package Javadoc to system javadoc.
+
+<p>The java-policy mandates that documentation must be linked with
+with the javadoc installed on the system. This can be done by passing
+javadoc the "-link" argument or by using the <link> tag in ant.
+An example:
+
+<example>
+# command line example of linking against system doc.
+javadoc -link /usr/share/doc/default-jdk-doc/api [other arguments]
+
+<!-- Ant example of linking against system doc -->
+<javadoc [attributes]>
+ <link href="/usr/share/doc/default-jdk-doc/api/" />
+ [other tags]
+</javadoc>
+</example>
+</p>
+
+<p>The documentation must be installed at the time the linking is
+done; so in the example cases above the package would need a
+Build-Depends or a Build-Depends-Indep on
+<package>default-jdk-doc</package>.
+</p>
+
+<p>
+Here is a short list of packages that can be used for reference:
+<list>
+ <item><package>commons-jci</package></item>
+ <item><package>ow-util-ant-tasks</package></item>
+ <item><package>libhamcrest-java</package></item>
+ <item><package>libfreemarker-java</package></item>
+</list>
+</p>
+
+<chapt>Java Compilers
+<p>
+<sect>What Java compilers are available in Debian?
+<p>
+<list>
+
+<item><package>openjdk-6-jdk</package></item>
+
+<item><package>sun-java6-jdk</package> (non-free)</item>
+
+<item><package>gcj</package>. Compiles Java source to native code,
+also source to bytecode, or bytecode to native code.
+
+<item>The deprecated <package>jikes</package> in <em>Lenny</em>.
+
+</list>
+
+<chapt>Java Virtual Machines (JVM)
+<p>
+<sect>What JVMs are available in Debian?
+
+<p>The following JVMs are currently available in Debian Squeeze:
+
+<list>
+<item><package>openjdk-6-jre</package></item>
+<item><package>sun-java6-jre</package> (non-free)</item>
+<item><package>gcj-4.4-jre</package></item>
+</list>
+
+</p>
+
+<p>The following lists JVMs available in Debian 5.0 release ('Lenny'):
+
+<list>
+<item><package>openjdk-6-jre</package></item>
+<item><package>kaffe</package></item>
+<item><package>gij-4.3</package></item>
+</list>
+
+
+<sect>What API do these JVMs provide?
+
+<p>Note that providing an API does not mean that everything is
+implemented, and certainly not implemented correctly. But even Sun's
+SDK, each out of four confirmed bugs don't get fixed, so don't
+disregard free implementation on buggyness or limited implementation
+alone.
+
+<sect>Are there known problems?
+
+<p>Yes, there are. Some of these are reported as Debian bugs. You can
+look up the bugs for a specific Debian package at the <url
+id="http://www.debian.org/Bugs/" name="Debian Bug Tracking System">. As
+a quick link, here are some packages:
+
+<list>
+<item><url id="http://bugs.debian.org/java-common" name="java-common"></item>
+<item><url id="http://bugs.debian.org/src:openjdk-6" name="openjdk-6"></item>
+<item><url id="http://bugs.debian.org/src:gcj-4.4" name="gcj-4.4"></item>
+</list>
+
+<p>As common within the Debian project, the developers would
+appreciate good bug reports on found problems. These include the good
+description of the problem, the command that gives the problem, the
+errors given when running the command, and any other information that
+might be relevant. A good tool to report bugs is
+<package>reportbug</package>.
+
+<sect>Do I need a JVM to run a Java program in Debian?
+<p>
+No, you can try to run the applications without a jvm by compiling
+the source code to native code is.
+
+<sect1>How do I compile to native code?
+
+<p>You might be able to use <prgn>gcj</prgn> to compile the program.
+And use <prgn>gcj</prgn> to convert bytecode to native code. The entire
+software chain is free.
+
+
+<chapt id="browser-java">Java Plugins for Browsers
+
+<p>
+<list>
+
+<item>You can install the package icedtea-gcjwebplugin or the non-free
+packages sun-java5-plugin or sun-java6-plugin in <em>Lenny</em>.</item>
+
+<item>You can install the package icedtea6-plugin or the non-free
+package sun-java6-plugin in <em>Squeeze</em>.</item>
+
+</list>
+
+
+<chapt>Java Servlets
+<p>
+<sect>How can I make Java servlets work?
+<p>You can use:
+<list>
+ <item>Apache <package>tomcat6</package> from <url id="http://tomcat.apache.org">.
+ <item>Eclipse <package>jetty</package> from <url id="http://www.eclipse.org/jetty/">.
+</list>
+
+
+<chapt>Java Policy
+<p>
+<sect>Is there a Java policy for Debian?
+<p>
+It is still in the works. The current policy addresses <em>some</em>
+of the problems. It has not been officially released. You can find
+it at <url id="http://www.debian.org/doc/packaging-manuals/java-policy/">.
+The Java Policy can also be found in the <package>java-common</package>
+package. You might want to also take a look at the
+<url id="http://wiki.debian.org/DebianJavaPackaging"
+name="Common Java Packaging"> entry in the Debian wiki.
+
+<sect>Are there holes in the Java Policy?
+<p>Yes, some until under discussion. Please check out the
+<url id="http://bugs.debian.org/java-common" name="bugs against
+the java-common package">. Thus it is <em>very</em> inconvenient to
+use several compilers of virtual machines since there is not one
+CLASSPATH setting for all of them.
+
+<chapt>Other Java alternatives for Debian
+<p>If the Java packages provided in Debian are not sufficient for your
+needs you might need to take a look at other alternatives. Please understand
+that these alternatives are not supported by the Debian project directly,
+you might get help, however, from the debian-java mailing list if you
+encounter issues with them.
+
+<P>Some of the alternatives presented use Debian packages which is
+convenient, since the user/administrator does not need to care on installation
+issues. However, mixing packages that come from a source which is not
+the Debian project might cause conflicts with your installation some times.
+Of course, Debian tries to integrate as many free software efforts as
+possible, so some of the alternatives described below might (if license
+permits) be included in Debian in the near future.
+
+<sect>Java programs not yet available on Debian
+<p>
+The following are programs that have not yet been packaged for Debian
+nor is there an installer. There are quite a lot Java programs out
+there and this list is not an exhaustive list, it only includes
+programs that <em>might</em> be packaged for Debian or those that
+someone is working on an installer for:
+<list>
+<item>BlueJ. A development environment for Java with editor, compiler,
+virtual machine and debugger. See <url
+id="http://bluej.monash.edu.au/">
+<item>Jacob (Java Commando Base): project maintainer and visualiser
+for Java in Emacs. See <url
+id="http://home.pages.de/~kclee/clemens/jacob">.
+
+<item>Emacs in Java. See <url id="http://jemacs.sourceforge.net/">.
+
+<item>Netbeans developer, now called <em>Forte</em>. Based on the
+Javabeans architecture. See <url id="http://www.netbeans.com">.Sun
+recently announced they would open-source it. See <url
+id="http://www.sun.com/forte/tools4dotcom/opensource.html">.
+
+<item>AnyJ. Graphic environment to develop applications, applets and
+servlets. More info in <url id="http://www.netcomputing.de">.
+
+<item>Free Builder. A Java IDE written in Java and distributed under
+the GPL <url id="http://www.freebuilder.org">.
+
+</list>
+
+</book>
diff --git a/debian/README.Debian b/debian/README.Debian
new file mode 100644
index 0000000..07af622
--- /dev/null
+++ b/debian/README.Debian
@@ -0,0 +1,15 @@
+This package contains information about how to make your java environment
+work. The package contains the Proposed Debian Java Policy and
+the Debian Java FAQ. It should probably be enough to get things going.
+
+They can be found at
+/usr/share/doc/java-common/debian-java-faq/index.html
+and
+/usr/share/doc/java-common/debian-java-policy/index.html
+
+Previously it existed a bunch of *-dummy packages. They have now been
+removed from the archive. If you need to fulfill the dependencies you have
+to make your own dummy package. The equivs package might help you with
+this.
+
+ Ola Lundqvist <opal at debian.org>
diff --git a/debian/README.gcj-native-transition b/debian/README.gcj-native-transition
new file mode 100644
index 0000000..d32c1b4
--- /dev/null
+++ b/debian/README.gcj-native-transition
@@ -0,0 +1,30 @@
+default-jdk-builddep transition
+===============================
+
+default-jdk-builddep was a package to provide helpers to compile
+class/jar files into native code, unfortunately its poorly chosen
+name lead to people thinking it was the "Right Thing" to
+Build-Depend on when maintaining a Java Package. This
+misunderstanding even got into the templates for AMs for reviewing
+New Maintainers (The T&SII follow up).
+
+These helper tools requires a special Java Development Kit and
+therefore on many architectures default-jdk-builddep would pull two
+full JDK.
+
+In order to end this confusion once and for all the Debian Java team
+decided to rename default-jdk-builddep to gcj-native-helper and
+reduce it to only pull the special JDK needed for native compilation.
+
+The replacement for default-jdk-builddep falls into one of two cases.
+If you create "gcj" packages (which contains jar files compiled into
+native shared libraries), default-jdk-builddep should be replaced by
+default-jdk AND gcj-native-helper. Otherwise you should replace it by
+default-jdk.
+
+If you are interested in the debate to do this rename, please have a
+look at:
+ * http://lists.debian.org/debian-java/2010/04/msg00070.html
+
+ -- Niels Thykier <niels at thykier.net> Wed, 30 Jun 2010 22:55:00 +0200
+
diff --git a/debian/changelog b/debian/changelog
index 96dfea8..8d3e7c8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,182 +1,9 @@
-java-common (0.57) unstable; urgency=medium
-
- * Build a default-jdk-headless package.
- * java_defaults.mk: Fix jvm_archdir macro (Jonas Smedegaard). Closes: #814783.
- * Just remove the gcj-native-helper doc symlink on upgrade. Closes: #813223.
- * Remove Torsten Werner from uploaders.
-
- -- Matthias Klose <doko at debian.org> Fri, 26 Feb 2016 18:34:49 +0100
-
-java-common (0.56) unstable; urgency=medium
-
- * Team upload.
- * Build default-java-plugin for the architectures supporting icedtea-web only
-
- -- Emmanuel Bourg <ebourg at apache.org> Wed, 10 Feb 2016 15:47:24 +0100
-
-java-common (0.55) unstable; urgency=medium
+java-common (0.47+deb7u1) wheezy; urgency=medium
* Team upload.
+ * Switch default Java environment from OpenJDK 6 to OpenJDK 7 in Wheezy LTS.
- [ Matthias Klose ]
- * Bump m68k, sh4 and sparc64 to 1.8.
-
- [ Emmanuel Bourg ]
- * Upload to unstable
- * Fixed the name of the plugin dependency
- (icedtea-<n>-plugin instead of icedtea-<n>-web)
- * Standards-Version updated to 3.9.7 (no changes)
- * Properly handle the symlink to dir conversion in gcj-native-helper
- (Closes: #813223)
-
- -- Emmanuel Bourg <ebourg at apache.org> Fri, 05 Feb 2016 00:42:57 +0100
-
-java-common (0.54) experimental; urgency=medium
-
- * Team upload.
-
- [ Emmanuel Bourg ]
- * Use OpenJDK 8 on mips, mipsel and mips64el.
- * Added a new default-java-plugin package depending on the right plugin
- package for the current architecture, typically icedtea-<n>-plugin.
- default-java-plugin provides icedtea-plugin (Closes: #678381).
- * default-jre now recommends default-java-plugin
- * The Java Policy and the FAQ have been moved to the new java-policy package.
- * default-jdk-doc is now architecture dependent (Closes: #801257)
- * gcj-native-helper no longer depends on default-jdk
- * gcj-native-helper depends on gcj-jdk instead of openjdk (regression in 0.53)
- * default-jdk/jre now have unversioned dependencies on openjdk
- * Dropped support for non multiarch aware openjdk packages
- * update-java-alternatives now supports bash completion (Closes: #777550)
- * The output of update-java-alternatives --list is now aligned vertically
- * Removed the unused classpath-from-jars-1 example
- * Removed the old dummy control files
- * Removed the README about the old default-jdk-builddep transition
- * Removed the unused Lintian overrides for java-common
- * Removed the not implemented --test option from update-java-alternatives
- (Closes: #800024)
- * Converted debian/copyright to the Copyright Format 1.0
- * Simplified debian/rules using the dh sequencer
- * Removed the default values for Java 6 (no longer used)
-
- [ Matthias Klose ]
- * Bump alpha, kfreebsd-amd64 and kfreebsd-i386 to 1.8.
- * java_defaults.mk: Add jvm_archdir, jvm_archpath, jvm_includes macros.
-
- -- Emmanuel Bourg <ebourg at apache.org> Tue, 27 Oct 2015 15:54:19 +0100
-
-java-common (0.53) experimental; urgency=medium
-
- * Team upload.
- * Use OpenJDK 8 on amd64, arm64, armel, armhf, i386, powerpc, powerpcspe,
- ppc64, ppc64el, s390x and x32.
- * Prepared the default values for Java 9
- * Policy changes:
- - Programs must depend on the needed runtime environment, but not
- the libraries (Closes: #730133)
- - Replaced 'java' with 'Java' when referring to the language
- - Mentioned the virtual packages java{5,6,7,8}-runtime(-headless)?
- * Removed Niels Thykier from the uploaders (Closes: #770579)
- * Changed the maintainer from 'Debian Java Mailing List'
- to 'Debian Java Maintainers'
- * Standards-Version updated to 3.9.6 (no changes)
- * Moved the package to Git
-
- -- Emmanuel Bourg <ebourg at apache.org> Tue, 01 Sep 2015 23:11:54 +0200
-
-java-common (0.52.1) unstable; urgency=medium
-
- * Team upload.
- * Bump kfreebsd-amd64 kfreebsd-i386 to 1.7 again.
- * java_defaults.mk: Add jvm_archdir and jvm_archpath macros.
-
- -- Matthias Klose <doko at debian.org> Sun, 11 Oct 2015 09:40:26 +0200
-
-java-common (0.52) unstable; urgency=medium
-
- * Team upload.
- * Use OpenJDK 7 on mips64el (Closes: #747179)
- * Prepared the default values for Java 8
- * Use 'set -e' instead of '#!/bin/sh -e' in debian/java-common.postrm
- * Switch to debhelper level 9
- * debian/control:
- - Standards-Version updated to 3.9.5 (no changes)
- - Use a canonical URL for the Vcs-Svn field
- - Added the Homepage field
-
- -- Emmanuel Bourg <ebourg at apache.org> Tue, 06 May 2014 11:10:05 +0200
-
-java-common (0.51) unstable; urgency=low
-
- [ Sylvestre Ledru ]
- * Fix some wrong version declarations
-
- [ Matthias Klose ]
- * Promote openjdk-7 as default-java on arm64, mips, mipsel, powerpcspe,
- ppc64el, x32.
- * Revert back to gcj on ia64. openjdk-7 fails to build, not porter feedback.
- * Revert back to gcj on s390. openjdk-7 fails to build, not a release
- architecture anymore.
- * Revert back to gcj on sparc and sparc64. Hotspot for sparc isn't
- maintained anymore upstream. No porter feedback about a Zero port.
- * Revert back to gcj on kfreebsd-{i386,amd64}. The port is not yet
- available upstream. No feedback from the kfreebsd porters, and no
- updates for new upstream versions.
- * Bump the epoch on the default-{jre-headless,jre,jdk} packages.
-
- -- Niels Thykier <niels at thykier.net> Sat, 01 Feb 2014 13:03:13 +0100
-
-java-common (0.50) unstable; urgency=low
-
- * Remove the 'Libraries must depend on the needed runtime environment'
- from the policy. It was wrong and conflicting with lintian.
- (Closes: #730133)
-
- [ Damien Raude-Morvan ]
- * Promote openjdk-7 as default-java on kfreebsd-{i386,amd64}.
-
- -- Sylvestre Ledru <sylvestre at debian.org> Sat, 23 Nov 2013 14:55:24 +0100
-
-java-common (0.49) unstable; urgency=low
-
- [ Sylvestre Ledru ]
- * Team upload.
- * Finalize the upload to switch to OpenJDK 7.
- See http://lists.debian.org/debian-devel-announce/2013/08/msg00000.html
- * Fix empty-binary-package on gcj-native-helper, default-jre & default-jdk
- * Remove local variables in the changelog
- * Update of the Debian Java FAQ (was starting to become obsolete)
- * Update of the Java policy:
- - Recommend default-jre & default-jre-headless for Java libraries
- - Create a section "Building Java packages"
- - Promote default-jdk
- - Advice to use javahelper
- - Recommend maven-debian-helper
- - Remove some deprecated references to java-runtime{1,2}
- - Minor improvements
- - State the license of the policy (Closes: #687841)
-
- [ tony mancill ]
- * Upload to unstable to make openjdk-7 the default on architectures
- where it is supported.
- * Bump Standards-Version to 3.9.4.
- * Update Vcs-Svn URL.
-
- [ Matthias Klose ]
- * Don't blindly update to OpenJDK7 on architectures where it is not
- supported or not even built.
- * Provide a /usr/share/java/java_defaults.mk makefile fragment for
- supported java architectures and versions.
-
- -- Sylvestre Ledru <sylvestre at debian.org> Mon, 05 Aug 2013 17:18:05 +0200
-
-java-common (0.48) experimental; urgency=low
-
- * Upload to experimental.
- * Replace java6 with java7 on architectures supporting
- openjdk-7.
-
- -- Niels Thykier <niels at thykier.net> Mon, 18 Jun 2012 14:29:24 +0200
+ -- Markus Koschany <apo at debian.org> Thu, 24 Mar 2016 18:59:19 +0100
java-common (0.47) unstable; urgency=low
@@ -704,4 +531,6 @@ java-common (0.0-1) unstable; urgency=low
-- Stephane Bortzmeyer <bortzmeyer at debian.org> Wed, 23 Jun 1999 15:03:43 +0200
-
+Local variables:
+mode: debian-changelog
+End:
diff --git a/debian/compat b/debian/compat
index ec63514..7f8f011 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-9
+7
diff --git a/debian/control b/debian/control
index 7cfc82a..48d2a49 100644
--- a/debian/control
+++ b/debian/control
@@ -1,38 +1,45 @@
Source: java-common
Section: java
Priority: optional
-Maintainer: Debian Java Maintainers <pkg-java-maintainers at lists.alioth.debian.org>
-Uploaders: Matthias Klose <doko at debian.org>
-Build-Depends: debhelper (>= 9)
-Standards-Version: 3.9.7
-Vcs-Git: git://anonscm.debian.org/pkg-java/java-common.git
-Vcs-Browser: http://anonscm.debian.org/cgit/pkg-java/java-common.git
-Homepage: https://wiki.debian.org/Java/
+Maintainer: Debian Java Mailing List <debian-java at lists.debian.org>
+Uploaders: Michael Koch <konqueror at gmx.de>, Matthias Klose <doko at debian.org>, Torsten Werner <twerner at debian.org>,
+ Niels Thykier <niels at thykier.net>
+Build-Depends: debhelper (>= 7)
+Build-Depends-Indep: debiandoc-sgml, docbook-utils, docbook-xml, lynx
+Standards-Version: 3.9.3
+Vcs-Svn: svn://svn.debian.org/svn/pkg-java/trunk/java-common
+Vcs-Browser: http://svn.debian.org/wsvn/pkg-java/trunk/java-common/
Package: java-common
Architecture: all
Multi-Arch: foreign
Depends: ${misc:Depends}
-Suggests: default-jre
-Description: Base package for Java runtimes
- This package provides common tools for the Java runtimes, such as
- the update-java-alternatives mechanism used to switch between
- different versions of Java.
+Suggests: default-jre, equivs
+Description: Base of all Java packages
+ This package must be installed in the system if a Java environment
+ is desired. It covers useful information for Java users in
+ Debian GNU/Linux, including:
+ * The Java policy document which describes the layout of Java support in
+ Debian and how Java packages should behave.
+ * The Debian-Java-FAQ which provides information on the status of
+ Java support in Debian, available compilers, virtual machines, Java
+ programs and libraries as well as on legal issues.
+ * Information on how to create dummy packages to fulfill java2
+ requirements.
Package: default-jre
Architecture: any
-Depends: default-jre-headless (= ${binary:Version}), ${jre},
+Depends: default-jre-headless (= ${binary:Version}), ${jre}${jre:version},
${misc:Depends}
-Recommends: default-java-plugin
Provides: ${jre:provides}
Description: Standard Java or Java compatible Runtime
- This dependency package points to the Java runtime, or Java compatible
+ This package points to the Java runtime, or Java compatible
runtime recommended for the ${jre:arch} architecture,
which is ${jre} for ${jre:arch}.
Package: default-jre-headless
Architecture: any
-Depends: ${jhl}, java-common, ${misc:Depends}
+Depends: ${jhl}${jre:version}, java-common, ${misc:Depends}
Suggests: default-jre
Provides: ${jhl:provides}
Replaces: openjdk-6-jre-headless (<< 6b23~pre8-2~)
@@ -46,56 +53,39 @@ Description: Standard Java or Java compatible Runtime (headless)
Package: default-jdk
Architecture: any
-Depends: default-jre (= ${binary:Version}), default-jdk-headless (= ${binary:Version}), ${jdk},
+Depends: default-jre (= ${binary:Version}), ${jdk}${jdk:version},
${misc:Depends}
Provides: ${jdk:provides}
Description: Standard Java or Java compatible Development Kit
- This dependency package points to the Java runtime, or Java compatible
- development kit recommended for this architecture, which is
- ${jdk} for ${jre:arch}.
-
-Package: default-jdk-headless
-Architecture: any
-Depends: default-jre-headless (= ${binary:Version}), ${jdkhl},
- ${misc:Depends}
-Provides: ${jdkhl:provides}
-Description: Standard Java or Java compatible Development Kit (headless)
- This dependency package points to the Java runtime, or Java compatible
+ This package points to the Java runtime, or Java compatible
development kit recommended for this architecture, which is
${jdk} for ${jre:arch}.
Package: default-jdk-doc
-Architecture: any
+Architecture: all
Section: doc
Depends: ${doc}, ${misc:Depends}
Suggests: default-jdk
Description: Standard Java or Java compatible Development Kit (documentation)
This package points to the documentation for the Java development kit,
or Java compatible development kit recommended for Debian, which is
- ${doc} for ${jre:arch}.
-
-Package: default-java-plugin
-Architecture: any
-Depends: default-jre (= ${binary:Version}), ${plugin}, ${misc:Depends}
-Provides: icedtea-plugin
-Description: Default Java Plugin for running applets and Java Web Start applications
- This dependency package points to the default Java Plugin recommended
- for the ${jre:arch} architecture. The Java Plugin adds the ability to run
- Java applets from a web browser and launch Java Web Start applications using
- the Java Network Launch Protocol (JNLP).
+ ${doc}.
Package: gcj-native-helper
Architecture: any
-Pre-Depends: ${misc:Pre-Depends}
-Depends: gcj-jdk, ${misc:Depends}
+Depends: default-jdk (= ${binary:Version}), ${jdk:builddep}, ${misc:Depends}
Provides: default-jdk-builddep
Conflicts: default-jdk-builddep
Replaces: default-jdk-builddep
Description: Standard helper tools for creating gcj native packages
- This dependency package points to the build dependencies used to build
+ This package points to the build dependencies used to build
gcj native packages.
.
Unlike default-jdk-builddep, this package only provides the
helpers to compile jar/class files into native code and not
a Java Development Kit (JDK). You do not need this package
unless you are compiling jar/class files to native code.
+ .
+ Note: During the transition from default-jdk-builddep to
+ gcj-native-helper, this package will also depend on
+ default-jdk to avoid breakage.
diff --git a/debian/copyright b/debian/copyright
index c492583..9c7b8ac 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,32 +1,35 @@
-Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
-Upstream-Name: Java Common
-Upstream-Contact: Debian Java Team <debian-java at lists.debian.org>
-
-Files: *
-Copyright: 2000, Stephane Bortzmeyer <bortzmeyer at debian.org>
- 2001-2003, Ola Lundqvist <opal at debian.org>
- 2003, Stefan Gybas <sgybas at debian.org>
- 2005, Arnaud Vandyck <avdyk at debian.org>
- 2006-2008, Michael Koch <konqueror at gmx.de>
- 2006-2014, Matthias Klose <doko at debian.org>
- 2009, Torsten Werner <twerner at debian.org>
- 2010, Niels Thykier <niels at thykier.net>
- 2011-2013, Sylvestre Ledru <sylvestre at debian.org>
- 2014-2015, Emmanuel Bourg <ebourg at apache.org>
-License: GPL-2+
- This package is free software; you can redistribute it and/or modify
- it under the terms of the GNU General Public License as published by
- the Free Software Foundation; either version 2 of the License, or
- (at your option) any later version.
- .
- This package is distributed in the hope that it will be useful,
- but WITHOUT ANY WARRANTY; without even the implied warranty of
- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- GNU General Public License for more details.
- .
- You should have received a copy of the GNU General Public License
- along with this program; if not, write to the Free Software
- Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
- .
- On Debian systems, the complete text of the GNU General
- Public License can be found in `/usr/share/common-licenses/GPL-2'.
+It is a Debian original work.
+
+Current maintainers:
+ Michael Koch <konqueror at gmx.de>
+ Matthias Klose <doko at debian.org>
+ Torsten Werner <twerner at debian.org>
+ Niels Thykier <niels at thykier.net>
+
+Previous maintainers:
+ Ola Lundqvist <opal at debian.org>
+ Stephane Bortzmeyer <bortzmeyer at debian.org>
+ Stefan Gybas <sgybas at debian.org>
+ Arnaud Vandyck <avdyk at debian.org>
+
+Copyright (C) 1999-2010 by current and previous maintainers for Debian
+
+License:
+
+ This package is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 2 of the License, or
+ (at your option) any later version.
+
+ This package is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+
+On Debian systems, the complete text of the GNU General
+Public License can be found in `/usr/share/common-licenses/GPL-2'.
+
diff --git a/debian/default-jdk-doc.lintian-overrides b/debian/default-jdk-doc.lintian-overrides
deleted file mode 100644
index 07362b5..0000000
--- a/debian/default-jdk-doc.lintian-overrides
+++ /dev/null
@@ -1,4 +0,0 @@
-# default-jdk-doc targets the documentation of the default JDK which is architecture dependent (#801257)
-default-jdk-doc: documentation-package-not-architecture-independent
-
-default-jdk-doc: debian-changelog-file-missing-or-wrong-name
diff --git a/debian/gcj-native-helper.lintian-overrides b/debian/gcj-native-helper.lintian-overrides
deleted file mode 100644
index 0972ea1..0000000
--- a/debian/gcj-native-helper.lintian-overrides
+++ /dev/null
@@ -1 +0,0 @@
-gcj-native-helper: debian-changelog-file-missing-or-wrong-name
diff --git a/debian/gcj-native-helper.preinst b/debian/gcj-native-helper.preinst
deleted file mode 100644
index 51b90b6..0000000
--- a/debian/gcj-native-helper.preinst
+++ /dev/null
@@ -1,13 +0,0 @@
-#! /bin/sh
-
-set -e
-
-if [ "$1" = upgrade ] && [ -n "$2" ] && dpkg --compare-versions "$2" lt 2:1.8-57~; then
- if [ -h /usr/share/doc/gcj-native-helper ]; then
- rm -f /usr/share/doc/gcj-native-helper
- fi
-fi
-
-#DEBHELPER#
-
-exit 0
diff --git a/debian/java-common.dirs b/debian/java-common.dirs
new file mode 100644
index 0000000..13c9f03
--- /dev/null
+++ b/debian/java-common.dirs
@@ -0,0 +1 @@
+usr/share/java
diff --git a/debian/java-common.doc-base.faq b/debian/java-common.doc-base.faq
new file mode 100644
index 0000000..b7a4771
--- /dev/null
+++ b/debian/java-common.doc-base.faq
@@ -0,0 +1,13 @@
+Document: debian-java-faq
+Title: Debian Java FAQ
+Author: Torsten Werner
+Abstract: The Debian Java FAQ provide answers to many
+ usual questions regarding the use of the Java programming
+ language in the Debian GNU/Linux operating system. It
+ discusses availability of compilers, virtual machines,
+ libraries and applications as well as legal issues.
+Section: Debian
+
+Format: HTML
+Index: /usr/share/doc/java-common/debian-java-faq/index.html
+Files: /usr/share/doc/java-common/debian-java-faq/*.html
diff --git a/debian/java-common.doc-base.policy b/debian/java-common.doc-base.policy
new file mode 100644
index 0000000..70bc900
--- /dev/null
+++ b/debian/java-common.doc-base.policy
@@ -0,0 +1,13 @@
+Document: java-policy
+Title: Debian Java Policy (proposal)
+Author: Niels Thykier
+Abstract: The Debian Java Policy (currently a proposal)
+ describes how Java packages are handled in Debian.
+Section: Debian
+
+Format: text
+Files: /usr/share/doc/java-common/policy.txt.gz
+
+Format: HTML
+Index: /usr/share/doc/java-common/debian-java-policy/index.html
+Files: /usr/share/doc/java-common/debian-java-policy/*.html
diff --git a/debian/java-common.docs b/debian/java-common.docs
new file mode 100644
index 0000000..1f359fe
--- /dev/null
+++ b/debian/java-common.docs
@@ -0,0 +1 @@
+debian/README.gcj-native-transition
diff --git a/debian/java-common.examples b/debian/java-common.examples
new file mode 100644
index 0000000..e39721e
--- /dev/null
+++ b/debian/java-common.examples
@@ -0,0 +1 @@
+examples/*
diff --git a/debian/java-common.install b/debian/java-common.install
deleted file mode 100644
index 7984010..0000000
--- a/debian/java-common.install
+++ /dev/null
@@ -1,3 +0,0 @@
-scripts/update-java-alternatives usr/sbin/
-scripts/completion/update-java-alternatives usr/share/bash-completion/completions/
-debian/java_defaults.mk usr/share/java/
diff --git a/debian/java-common.lintian-overrides b/debian/java-common.lintian-overrides
new file mode 100644
index 0000000..a107fa8
--- /dev/null
+++ b/debian/java-common.lintian-overrides
@@ -0,0 +1 @@
+java-common: package-contains-empty-directory usr/share/java/
diff --git a/debian/java-common.manpages b/debian/java-common.manpages
deleted file mode 100644
index 0b97e9b..0000000
--- a/debian/java-common.manpages
+++ /dev/null
@@ -1 +0,0 @@
-scripts/update-java-alternatives.8
diff --git a/debian/java-common.postrm b/debian/java-common.postrm
index 5f7f974..4e16477 100644
--- a/debian/java-common.postrm
+++ b/debian/java-common.postrm
@@ -1,6 +1,4 @@
-#!/bin/sh
-
-set -e
+#!/bin/sh -e
case "$1" in
purge)
diff --git a/debian/java_defaults.mk b/debian/java_defaults.mk
deleted file mode 100644
index 3a25ccd..0000000
--- a/debian/java_defaults.mk
+++ /dev/null
@@ -1,69 +0,0 @@
-
-# makefile fragment to define the macros java_default_version,
-# java{,5,6,7,8,9}_architectures
-
-java9_architectures =
-java8_architectures = $(java9_architectures) \
- alpha amd64 arm64 armel armhf i386 \
- m68k mips mipsel mips64el \
- powerpc powerpcspe ppc64 ppc64el \
- s390x sh4 sparc64 x32 \
- kfreebsd-amd64 kfreebsd-i386
-java7_architectures = $(java8_architectures)
-java6_architectures = $(java7_architectures)
-java5_architectures = $(java6_architectures) \
- hppa ia64 s390 sparc \
- hurd-i386
-java_architectures = $(java5_architectures)
-
-java_plugin_architectures = \
- amd64 arm64 armel armhf i386 \
- powerpc ppc64 ppc64el s390x \
- kfreebsd-amd64 kfreebsd-i386 \
- x32
-
-_java_host_arch := $(if $(DEB_HOST_ARCH),$(DEB_HOST_ARCH),$(shell dpkg-architecture -qDEB_HOST_ARCH))
-ifneq (,$(filter $(_java_host_arch),$(java9_architectures)))
- java_default_version = 9
-else ifneq (,$(filter $(_java_host_arch),$(java8_architectures)))
- java_default_version = 8
-else ifneq (,$(filter $(_java_host_arch),$(java6_architectures)))
- java_default_version = 7
-else ifneq (,$(filter $(_java_host_arch),$(java6_architectures)))
- java_default_version = 6
-else ifneq (,$(filter $(_java_host_arch),$(java5_architectures)))
- java_default_version = 5
-endif
-
-# jvm_archdir is the directory for architecture specific files / libraries
-# in <JAVA_HOME>/jre/lib/<jvm_archdir> or <JAVA_HOME>/lib/<jvm_archdir>
-# jvm_archpath is the relative path of jvm_archdir in JAVA_HOME.
-
-_java_host_cpu := $(if $(DEB_HOST_ARCH_CPU),$(DEB_HOST_ARCH_CPU),$(shell dpkg-architecture -qDEB_HOST_ARCH_CPU))
-jvm_archdir_map = \
- alpha=alpha armel=arm armhf=arm arm64=aarch64 amd64=amd64 hppa=parisc \
- i386=i386 m68k=m68k mips=mips mipsel=mipsel mips64=mips64 mips64el=mips64el \
- powerpc=ppc powerpcspe=ppc ppc64=ppc64 ppc64el=ppc64le \
- sparc=sparc sparc64=sparc64 sh4=sh s390x=s390x ia64=ia64 x32=x32
-
-jvm_archdir := \
- $(strip $(patsubst $(_java_host_cpu)=%, %, $(filter $(_java_host_cpu)=%, $(jvm_archdir_map))))
-
-ifneq (,$(filter $(java_default_version), 9))
- jvm_archpath := lib/$(jvm_archdir)
-else
- jvm_archpath := jre/lib/$(jvm_archdir)
-endif
-
-_jvm_osinclude = linux
-ifeq ($(java_default_version),5)
- jvm_includes = \
- -I/usr/lib/jvm/java-gcj/include -I/usr/lib/jvm/java-gcj/include/$(_jvm_osinclude)
-else
- ifeq (,$(filter $(java_default_version), 6 7))
- _jvm_osinclude = $(if $(findstring kfreebsd,$(_java_host_arch)),bsd,linux)
- endif
- jvm_includes = \
- -I/usr/lib/jvm/java-$(java_default_version)-openjdk-$(_java_host_arch)/include \
- -I/usr/lib/jvm/java-$(java_default_version)-openjdk-$(_java_host_arch)/include/$(_jvm_osinclude)
-endif
diff --git a/debian/rules b/debian/rules
index 8fc3b8e..81efa64 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,95 +1,144 @@
#!/usr/bin/make -f
+# Made with the aid of dh_make, by Craig Small
+# Sample debian/rules that uses debhelper. GNU copyright 1997 by Joey Hess.
+# Some lines taken from debmake, by Cristoph Lameter.
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
-release = $(shell dpkg-parsechangelog | grep -E ^Version: | sed "s/Version: 0.//")
-
-DEB_HOST_ARCH ?= $(shell dpkg-architecture --query DEB_HOST_ARCH)
-
-include debian/java_defaults.mk
-
-p_jre = openjdk-$(java_default_version)-jre
-p_jhl = openjdk-$(java_default_version)-jre-headless
-p_jdk = openjdk-$(java_default_version)-jdk
-p_jdkhl = openjdk-$(java_default_version)-jdk-headless
-p_doc = openjdk-$(java_default_version)-doc
-p_plugin = icedtea-$(java_default_version)-plugin
-dversion = 2:1.$(java_default_version)-$(release)
-jvmdir = java-1.$(java_default_version).0-openjdk-$(DEB_HOST_ARCH)
-
-ifeq (5, $(java_default_version))
- p_jre = gcj-jre
- p_jhl = gcj-jre-headless
- p_jdk = gcj-jdk
- p_jdkhl = gcj-jdk # no gcj-jdk-headless package
- p_doc = openjdk-8-doc
- p_plugin =
- jvmdir = java-gcj
+, = ,
+S = $(EMPTY) $(EMPTY)
+mk_cslist = $(subst $(S),$(,)$(S),$(foreach v,$(1),$(v)-$(2)))
+vafilt = $(subst $(2)=,,$(filter $(2)=%,$(1)))
+jrel = $(shell dpkg-parsechangelog | grep -E ^Version: | sed "s/Version: 0.//")
+
+DPKG_VARS := $(shell dpkg-architecture)
+DEB_HOST_ARCH ?= $(call vafilt,$(DPKG_VARS),DEB_HOST_ARCH)
+DEB_HOST_MULTIARCH ?= $(call vafilt,$(DPKG_VARS),DEB_HOST_MULTIARCH)
+
+p_jre = gcj-jre
+p_jhl = gcj-jre-headless
+p_jdk = gcj-jdk
+jdk_build_dep =
+v_jre =
+v_jdk = $(v_jre)
+provides = java java2 java5
+dversion = 1:1.5-$(jrel)
+jvmdir = java-gcj
+
+ifneq (,$(filter $(DEB_HOST_ARCH), alpha amd64 armel armhf i386 ia64 lpia mips mipsel powerpc powerpcspe ppc64 s390 s390x sparc sh4))
+ p_jre = openjdk-7-jre
+ p_jhl = openjdk-7-jre-headless
+ p_jdk = openjdk-7-jdk
+ jdk_build_dep = gcj-jdk
+ v_jre = $(S)(>= 7~u3-2.1.1)
+ v_jdk = $(v_jre)
+ provides = java java2 java5 java6 java7
+ dversion = 1:1.7-$(jrel)
+ jvmdir = java-1.7.0-openjdk$(if $(DEB_HOST_MULTIARCH),-$(DEB_HOST_ARCH))
endif
-# Build default-java-plugin for the architectures supporting icedtea-web only
-ifeq (,$(filter $(_java_host_arch),$(java_plugin_architectures)))
- p_plugin =
-endif
+p_doc = openjdk-7-doc
+
+jre_provides = $(call mk_cslist,$(provides),runtime)
+jhl_provides = $(call mk_cslist,$(provides),runtime-headless)
+jdk_provides = $(call mk_cslist,$(provides),sdk)
-jre_provides = java-runtime, java2-runtime, $(shell seq --format java%.f-runtime --separator ', ' 5 $(java_default_version))
-jhl_provides = java-runtime-headless, java2-runtime-headless, $(shell seq --format java%.f-runtime-headless --separator ', ' 5 $(java_default_version))
-jdk_provides = java-sdk, java2-sdk, $(shell seq --format java%.f-sdk --separator ', ' 5 $(java_default_version))
-jdkhl_provides = java-sdk-headless, java2-sdk-headless, $(shell seq --format java%.f-sdk-headless --separator ', ' 5 $(java_default_version))
+build: build-arch
+build-arch:
+ # Do nothing :)
+build-indep: build-stamp
+build-stamp:
+ dh_testdir
-%:
- dh $@
+ $(MAKE)
+ touch build-stamp
-override_dh_link:
- dh_link
+clean:
+ dh_testdir
+ dh_testroot
+ rm -f build-stamp install-stamp
+ $(MAKE) clean
- # Link /usr/lib/jvm/default-java to the default JRE
- dh_link -pdefault-jre-headless usr/lib/jvm/$(jvmdir) usr/lib/jvm/default-java
+ dh_clean
- # Link to the JDK documentation
- dh_link -pdefault-jdk-doc /usr/share/doc/$(p_doc)/api usr/share/doc/default-jre-headless/api
- dh_link -pdefault-jdk-doc /usr/share/doc/$(p_doc)/api usr/share/doc/default-jdk-doc/api
+install-indep: install-stamp
+install-stamp: build-indep
+ dh_testdir
+ dh_testroot
+ dh_prep -i
+ dh_installdirs -i
-override_dh_installdocs:
dh_installdocs -i
+ $(MAKE) install DESTDIR=$(CURDIR)/debian/java-common
- # Install the changelog and copyright once in default-jre-headless and use links for the other packages
- dh_installdocs -pdefault-jre-headless
- dh_link -pdefault-jre /usr/share/doc/default-jre-headless /usr/share/doc/default-jre
- dh_link -pdefault-jdk-headless /usr/share/doc/default-jre-headless /usr/share/doc/default-jdk-headless
- dh_link -pdefault-jdk /usr/share/doc/default-jre /usr/share/doc/default-jdk
- dh_link -pdefault-java-plugin /usr/share/doc/default-jre /usr/share/doc/default-java-plugin
+ touch install-stamp
+
+install-arch: build-arch
+ dh_testdir
+ dh_testroot
+ dh_prep -a
- dh_installdocs -pdefault-jdk-doc
- dh_installdocs -pgcj-native-helper
-override_dh_gencontrol:
- dh_gencontrol -i
+binary-arch: install-arch
ifneq (,$(p_jre))
- dh_gencontrol -a --no-package=default-java-plugin -- \
+ dh_testdir -a
+ dh_testroot -a
+ dh_install -a
+ dh_installdocs -pdefault-jre-headless
+ dh_installchangelogs -pdefault-jre-headless
+ dh_link -pdefault-jre-headless \
+ usr/lib/jvm/$(jvmdir) usr/lib/jvm/default-java
+ for p in default-jre-headless default-jre default-jdk gcj-native-helper; do \
+ [ -z "$$t" ] && t=$$p && continue; \
+ mkdir -p debian/$$p/usr/share/doc; \
+ ln -sf $$t debian/$$p/usr/share/doc/$$p; \
+ t=$$p; \
+ done
+ dh_lintian -a
+ dh_compress -a
+ dh_fixperms -a
+ dh_installdeb -a
+ dh_gencontrol -a -- \
-v$(dversion) \
'-Vjre=$(p_jre)' \
'-Vjhl=$(p_jhl)' \
'-Vjdk=$(p_jdk)' \
- '-Vjdkhl=$(p_jdkhl)' \
- '-Vdoc=$(p_doc)' \
+ '-Vjdk:builddep=$(jdk_build_dep)' \
'-Vjre:arch=$(DEB_HOST_ARCH)' \
+ '-Vjre:version=$(v_jre)' \
+ '-Vjdk:version=$(v_jdk)' \
'-Vjre:provides=$(jre_provides)' \
'-Vjhl:provides=$(jhl_provides)' \
- '-Vjdkhl:provides=$(jdkhl_provides)' \
- '-Vjdk:provides=$(jdk_provides)'
-endif
-ifneq (,$(p_plugin))
- dh_gencontrol -pdefault-java-plugin -- -v$(dversion) -Vplugin=$(p_plugin) -Vjre:arch=$(DEB_HOST_ARCH)
+ '-Vjdk:provides=$(jdk_provides)' \
+
+ dh_md5sums -a
+ dh_builddeb -a
endif
-override_dh_builddeb:
+# Build architecture-independent files here.
+binary-indep: build-indep install-indep
+ dh_testdir -i
+ dh_testroot -i
+ dh_install -i
+ mkdir -p debian/default-jdk-doc/usr/share/doc/default-jre-headless
+ ln -sf ../$(p_doc)/api debian/default-jdk-doc/usr/share/doc/default-jre-headless/api
+ ln -sf ../$(p_doc)/api debian/default-jdk-doc/usr/share/doc/default-jdk-doc/api
+ dh_installexamples -i
+ dh_installmenu -i
+ dh_installman -i
+ dh_installchangelogs -i
+ dh_link -i
+ dh_lintian -i
+ dh_compress -i
+ dh_fixperms -i
+ dh_installdeb -i
+ dh_gencontrol -i -- \
+ '-Vdoc=$(p_doc)' \
+ '-Vjdk=$(p_jdk)'
+ dh_md5sums -i
dh_builddeb -i
-ifneq (,$(p_jre))
- dh_builddeb -a --no-package=default-java-plugin
-endif
-ifneq (,$(p_plugin))
- dh_builddeb -pdefault-java-plugin
-endif
+
+binary: binary-indep binary-arch
+.PHONY: build build-arch build-indep clean binary-indep binary-arch binary install configure
diff --git a/dummy/README b/dummy/README
new file mode 100644
index 0000000..9f760eb
--- /dev/null
+++ b/dummy/README
@@ -0,0 +1,2 @@
+Those control files can be used to create dummy packages of needed components.
+Install "equivs" package and use "equivs-build" build needed dummy packages.
diff --git a/dummy/java-compiler-dummy.control b/dummy/java-compiler-dummy.control
new file mode 100644
index 0000000..8dc8e62
--- /dev/null
+++ b/dummy/java-compiler-dummy.control
@@ -0,0 +1,12 @@
+Package: java-compiler-dummy
+Architecture: all
+Section: misc
+Priority: optional
+Depends: java-common, java1-runtime | java2-runtime
+Provides: java-compiler
+Description: Dummy package providing java-compiler
+ This package does NOT provide java compiler binary, it is here only to fulfill
+ dependencies of other packages.
+ .
+ You probably will want to use this package if you have installed the compiler
+ "by hand" or from package that does not provide java-compiler dependency.
diff --git a/dummy/java-virtual-machine-dummy.control b/dummy/java-virtual-machine-dummy.control
new file mode 100644
index 0000000..8e8938e
--- /dev/null
+++ b/dummy/java-virtual-machine-dummy.control
@@ -0,0 +1,13 @@
+Package: java-virtual-machine-dummy
+Architecture: all
+Section: misc
+Priority: optional
+Depends: java-common, java1-runtime | java2-runtime
+Provides: java-virtual-machine
+Description: Dummy package providing java-virtual-machine
+ This package does NOT provide java virtual machine binary, it is here only
+ to fulfill dependencies of other packages.
+ .
+ You probably will want to use this package if you have installed JVM
+ "by hand" or from package that does not provide java-virtual-machine
+ dependency.
diff --git a/dummy/java1-runtime-dummy.control b/dummy/java1-runtime-dummy.control
new file mode 100644
index 0000000..73fa334
--- /dev/null
+++ b/dummy/java1-runtime-dummy.control
@@ -0,0 +1,13 @@
+Package: java1-runtime-dummy
+Architecture: all
+Section: misc
+Priority: optional
+Depends: java-common
+Provides: java1-runtime
+Description: Dummy package providing java1-runtime
+ This package does NOT provide java1 runtime environment, it is here only to
+ fulfill dependencies of other packages.
+ .
+ You probably will want to use this package if you have installed the
+ environment "by hand" or from package that does not provide java1-runtime
+ dependency.
diff --git a/dummy/java2-compiler-dummy.control b/dummy/java2-compiler-dummy.control
new file mode 100644
index 0000000..c7509b8
--- /dev/null
+++ b/dummy/java2-compiler-dummy.control
@@ -0,0 +1,12 @@
+Package: java2-compiler-dummy
+Architecture: all
+Section: misc
+Priority: optional
+Depends: java-common, java2-runtime
+Provides: java2-compiler
+Description: Dummy package providing java2-compiler
+ This package does NOT provide java2 compiler binary, it is here only to
+ fulfill dependencies of other packages.
+ .
+ You probably will want to use this package if you have installed the compiler
+ "by hand" or from package that does not provide java2-compiler dependency.
diff --git a/dummy/java2-runtime-dummy.control b/dummy/java2-runtime-dummy.control
new file mode 100644
index 0000000..3d5cdff
--- /dev/null
+++ b/dummy/java2-runtime-dummy.control
@@ -0,0 +1,13 @@
+Package: java2-runtime-dummy
+Architecture: all
+Section: misc
+Priority: optional
+Depends: java-common
+Provides: java2-runtime
+Description: Dummy package providing java2-runtime
+ This package does NOT provide java2 runtime environment, it is here only to
+ fulfill dependencies of other packages.
+ .
+ You probably will want to use this package if you have installed the
+ environment "by hand" or from package that does not provide java2-runtime
+ dependency.
diff --git a/examples/classpath-from-jars-1 b/examples/classpath-from-jars-1
new file mode 100644
index 0000000..bea5802
--- /dev/null
+++ b/examples/classpath-from-jars-1
@@ -0,0 +1,12 @@
+# No shebang here: you have to source this file or to include
+# it into a shell startup file, since it changes the environment.
+# Bourne shell syntax.
+
+# From: Aaron Brashears <gila at gila.org>
+
+for jar in /usr/share/java/*.jar ; do
+ CLASSPATH=${CLASSPATH}:$jar
+done
+
+
+
diff --git a/html.dsl b/html.dsl
new file mode 100644
index 0000000..f80d183
--- /dev/null
+++ b/html.dsl
@@ -0,0 +1,29 @@
+<!--
+ html.dsl - stylesheets for HTML output.
+ Stolen from SGMLtools
+-->
+
+<!DOCTYPE style-sheet PUBLIC "-//James Clark//DTD DSSSL Style Sheet//EN" [
+<!ENTITY docbook.dsl PUBLIC "-//Norman Walsh//DOCUMENT DocBook HTML Stylesheet//EN" CDATA dsssl>
+]>
+<style-sheet>
+
+<style-specification id="html" use="docbook">
+<style-specification-body>
+
+
+(define %html-ext% ".html")
+(define %root-filename% "policy")
+(define %generate-article-toc% #t)
+(define %generate-article-titlepage% #t)
+(define %use-id-as-filename% #t)
+; (define %gentext-nav-use-tables% #f)
+
+;; Add other customization here
+
+
+</style-specification-body>
+</style-specification>
+
+<external-specification id="docbook" document="docbook.dsl">
+</style-sheet>
diff --git a/patches/0.16-policy.author b/patches/0.16-policy.author
new file mode 100644
index 0000000..730bf9e
--- /dev/null
+++ b/patches/0.16-policy.author
@@ -0,0 +1,7 @@
+Ahmed <ahmed at baizid.org>
+
+A small typo make Java policy invalid XML.
+
+References to the Debian policy do not seem correct.
+
+I propose the attached patch.
diff --git a/patches/0.16-policy.patch b/patches/0.16-policy.patch
new file mode 100644
index 0000000..a955c58
--- /dev/null
+++ b/patches/0.16-policy.patch
@@ -0,0 +1,56 @@
+--- policy.xml 2002-12-12 02:42:18.000000000 +0100
++++ policy.xml 2002-12-12 03:32:28.000000000 +0100
+@@ -133,7 +133,7 @@
+ environment.
+ </para>
+ <para>
+- I &should; use <filename>/etc/alternatives</filename>
++ They &should; use <filename>/etc/alternatives</filename>
+ for the name 'java' if they are command-line compatible with the
+ Sun's java program.
+ </para>
+@@ -155,7 +155,7 @@
+ <para>
+ Java compilers &must; provide &jc; and/or &j2c; and depend on
+ java-common. They &must; also depend on the needed runtime environemnt
+- (&j1r and/or &j2r;).
++ (&j1r; and/or &j2r;).
+ </para>
+
+ <para>
+@@ -175,11 +175,11 @@
+ <filename>/usr/bin</filename> and be executable. They can be Java
+ classes (using binfmt_misc) or wrappers. In any case, they &must; run
+ without specific environment variables (see
+- <ulink url="http://www.debian.org/doc/debian-policy/ch3.html#s3.8">Policy
+- 3.8</ulink>), for instance CLASSPATH. They &must; respect the Policy
++ <ulink url="http://www.debian.org/doc/debian-policy/ch-opersys.html#s10.9">Policy
++ 10.9</ulink>), for instance CLASSPATH. They &must; respect the Policy
+ rules for executables (for instance a manual page per executable, see
+- <ulink url="http://www.debian.org/doc/debian-policy/ch6.html#s6.1">
+- Policy 6.1</ulink>).
++ <ulink url="http://www.debian.org/doc/debian-policy/ch-docs.html#s13.1">
++ Policy 13.1</ulink>).
+ </para>
+ <para>
+ If they have their own auxiliary classes, they
+@@ -324,8 +324,8 @@
+ <listitem>
+ <para>
+ Sun's Community Source Licence. Can we use it? How?
+- Where can we <ulink url="http://www.sun.com/software/communitysource/faq.html">
+- find the text</ulink>?
++ The 2.3 version of the text can be found
++ <ulink url="http://wwws.sun.com/software/java2/license.html">here</ulink>.
+ </para>
+ </listitem>
+
+@@ -370,7 +370,7 @@
+ <title>Advices to Java packagers</title>
+
+ <para>
+- Warning: they are just advices, they are not part of the policy.
++ Warning: These are just advices, they are not part of the policy.
+ </para>
+
+ <itemizedlist>
diff --git a/patches/0.18-jni-policy.author b/patches/0.18-jni-policy.author
new file mode 100644
index 0000000..a2f932c
--- /dev/null
+++ b/patches/0.18-jni-policy.author
@@ -0,0 +1 @@
+From: Ben Burton <bab at debian.org>
diff --git a/patches/0.18-jni-policy.patch b/patches/0.18-jni-policy.patch
new file mode 100644
index 0000000..ae0f053
--- /dev/null
+++ b/patches/0.18-jni-policy.patch
@@ -0,0 +1,52 @@
+--- java-common-0.16/policy.xml 2002-09-26 00:53:03.000000000 +1000
++++ java-common-0.16.1/policy.xml 2003-02-09 23:16:23.000000000 +1100
+@@ -147,6 +147,14 @@
+ virtual machine, you &may; name the compiler package xxxx-dev.
+ </para>
+
++ <para>
++ Some Java classes implement their routines using a "native"
++ language (such as C). This native code is compiled and stored
++ in dynamic libraries (such as JNI modules) that are loaded at
++ runtime. If a virtual machine supports native code, it &must;
++ include the directory <filename>/usr/lib/jni</filename> in its
++ search path for these dynamic libraries.
++ </para>
+ </sect1>
+
+ <sect1 id="policy-compiler">
+@@ -245,18 +253,27 @@
+ This applies only to libraries, <emphasis>not</emphasis> to the core
+ classes provied by a the runtime environment.
+ </para>
+-
++
++ <para>
++ Some Java libraries rely on code written in a "native" language,
++ such as JNI (Java Native Interface) code. This native code is
++ compiled into separate dynamic libraries which are loaded by the
++ Java virtual machine at runtime.
++ </para>
++
+ <para>
+- If the Java code depends on code written in a "native" language,
+- for example Java Native Interface code, the compiled native code
+- &should; be shipped in a separate architecture-specific package
+- named libXXX[version]-jni. The package containing Java bytecode
+- &should; depend on this package.
++ If a Java library relies on native code, the dynamic libraries
++ containing this compiled native code &should; be installed into
++ the directory <filename>/usr/lib/jni</filename>. These dynamic
++ libraries &should; be shipped in a separate architecture-specific
++ package named libXXX[version]-jni. The package containing the Java
++ bytecode (generally libXXX[version]-java) &should; depend on
++ this package.
+ </para>
+ <para>
+ There may be situations, such as with very small packages,
+ where it is better to bundle the Java code and the native code
+- together into a single package. Such packages should be
++ together into a single package. Such packages &should; be
+ architecture-specific and follow the usual libXXX[version]-java
+ naming convention.
+ </para>
diff --git a/policy.xml b/policy.xml
new file mode 100644
index 0000000..9dca108
--- /dev/null
+++ b/policy.xml
@@ -0,0 +1,524 @@
+<?xml version='1.0'?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
+ "/usr/share/sgml/docbook/dtd/4.1/docbook.dtd"
+[
+<!ENTITY must "<emphasis>must</emphasis>">
+<!ENTITY mustnot "<emphasis>must not</emphasis>">
+<!ENTITY may "<emphasis>may</emphasis>">
+<!ENTITY should "<emphasis>should</emphasis>">
+<!ENTITY j1r "<emphasis>java1-runtime</emphasis>">
+<!ENTITY j2r "<emphasis>java2-runtime</emphasis>">
+<!ENTITY d-jdk "<emphasis>default-jdk</emphasis>">
+<!ENTITY d-jbdep "<emphasis>default-jdk-builddep</emphasis>">
+<!ENTITY d-jdoc "<emphasis>default-jdk-doc</emphasis>">
+<!ENTITY g-n-h "<emphasis>gcj-native-helper</emphasis>">
+<!ENTITY JVM "<acronym>JVM</acronym>">
+<!ENTITY JIT "<acronym>JIT</acronym>">
+<!ENTITY debpol "http://www.debian.org/doc/debian-policy">
+<!ENTITY djmail "<email>debian-java at lists.debian.org</email>">
+]>
+
+<book>
+ <bookinfo>
+ <title>Debian policy for Java</title>
+ <edition>$Revision:$ $Date:$</edition>
+ <authorgroup>
+ <author>
+ <surname>Thykier</surname>
+ <firstname>Niels</firstname>
+ <authorblurb>
+ <para>
+ <email>niels at thykier.net</email>
+ </para>
+ <para>
+ The current author of the java policy.
+ </para>
+ </authorblurb>
+ </author>
+ <author>
+ <surname>Lundqvist</surname>
+ <firstname>Ola</firstname>
+ <authorblurb>
+ <para>
+ <email>opal at debian.org</email>
+ </para>
+ <para>
+ A previous author of the java policy.
+ </para>
+ </authorblurb>
+ </author>
+ <author>
+ <surname>Bortzmeyer</surname>
+ <firstname>Stephane</firstname>
+ <authorblurb>
+ <para>
+ <email>bortzmeyer at debian.org</email>
+ </para>
+ <para>
+ The original author of the java policy.
+ </para>
+ </authorblurb>
+ </author>
+ <author>
+ <authorblurb>
+ <para>
+ Most issues of the java policy have been discussed on the
+ &djmail; mailinglist.
+ </para>
+ </authorblurb>
+ </author>
+ </authorgroup>
+ <abstract>
+ <title>Abstract</title>
+ <para>
+ This is the java policy for Debian. It begins with a
+ background description, continues with the real policy, some
+ issues to discuss and ends with some advices to java packagers.
+ </para>
+ <para>
+ The policy covers java virtual machines, java compilers, java
+ programs and java libraries.
+ </para>
+ </abstract>
+ </bookinfo>
+
+ <chapter id="background">
+ <title>Background</title>
+
+ <para>
+ There are several "subpolicies" in Debian. They all want to make
+ the <ulink url="&debpol;">Debian Policy</ulink> more precise when
+ it comes to a specific subject. See the Emacs subpolicy in package
+ emacsen-common for instance. As far as I know, the only subpolicy
+ for a programming language, is that of
+ <ulink
+ url="http://non-us.debian.org/~hertzog/perl-policy.html/">Perl</ulink>.
+ </para>
+
+ <para>
+ Feel free to report comments, suggestions and/or disagreements to the
+ java-common package (<email>java-common at packages.debian.org</email>)
+ or the Debian Java mailing list &djmail;. Change requests should be
+ sent as a bug to the java-common package.
+ </para>
+
+ </chapter>
+
+ <chapter id="policy">
+ <title>Policy</title>
+
+ <para>
+ Virtual packages are created: &j1r; and &j2r;.
+ </para>
+
+ <para>
+ Packages written in Java are separated in two categories: programs
+ and libraries. Programs are intended to be run by end-users. Libraries
+ are intended to help programs to run and to be used by developers.
+ </para>
+
+ <para>
+ Both &must; be shipped as Java bytecode (<filename>*.class</filename>
+ files, packaged in a <filename>*.jar</filename> archive) and with
+ an "Architecture: all". There are rare exceptions to this such as Eclipse
+ SWT. Exceptions to this rule can only be granted by the Java Team.
+ Requests &must; be sent to &djmail;.
+ </para>
+
+ <para>
+ The Java bytecode &may; additionally be shipped as machine code, as produced for example
+ by the GNU Compiler for Java, in a separate architecture-specific package.
+ </para>
+
+ <para>
+ Programs and libraries &should; enable JUnit tests, if these are present.
+ The build &may; ignore test failures.
+ </para>
+
+ <sect1 id="policy-vm">
+ <title>Virtual machines</title>
+
+ <para>
+ Java virtual machines &must; depend on java-common. They can also
+ provide the runtime environment that the package contains (&j1r;
+ and/or &j2r;). If it does not provide the files itself it &must;
+ depend on the needed runtime environment.
+ </para>
+
+ <para>
+ Packages that contain a runtime conforming to the Java 1.1
+ specification &should; provide &j1r;. Packages that contain a runtime
+ conforming to the Java 2 specification &should; provide &j2r;.
+ If a package conforms to both, then it &should; provide both; however,
+ packages that do not implement the methods from Java 1.1 that have been
+ deprecated in Java 2 &mustnot; provide &j1r;.
+ </para>
+
+ <para>
+ They &should; use <filename>/etc/alternatives</filename>
+ for the name 'java' if they are command-line compatible with the
+ Sun's java program.
+ </para>
+ <para>
+ They &should; have a CLASSPATH predefined which include the needed
+ runtime environment.
+ </para>
+
+ <para>
+ If a given source (like the JDK does) brings both a compiler and a
+ virtual machine, you &may; name the compiler package xxxx-dev.
+ </para>
+
+ <para>
+ Some Java classes implement their routines using a "native"
+ language (such as C). This native code is compiled and stored
+ in dynamic libraries (such as JNI modules) that are loaded at
+ runtime. If a virtual machine supports native code, it &must;
+ include the directory <filename>/usr/lib/jni</filename> in its
+ search path for these dynamic libraries.
+ </para>
+ </sect1>
+
+ <sect1 id="policy-programs">
+ <title>Java programs</title>
+
+ <para>
+ Programs &must; have one or more executables in one or more of
+ the directories defined by <ulink url="&debpol;/ch-opersys.html#s9.1">
+ 9.1</ulink> of the Debian Policy. These &must; either be a wrapper
+ script or a symlink to an executable jar. In any case, they &must; run
+ without specific environment variables (see
+ <ulink url="&debpol;/ch-opersys.html#s10.9">Policy 10.9</ulink>), for
+ instance CLASSPATH. They &must; respect the Policy rules for
+ executables (for instance a manual page per executable, see
+ <ulink url="&debpol;/ch-docs.html#s13.1">
+ Policy 13.1</ulink>).
+ </para>
+
+ <para>
+ If the package installs a jar (or a symlink to a jar) as an executable
+ the package &must; have an absolute dependency on jarwrapper or an
+ equivalent package, which allows jar files to be executed directly
+ from PATH like a normal program. The package &must; also ensure that
+ the correct class is used as main-class. As an example jarwrapper
+ uses the Main-Class attribute from the main part of the Manifest of the
+ jar file to determine this.
+ </para>
+
+ <para>
+ Additional classes in the package must be packaged in one or more JARs
+ which can be put into /usr/share/java (if they are intended to be used
+ by other programs) or into a private directory in
+ /usr/share/<package>.
+ </para>
+ <para>
+ Programs &must; depend on the needed runtime environment (&j1r; and/or
+ &j2r;).
+ </para>
+ <para>
+ There is no naming rules for programs, they are ordinary programs,
+ from the user point of view.
+ </para>
+ </sect1>
+
+ <sect1 id="policy-libraries">
+ <title>Java libraries</title>
+
+ <para>
+ Libraries are not separated between developers (-dev) and users
+ versions, since this is meaningless in Java.
+ </para>
+
+ <para>
+ Java libraries packages &must; be named libXXX[version]-java
+ (without the brackets), where the version part is optional and &should;
+ only contain the necessary part. The version part &should; only be
+ used to avoid naming collisions. The XXX part is the actual package
+ name used in the text below.
+ </para>
+
+ <para>
+ Their classes &must; be in <filename>jar</filename> archive(s) in
+ the directory <filename>/usr/share/java</filename>, with the name
+ <filename>packagename[-extraname]-fullversion.jar</filename>.
+ The extraname is optional and used internally within the package to
+ separate the different jars provided by the package. The fullversion
+ is the version of that jar file. In some cases that is not the same as
+ the package version.
+ </para>
+ <para>
+ Some package &must; also provide a symbolic link from
+ <filename>packagename-extraname.jar</filename> to the most compatible
+ version of the available
+ <filename>packagename-extraname-version.jar</filename> files.
+ </para>
+
+ <para>
+ Class files in a java library &must; be built with debug symbols.
+ </para>
+
+ <para>
+ All jar files &must; have a well-documented CLASSPATH, so
+ that developers should know what to add to their wrappers.
+ </para>
+
+ <para>
+ This applies only to libraries, <emphasis>not</emphasis> to the core
+ classes provided by a the runtime environment.
+ </para>
+
+ <para>
+ Some Java libraries rely on code written in a "native" language,
+ such as JNI (Java Native Interface) code. This native code is
+ compiled into separate dynamic libraries which are loaded by the
+ Java virtual machine at runtime.
+ </para>
+
+ <para>
+ If a Java library relies on native code, the dynamic libraries
+ containing this compiled native code &should; be installed into
+ the directory <filename>/usr/lib/jni</filename>. These dynamic
+ libraries &should; be shipped in a separate architecture-specific
+ package named libXXX[version]-jni. The package containing the Java
+ bytecode (generally libXXX[version]-java) &should; depend on
+ this package.
+ </para>
+ <para>
+ There may be situations, such as with very small packages,
+ where it is better to bundle the Java code and the native code
+ together into a single package. Such packages &should; be
+ architecture-specific and follow the usual libXXX[version]-java
+ naming convention.
+ </para>
+
+ <para>
+ Java library packages &should; compile the javadoc API of the
+ library. The API &must; link against the javadoc API of the
+ libraries it depends on. This includes the core java classes,
+ which are provided by &d-jdoc;. The API &must; be registered with
+ doc-base and &must; be installed in
+ <filename>/usr/share/doc/<package>/api/</filename> or
+ <filename>/usr/share/doc/<package>/api-<component>/</filename>.
+ </para>
+ <para>
+ The API &must; be placed in a separate doc package. This package
+ &must; recommend the doc packages it was linked against.
+ </para>
+ </sect1>
+
+ <sect1 id="policy-gcj-native">
+ <title>Native Java Bytecode (gcj packages)</title>
+
+ <para>
+ Java bytecode compiled into native code is referred to as
+ gcj-code and packages containing gcj-code as gcj-packages.
+ </para>
+
+ <para>
+ gcj-packages has been added in order to improve
+ performance of Java libraries and programs. This is
+ particularly useful on architectures where the JVM
+ does not have a &JIT;. However, this performance comes
+ at the cost of size, extra compilation time and
+ creates architecture dependent packages.
+ </para>
+
+ <para>
+ Packages &mustnot; ship gcj-code without the permission of
+ the Java team (&djmail;). Source packages that shipped
+ gcj-packages as of March 22nd,2010, have been given this
+ permission through the ratification of this policy.
+ </para>
+
+ <para>
+ A request for permission to add gcj should convince
+ the Java Team that the performance boost of adding
+ the gcj-packages out-weights the disadvantages.
+ </para>
+
+ <para>
+ Source packages compiling gcj-packages &must; Build-Depend on
+ &g-n-h; (formerly known as &d-jbdep;). The gcj-code &should;
+ only be shipped for a selected set of architectures.
+ </para>
+
+ <para>
+ The gcj-code &must; be installed in <filename>/usr/lib/gcj/</filename>
+ and shipped separately from the original jar file. The gcj-package
+ &must; also install the classmap file generated by aot-compile in
+ <filename>/usr/share/gcj/classmap.d/</filename>.
+ </para>
+
+ <para>
+ The gcj-package &must; call rebuild-gcj-db in the postinst and
+ postrm script, if rebuild-gcj-db is present.
+ </para>
+
+ <para>
+ The gcj-package &must; depend on the package providing the jar
+ file, it is a native compilation.
+ The package containing the jar file &must; declare either a
+ Suggests or a Recommends relationship on the gcj-package.
+ </para>
+
+ </sect1>
+
+ <sect1 id="policy-politics">
+ <title>Main, contrib or non-free</title>
+ <para>
+ About politics: packaging Java stuff changes nothing to the
+ rules Debian uses to find if a program is free or not. Since there are
+ not many free Java tools, keep in mind the following:
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ If your source package can compile (correctly) only
+ with non-free tools, it cannot go to main. If your package itself
+ is free, it &must; go to contrib.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ If your binary package can run only with non-free
+ virtual machines
+ (<ulink
+ url="http://www.gnu.org/software/classpath">GNU-Classpath</ulink> has
+ a list of free versions), it cannot go to main. If
+ your package itself is free, it &must; go to contrib.
+ Since java libraries do not have a runtime dependency,
+ this rule does not apply to them.
+ </para>
+ </listitem>
+
+ </itemizedlist>
+ </sect1>
+ </chapter>
+
+ <chapter id="to-discuss">
+ <title>Issues to discuss</title>
+
+ <para>
+ The following points are discussions about the policy, either
+ because they have to be studied more, or are controversial.</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Name and existence of the repository. It was removed
+ in the latest version.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ The symbolic links in <filename>/usr/share/java</filename> be
+ made by a script instead, similar to the c-libraries.
+ </para>
+ </listitem>
+
+
+ <listitem>
+ <para>Core classes (<filename>java.*</filename>). More study
+ needed.</para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Sun's Community Source Licence. Can we use it? How?
+ The 2.3 version of the text can be found
+ <ulink url="http://wwws.sun.com/software/java2/license.html">here</ulink>.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>All jars must have a good CLASSPATH documentation, but
+ how should it be documented. The best solution is probably in some
+ computer parsable format to make it even easier for the developer.
+ </para>
+ <para>It should exist some tool to parse this. How should it
+ work?
+ </para>
+ <para>Should the tool also be used to create the necessary symbolic
+ links needed by servlets under tomcat?
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Should there be a default CLASSPATH, similar to a
+ repository? Which jars should be included in that? A standard and
+ one optional part? If there are a default CLASSPATH (in the
+ wrapper) how should it be overridden?
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>How to check for a good enough &JVM;, and to select a
+ proper one to use. Are <filename>/etc/alternatives</filename>
+ not good enough?
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Should the &JVM; internal classes be possible to
+ override entirely and how?
+ </para>
+ </listitem>
+ </itemizedlist>
+ </chapter>
+
+ <chapter id="advices">
+ <title>Advices to Java packagers</title>
+
+ <para>
+ Warning: These are just advices, they are not part of the policy.
+ </para>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ Be sure to manage all dependencies by hand in
+ <filename>debian/control</filename>. Debian development tools cannot
+ find them automatically like they do with C programs and libraries
+ (or like dh_perl does it for Perl, a volunteer to write dh_java
+ would be welcome).
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ You can suppress many calls in <filename>debian/rules</filename>
+ which are meaningless for Java, like dh_strip and dh_shlibdeps.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Source package handling is painful, since most Java
+ upstream programs come with <filename>.class</filename> files. I
+ suggest to make a new <filename>.orig</filename> tarball after
+ cleaning them, otherwise, dpkg-source will complain.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>
+ Java properties files are probably better under
+ <filename>/etc</filename> and flagged as configuration files (this
+ will be integrated in the policy, one day).
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Java packages &should; be built with &d-jdk; if possible.
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ </chapter>
+
+</book>
diff --git a/scripts/completion/update-java-alternatives b/scripts/completion/update-java-alternatives
deleted file mode 100644
index 80c00db..0000000
--- a/scripts/completion/update-java-alternatives
+++ /dev/null
@@ -1,65 +0,0 @@
-#
-# update-java-alternatives(8) completion
-#
-
-#
-# List the available alternatives
-#
-_update-java-alternatives_list()
-{
- shopt -s dotglob
-
- top=/usr/lib/jvm
- for i in ${jinfo:-$top/*.jinfo}; do
- alias=$(basename ${i%.jinfo})
- alias=${alias#.}
- echo $alias
- done
-}
-
-_update-java-alternatives()
-{
- local cur prev options
-
- cur=`_get_cword`
- prev=${COMP_WORDS[COMP_CWORD-1]}
-
- options=()
-
- # complete but doesn't display the short options
- if [[ $cur == "-s" || $cur == "-l" || $cur == "-a" || $cur == "-h" || $cur == "-v" ]] ; then
- COMPREPLY=( $( compgen -W '$cur' -- $cur ) )
- return 0
- fi
-
- # suggest an action if none was specified yet
- if [[ ! "${COMP_WORDS[@]}" =~ " --set " ]] && [[ ! "${COMP_WORDS[@]}" =~ " -s " ]] && [[
- ! "${COMP_WORDS[@]}" =~ " --list " ]] && [[ ! "${COMP_WORDS[@]}" =~ " -l " ]] && [[
- ! "${COMP_WORDS[@]}" =~ " --auto " ]] && [[ ! "${COMP_WORDS[@]}" =~ " -a " ]] && [[
- ! "${COMP_WORDS[@]}" =~ " --help " ]] && [[ ! "${COMP_WORDS[@]}" =~ " -h " ]]; then
- options+=( --help --list --auto --set )
- fi
-
- # add the --set sub options
- if [[ " ${COMP_WORDS[@]} " =~ " --set " ]] || [[ " ${COMP_WORDS[@]} " =~ " -s " ]]; then
- if [[ ! "${COMP_WORDS[@]}" =~ " --verbose " ]] && [[ ! " ${COMP_WORDS[@]} " =~ " -v " ]]; then options+=("--verbose"); fi
- if [[ ! "${COMP_WORDS[@]}" =~ " --plugin " ]]; then options+=("--plugin"); fi
- if [[ ! "${COMP_WORDS[@]}" =~ " --jre " ]]; then options+=("--jre"); fi
- if [[ ! "${COMP_WORDS[@]}" =~ " --jre-headless " ]]; then options+=("--jre-headless"); fi
- fi
-
- case "$prev" in
- -s|--set|-l|--list)
- COMPREPLY=( $( compgen -W '$(_update-java-alternatives_list)' -- $cur ) )
- ;;
- -h|--help)
- COMPREPLY=( )
- ;;
- *)
- COMPREPLY=( $( compgen -W '${options[@]}' -- $cur ) )
- ;;
- esac
-
- return 0
-} &&
-complete -F _update-java-alternatives update-java-alternatives
diff --git a/scripts/update-java-alternatives b/scripts/update-java-alternatives
index 9eea19c..5e31a68 100755
--- a/scripts/update-java-alternatives
+++ b/scripts/update-java-alternatives
@@ -8,7 +8,7 @@ usage()
{
rv=$1
cat >&2 <<-EOF
- usage: $prog [--jre-headless] [--jre] [--plugin] [-v|--verbose]
+ usage: $prog [--jre-headless] [--jre] [--plugin] [ -t|--test|-v|--verbose]
-l|--list [<jname>]
-s|--set <jname>
-a|--auto
@@ -46,6 +46,9 @@ while [ "$#" -gt 0 ]; do
[ "$#" -gt 0 ] || usage 1
jname=$1
;;
+ -t|--test)
+ dryrun=yes
+ uaopts="$uaopts --test";;
-v|--verbose)
verbose=yes
uaopts="${uaopts/--quiet/}";;
@@ -123,7 +126,7 @@ do_list()
alias=$(basename ${i%.jinfo})
alias=${alias#.}
prio=$(awk -F= '/priority=/ {print $2}' $i)
- printf "%-30s %-10s %s\n" $alias "$prio " $top/$alias
+ echo $alias $prio $top/$alias
[ -n "$verbose" ] && egrep "$which" $i
done
}
diff --git a/scripts/update-java-alternatives.8 b/scripts/update-java-alternatives.8
index 87a2a69..07c4bcf 100644
--- a/scripts/update-java-alternatives.8
+++ b/scripts/update-java-alternatives.8
@@ -2,7 +2,7 @@
.SH NAME
update-java-alternatives \- update alternatives for jre/sdk installations
.SH SYNOPSIS
-.B update-java-alternatives [--jre] [--plugin] [-v|--verbose]
+.B update-java-alternatives [--jre] [--plugin] [-t|--test|-v|--verbose]
\-l|--list [<jname>]
\-s|--set <jname>
\-a|--auto
@@ -38,6 +38,10 @@ Limit the actions to alternatives providing browser plugins.
\fB\-h|\-\-help\fR
Display a help message.
.TP
+\fB\-t|\-\-test\fR
+Don't actually do anything, just say what would be done. The implementation
+status of this option is the same as for update-alternatives (not implemented).
+.TP
\fB\-v|\-\-verbose\fR
Verbose output.
--
Alioth's /usr/local/bin/git-commit-notice on /srv/git.debian.org/git/pkg-java/java-common.git
More information about the pkg-java-commits
mailing list