Removed the policy and the FAQ (now in the java-policy package)

17 files changed, 5 insertions, 3335 deletions

diff --git a/Makefile b/Makefile
deleted file mode 100644
index 3184283..0000000
--- a/Makefile
+++ /dev/null
@@ -1,86 +0,0 @@
-#!/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 script-install
-
-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
deleted file mode 100644
index 75c2ec5..0000000
--- a/debian-java-faq/Makefile
+++ /dev/null
@@ -1,42 +0,0 @@
-# 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
deleted file mode 100644
index 26cce53..0000000
--- a/debian-java-faq/debian-java-faq.it.sgml
+++ /dev/null
@@ -1,1953 +0,0 @@
-<!doctype debiandoc system>
-
-<book>
-
-<titlepag>
-<title>Debian Java FAQ</title>
-<author>
-<name>Javier Fernández-Sanguino Peña </name>
-<email>jfs@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. &Egrave; 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>. &Egrave; 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>&Egrave; 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. 
-&Egrave; 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>&Egrave; 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>
-&Egrave; disponibile anche Japhar.
-
-<p>
-libgcj (la libreria run-time per gcj) adesso include interprete e
-ClassLoader.
-
-<p>tya, un compilatore JIT, è adesso disponibile.
-
-
-<sect>&Egrave; 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>&Egrave; 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>&Egrave; 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>&Egrave; disponibile un tool Jar?
-
-<p>
-<package>FastJar</package> che è davvero molto veloce.
-<package>Kaffe</package> ha anche un tool jar.
-
-
-<sect>&Egrave; 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. &Egrave;
-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>&Egrave; 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.
-
-&Egrave; 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. &Egrave; 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>&Egrave; 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>. &Egrave; 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>. &Egrave; 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>. &Egrave; 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>. &Egrave; 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>
-&Egrave; 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>&Egrave; 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&amp;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.  &Egrave; 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>&Egrave; 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>&Egrave; disponibile una politica Java per Debian?
-
-<p>
-&Egrave; 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.
-&Egrave; 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>
-&Egrave; 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>
-&Egrave; 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. &Egrave; 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@yahoo.it/, l'aggiornamento
-alla presente versione da  CarloS <email/enne.enne@tiscalinet.it/,
-la conversione in SGML e la revisione da
-Ferdinando Ferranti <email/zappagalattica@inwind.it/.
-
-</appendix>
-
-
-</book>
diff --git a/debian-java-faq/debian-java-faq.sgml b/debian-java-faq/debian-java-faq.sgml
deleted file mode 100644
index 7935cdd..0000000
--- a/debian-java-faq/debian-java-faq.sgml
+++ /dev/null
@@ -1,502 +0,0 @@
-<!doctype debiandoc system>
-
-<book>
-
-<titlepag>
-<title>Debian Java FAQ.</title>
-<author>
-<name>Torsten Werner</name>
-<email>twerner@debian.org</email>
-</author>
-<author>
-<name>Niels Thykier</name>
-<email>niels@thykier.net</email>
-</author>
-<author>
-<name>Javier Fernández-Sanguino Peña</name>
-<email>jfs@debian.org</email>
-</author>
-<author>
-<name>Sylvestre Ledru</name>
-<email>sylvestre@debian.org</email>
-</author>
-<version>$Revision: 7831 $, $Date: 2013-06-05 21:17:15 +0100 $
-
-<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 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.
-Since May 2007, Sun/Oracle with some partners like Red Hat provide a free
-implementation released under the GNU GPL called OpenJDK.
-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 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>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>Sun's OpenJDK 6, available since the Debian 5.0 <em>Lenny</em>
-release in the <em>main</em> section.
-
-<item>Oracle's OpenJDK 7, available since the Debian 7.0 <em>Wheezy</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>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="java6">Java 6 and 7
-
-<p>There are binary packages available for the Java 6 and Java 7 platforms
-since the Debian 7.0 ('wheezy') release.
-
-Once this is done and you have updated your package database. You can either
-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>Similarly, you can install the Java 7 development kit:
-
-<example>
-apt-get install openjdk-7-jdk
-</example>
-
-or the Java 7 runtime environment:
-
-<example>
-apt-get install openjdk-7-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-1.6.0-openjdk-amd64
-</example>
-
-Or for java 7:
-
-<example>
-update-java-alternatives -s java-1.7.0-openjdk-amd64
-</example>
-
-<sect1 id="openjdk">Oracle proprietary JVM
-
-<p>Since the version 7 of the OpenJDK, the proprietary JVM developments are done on the OpenJDK. That means that the OpenJDK is strongly tested and high quality.
-<p>However, some users might want to use the Oracle JVM for the proprietary extensions (for example: the browser plugin). For such need, Debian provides a tool called <url id="http://packages.debian.org/sid/java-package" name="java-package">. The program make-jpkg will take an upstream archive and convert it to a Debian package. For example:
-<example>
-    make-jpkg jdk-6u31-linux-x64.bin
-</example>
-<p>For more information see <url id="http://www.oracle.com/technetwork/java/index.html" name="Oracle Technology Network 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 the
-javadoc installed on the system. This can be done by passing javadoc
-the "-link" argument or by using the &lt;link&gt; 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]
-
-&lt;!-- Ant example of linking against system doc --&gt;
-&lt;javadoc [attributes]&gt;
-    &lt;link href="/usr/share/doc/default-jdk-doc/api/" /&gt;
-    [other tags]
-&lt;/javadoc&gt;
-</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>Managing Java (for users and administrators)
-<p>
-By default Java programs shipped with Debian will use the java
-in PATH. Some of them may respect the JAVA_HOME variable
-(usually only if upstream supports this) or have command line
-arguments to select a different java implementation.
-</p>
-
-<p>
-Unfortunately not all java implementations work as well as others.
-So some times it may be necessary to change the current java and
-Debian provides an easy way to change the default java in PATH by
-using update-java-alternatives (from the <package>java-common
-</package>). Some examples of how to do this are:
-</p>
-
-<p>
-<example>
-# List available java implementations
-$ update-java-alternatives --list
-# Use openjdk-6 
-$ update-java-alternatives --set java-6-openjdk
-# Use the non-free sun java.
-$ update-java-alternatives --set java-6-sun
-# Use the non-free sun java only for the web plugin
-$ update-java-alternatives  --plugin --set java-6-sun
-</example>
-</p>
-
-<p>
-For more information, please read the manpage (or the --help
-output) of update-java-alternatives. Also please note that
-update-java-alternatives is a frontend for update-alternatives.
-</p>
-
-<chapt>Java Virtual Machines (JVM)
-<p>
-<sect>What JVMs are available in Debian?
-
-<p>The following JVMs are currently available in Debian Wheezy:
-
-<list>
-<item><package>openjdk-6-jre</package></item>
-<item><package>openjdk-7-jre</package></item>
-<item><package>gcj-4.7-jre</package></item>
-</list>
-
-</p>
-
-<p>The following lists JVMs available in Debian 6.0 release ('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>
-<sect>What Java Compilers are available in Debian?
-<p>
-<list>
-
-<item><package>openjdk-6-jdk</package></item>
-
-<item><package>openjdk-7-jdk</package></item>
-
-<item><package>gcj</package>. Compiles Java source to native code,
-also source to bytecode, or bytecode to native code. Please note that the
-support of the Java language is not completed.</item>
-
-</list>
-
-</p>
-
-<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. 
-
-<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:openjdk-7" name="openjdk-7"></item>
-<item><url id="http://bugs.debian.org/src:gcj-4.7" name="gcj-4.7"></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>How can I use the proprietary version of the JDK/JRE from Oracle as a Debian package?
-<p>
-The package <url id="http://packages.debian.org/wheezy/java-package/" name="java-package"> provides an easy way to convert an upstream installer into a Debian package. It should be as easy as:
-<example>make-jpkg ~/Downloads/jdk-6u31-linux-x64.bin
-</example>
-<p>For more information, see this <url id="http://sylvestre.ledru.info/blog/2012/02/29/java_package_replacement_of_sun_java6" name="Blog article">
-
-<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. However, the usage of the OpenJDK is recommended. For example, gcj does not provide any support of Swing (the Java GUI API).
-
-<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-6-plugin or icedtea-7-plugin in <em>wheezy</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.
-
-<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.
-
-<p>A list of missing packages is maintained on the 
-<url id="http://wiki.debian.org/Java/RequestedPackages" name="Debian Wiki - Java Packaging Wishlist">.
-
-</book>
diff --git a/debian/README.Debian b/debian/README.Debian
deleted file mode 100644
index c0bd03f..0000000
--- a/debian/README.Debian
+++ /dev/null
@@ -1,8 +0,0 @@
-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
diff --git a/debian/changelog b/debian/changelog
index c3e5620..910038f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,7 @@ java-common (0.54) UNRELEASED; urgency=medium
 
   * Team upload.
   * Use OpenJDK 8 on mips, mipsel and mips64el.
+  * The Java Policy and the FAQ have been moved to the new java-policy package.
   * 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
diff --git a/debian/control b/debian/control
index fba3611..3fed2c3 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,6 @@ Priority: optional
 Maintainer: Debian Java Maintainers <pkg-java-maintainers@lists.alioth.debian.org>
 Uploaders: Matthias Klose <doko@debian.org>, Torsten Werner <twerner@debian.org>,
 Build-Depends: debhelper (>= 9)
-Build-Depends-Indep: debiandoc-sgml, docbook-utils, docbook-xml, lynx
 Standards-Version: 3.9.6
 Vcs-Git: git://anonscm.debian.org/pkg-java/java-common.git
 Vcs-Browser: http://anonscm.debian.org/cgit/pkg-java/java-common.git
@@ -15,15 +14,10 @@ Architecture: all
 Multi-Arch: foreign
 Depends: ${misc:Depends}
 Suggests: default-jre
-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.
+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.
 
 Package: default-jre
 Architecture: any
diff --git a/debian/java-common.dirs b/debian/java-common.dirs
deleted file mode 100644
index 13c9f03..0000000
--- a/debian/java-common.dirs
+++ /dev/null
@@ -1 +0,0 @@
-usr/share/java
diff --git a/debian/java-common.doc-base.faq b/debian/java-common.doc-base.faq
deleted file mode 100644
index b7a4771..0000000
--- a/debian/java-common.doc-base.faq
+++ /dev/null
@@ -1,13 +0,0 @@
-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
deleted file mode 100644
index 70bc900..0000000
--- a/debian/java-common.doc-base.policy
+++ /dev/null
@@ -1,13 +0,0 @@
-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/rules b/debian/rules
index fa6d935..96b434c 100755
--- a/debian/rules
+++ b/debian/rules
@@ -87,14 +87,12 @@ build-indep: build-stamp
 build-stamp:
 	dh_testdir
 
-	$(MAKE)
 	touch build-stamp
 
 clean:
 	dh_testdir
 	dh_testroot
 	rm -f build-stamp install-stamp
-	$(MAKE) clean
 
 	dh_clean
 
@@ -106,7 +104,6 @@ install-stamp: build-indep
 	dh_installdirs -i
 
 	dh_installdocs -i
-	$(MAKE) install DESTDIR=$(CURDIR)/debian/java-common
 
 	touch install-stamp
 
diff --git a/html.dsl b/html.dsl
deleted file mode 100644
index f80d183..0000000
--- a/html.dsl
+++ /dev/null
@@ -1,29 +0,0 @@
-<!--
-    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
deleted file mode 100644
index 730bf9e..0000000
--- a/patches/0.16-policy.author
+++ /dev/null
@@ -1,7 +0,0 @@
-Ahmed <ahmed@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
deleted file mode 100644
index a955c58..0000000
--- a/patches/0.16-policy.patch
+++ /dev/null
@@ -1,56 +0,0 @@
---- 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
deleted file mode 100644
index a2f932c..0000000
--- a/patches/0.18-jni-policy.author
+++ /dev/null
@@ -1 +0,0 @@
-From: Ben Burton <bab@debian.org>
diff --git a/patches/0.18-jni-policy.patch b/patches/0.18-jni-policy.patch
deleted file mode 100644
index ae0f053..0000000
--- a/patches/0.18-jni-policy.patch
+++ /dev/null
@@ -1,52 +0,0 @@
---- 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
deleted file mode 100644
index 8a51ee5..0000000
--- a/policy.xml
+++ /dev/null
@@ -1,559 +0,0 @@
-<?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 j5r "<emphasis>java5-runtime</emphasis>">
-<!ENTITY j5rh "<emphasis>java5-runtime-headless</emphasis>">
-<!ENTITY j6r "<emphasis>java6-runtime</emphasis>">
-<!ENTITY j6rh "<emphasis>java6-runtime-headless</emphasis>">
-<!ENTITY j7r "<emphasis>java7-runtime</emphasis>">
-<!ENTITY j7rh "<emphasis>java7-runtime-headless</emphasis>">
-<!ENTITY j8r "<emphasis>java8-runtime</emphasis>">
-<!ENTITY j8rh "<emphasis>java8-runtime-headless</emphasis>">
-<!ENTITY d-jdk "<emphasis>default-jdk</emphasis>">
-<!ENTITY d-jre "<emphasis>default-jre</emphasis>">
-<!ENTITY d-jre-h "<emphasis>default-jre-headless</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@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@thykier.net</email>
-	  </para>
-	  <para>
-	    The current author of the Java policy.
-	  </para>
-	</authorblurb>
-      </author>
-      <author>
-	<surname>Ledru</surname>
-	<firstname>Sylvestre</firstname>
-	<authorblurb>
-	  <para>
-	    <email>sylvestre@debian.org</email>
-	  </para>
-	</authorblurb>
-
-      </author>
-      <author>
-	<surname>Lundqvist</surname>
-	<firstname>Ola</firstname>
-	<authorblurb>
-	  <para>
-	    <email>opal@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@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>
-      <para>
-        This policy is published under the GNU GPL v2 or later license.
-      </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://pkg-perl.alioth.debian.org/policy.html">Perl</ulink>.
-    </para>
-    
-    <para>
-      Feel free to report comments, suggestions and/or disagreements to the
-      java-common package (<email>java-common@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;, &j2r;, &j5r;, &j5rh;, &j6r;, &j6rh;,
-      &j7r;, &j7rh;, &j8r; and &j8rh;.
-    </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 unit 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 supports (&j1r;,
-	&j2r;, &j8r;, &j8rh;, etc). If it does not provide the files itself
-	it &must; depend on the needed runtime environment.
-      </para>
-
-      <para>
-	They &should; use <filename>/etc/alternatives</filename>
-	for the name 'java' if they are command-line compatible with the
-	Oracle'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="build-pkg">
-      <title>Building Java packages</title>
-
-      <para>
-        Since it is common for Java source tarball to ship jar files of third party
-        libraries, creating a repack script to remove them from the upstream tarball
-        is mandatory.
-      </para>
-
-      <para>
-        Packages must be built with &d-jdk;. This package provides a dependency
-        on the recommended Java Development Kit. If needed, the right
-        <emphasis role="italic">JAVA_HOME</emphasis> is
-        <emphasis role="italic">/usr/lib/jvm/default-java/</emphasis>
-      </para>
-
-      <para>
-        The <ulink url="http://packages.debian.org/sid/javahelper">javahelper package</ulink>
-        provides helper to build either with CDBS or dh. They are strongly
-        recommended for Java packaging.
-      </para>
-
-      <para>
-        For Maven based packages, the usage of <ulink url="http://packages.debian.org/sid/maven-debian-helper">maven-debian-helper</ulink>
-        is recommended.
-      </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/&lt;package&gt;.
-      </para>
-
-      <para>
-	Programs &must; depend on the needed runtime environment (&d-jre; or
-	&d-jre-h; if need a GUI or not, and <emphasis>java&lt;N&gt;-runtime</emphasis>
-	or <emphasis>java&lt;N&gt;-runtime-headless</emphasis> as provided
-	by alternative Java environments).
-      </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>
-        Libraries &must; not depend on a Java runtime.
-      </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/&lt;package&gt;/api/</filename> or
-	<filename>/usr/share/doc/&lt;package&gt;/api-&lt;component&gt;/</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>
-
-      </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>
-	  Minimal version of the class version files (50 for Java 6, 51 for Java 7, etc)
-	</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>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>
-	  Many calls in <filename>debian/rules</filename> can be removed
-	  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>
-    </itemizedlist>
-    
-  </chapter>
-  
-</book>