diff options
author | Emmanuel Bourg <ebourg@apache.org> | 2015-10-07 21:31:37 +0200 |
---|---|---|
committer | Emmanuel Bourg <ebourg@apache.org> | 2015-10-08 00:22:19 +0200 |
commit | a426b9ed992fd467856bce42ce1b960379911d9b (patch) | |
tree | 36d74cbac8aba3f8ee28c3b8b842a419d4ce35ed | |
parent | 131e8e5f43cfb2e4276cf3d1eaae2825ceb2e0e5 (diff) | |
download | java-common-a426b9ed992fd467856bce42ce1b960379911d9b.tar.gz |
Removed the policy and the FAQ (now in the java-policy package)
-rw-r--r-- | Makefile | 86 | ||||
-rw-r--r-- | debian-java-faq/Makefile | 42 | ||||
-rw-r--r-- | debian-java-faq/debian-java-faq.it.sgml | 1953 | ||||
-rw-r--r-- | debian-java-faq/debian-java-faq.sgml | 502 | ||||
-rw-r--r-- | debian/README.Debian | 8 | ||||
-rw-r--r-- | debian/changelog | 1 | ||||
-rw-r--r-- | debian/control | 14 | ||||
-rw-r--r-- | debian/java-common.dirs | 1 | ||||
-rw-r--r-- | debian/java-common.doc-base.faq | 13 | ||||
-rw-r--r-- | debian/java-common.doc-base.policy | 13 | ||||
-rwxr-xr-x | debian/rules | 3 | ||||
-rw-r--r-- | html.dsl | 29 | ||||
-rw-r--r-- | patches/0.16-policy.author | 7 | ||||
-rw-r--r-- | patches/0.16-policy.patch | 56 | ||||
-rw-r--r-- | patches/0.18-jni-policy.author | 1 | ||||
-rw-r--r-- | patches/0.18-jni-policy.patch | 52 | ||||
-rw-r--r-- | policy.xml | 559 |
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. È divertente da usare. Il tool javadoc crea -documentazione da commenti nel codice, cosicché, commentando, si ottiene la -documentazione gratis. - - - -<sect>Cos'è un JIT? - -<p> -JIT è un acronimo di Just In Time. Si riferisce ad un plugin per la -VM che velocizza l'esecuzione della VM nella compilazione in -bytecode del codice sorgente nativo. - - -<sect>Dove trovare altre informazioni su Java? - - -<p> -Naturalmente, <url id="http://java.sun.com"> sarebbe la prima fonte -in cui trovare informazioni su Java, dal momento che si tratta della -compagnia che ha dato origine al progetto (Sun). Comunque, altre -buone fonti di informazioni per Java e Linux possono essere le seguenti: - - -<list> -<item>Le pagine della Sun <url id="http://java.sun.com/linux/" name="Java Technology on Linux">. -<item>Blackdown's <url id="http://www.blackdown.org/java-linux/docs/support/faq-release/FAQ-java-linux.html" name="Java and Linux FAQ">. -<item>GNU <url id="http://www.gnu.org/software/java/" name="Java software"> -<item>Enterprise in a Nutshell di Gary Meyer: <url id=" -http://en.tldp.org/HOWTO/Enterprise-Java-for-Linux-HOWTO.html">. -Qui viene spiegato come realizzare un ambiente che comprenda JDK, -web server, servlet Java, accesso JDBC ad un database ed a EJB. -Per chi è interessato, si veda anche Java Enterprise in a Nutshell: -<url id="http://www.oreilly.com/catalog/jentnut/">. -<item>Il <url id="http://www.linuxjournal.com/" name="Linux Journal Magazine">, -vale la pena di leggere i seguenti articoli: -<list> -<item>Numero 105 <url id="http://www.linuxjournal.com/article.php?sid=4860" -name="Compiling Java with CGJ"> -<item><url id="http://www.linuxjournal.com/article.php?sid=6290" -name="Getting Started with Java on Linux"> -<item>Numero 94 <url id="http://www.linuxjournal.com/article.php?sid=5612" -name="Embedded Linux and Java--Wave of the Future?"> -<item><url id="http://www.linuxjournal.com/article.php?sid=4819" -name="Using and Writing Java Servlets"> -<item>Numero 66 <url -id="http://www.linuxjournal.com/lj-issues/issue66/3119.html" -name="Java servlets"> e <url -id="http://www.linuxjournal.com/lj-issues/issue66/3224.html" -name="Java 2 SDK">. - -</list> - -<item>La <url id="http://www.linuxgazette.com/" name="Linux Gazette -Magazine">, i seguenti articoli potrebbero essere utili: -<list> -<item>Numero 87 <url id="http://www.linuxgazette.com/issue87/jenkins.html" -name="A Keep-Alive Program You Can Run Anywhere"> -<item>Numero 69 <url id="http://www.linuxgazette.com/issue69/peda.html" -name="Installing Tomcat on Linux"> -<item>Numero 48 <url id="http://www.linuxgazette.com/issue48/lane.html" -name="Linux, Java and XML"> -<item>Numero 45 <url -id="http://tldp.org/LDP/LG/issue45/gibbs/Linux_java.html" -name="Setting Up A Java Development Enviroment For Linux"> -<item>Numero 33 <url id="http://tldp.org/LDP/LG/issue33/burtch.html"> -<item>Numero 32 <url id="http://tldp.org/LDP/LG/issue32/rojansky.html" - name="Java and Linux"> -<item>Numero 25 <url id="http://tldp.org/LDP/LG/issue29/hamilton.html"> -</list> - - -<!-- No longer available -<item>Linux users worlwide includes information on how to use Java an -Linux <url id="http://linuxusers.webprovider.com">. ---> - -<!-- Pretty old and not very much maintainted ATM -<item>Linux Java Tips and Hints at <url -id="http://www.parnasse.com/java.shtml">. ---> - -<!-- no longer available -<item>The Java and Linux Page <url id="http://www.geocities.com/SiliconValley/Platform/8187/java/Linux_java.html"> ---> - -<item><url id="http://www.linuxfocus.org/" name="LinuxFocus">, un giornale libero disponibile in più lingue: -<list> - -<item>marzo 2003: <url -id="http://www.linuxfocus.org/English/March2003/article285.shtml" -name="Accessing PostgreSQL through JDBC via a Java SSL tunnel"> - -<item>gennaio 1999: <url -id="http://www.linuxfocus.org/English/January1999/article78.html" -name="Programming with Java, part II"> - -<item>luglio 1998: <url -id="http://www.linuxfocus.org/English/July1998/article57.html" -name="Programming with Java, part I"> -</list> - -<item>Il Java-CGI HOWTO di David H. Silber:<url -id="http://en.tldp.org/HOWTO/Java-CGI-HOWTO.html"> -Qui viene spiegato come impostare il proprio server in modo da far -funzionare le CGI Java. Vale forse la pena di dare un'occhiata alle servlet. -<item>Java Programming on Linux di Nathan Meyers, -con sito presso <url id="http://www.javalinux.net/">, libro dedicato -all'uso di Java in Linux (anche se non c'è una sua versione in linea). - -</list> - -Altri siti web riguardanti Java potrebbero essere: -<list> -<item>The Java Lobby <url id="http://www.javalobby.org">. -<item>Brewing Java: un piccola guida, presso <url -id="http://metalab.unc.edu/javafaq/javatutorial.html">. - -</list> - -Per informazioni gratuite su Java, si può consultare la rete con Google; per -applet con codice sorgente, -<url id="http://javaboutique.internet.com/javasource.html">. -Si veda anche <ref id="free"> per puntatori disponibili alle piattaforme -java gratuite, che potrebbero anche non essere riportati nelle pagine GNU in -rete dedicate a Java. - - -<sect>Dove posso fare domande su java in Debian? - -<p> -Il posto giusto dove porre domande è -<email>debian-java at lists.debian.org</email>. È possibile -iscriversi presso la pagina delle -<url id="http://www.debian.org/MailingLists/subscribe" - name="iscrizioni alle mailing list">. - - - - -<chapt>La situazione di Java in Debian GNU/Linux 3.0 (Woody) - - - -<sect>Dove sta andando Java? - -<p> -Innanzitutto, è fondamentale capire che la strategia nella concezione di -Debian è di ottenere una piattaforma che sia al 100% software libero. -Per questo motivo, alcuni dei tool non sono disponibili - -<footnote> -Notevoli i port su Linux del Sun Java Developer Toolkit (SDK) o del -Java Runtime Environment (JRE) di Blackdown. -Per quelli che si possono recuperare da Blackdown, si veda in -<ref id="blackdown-pack">. - -</footnote> - -nella distribuzione standard di Debian per motivi concernenti le licenze e -non per motivazioni tecniche (si veda in <ref id="license-concerns">). - -<p> -Detto questo, sostanzialmente tutte le tecnologie sulle quali ci si -volesse informare possono essere o sono disponibili per Debian da subito. -Per rispondere in modo costruttivo ai perché di questa questione, è -opportuno inquadrarla nella prospettiva di disponibilità -Open Source. - -<p> -Per chi è <em>veramente</em> interessato, si consiglia di leggere: <url -id="http://lists.debian.org/debian-java/1999/debian-java-199912/msg00015.html"> -e <url -id="http://lists.debian.org/debian-java/1999/debian-java-199910/msg00017.html">. -Questa sezione è un sunto delle informazioni in essi contenute. - - -<sect>È disponibile un compilatore Java1 (da .java a .class)? - - -<p> -Esiste il Kopi Java Compiler, scritto in Java ed il super veloce -Jikes scritto in C++. - -<p> -Gcj può anche compilare i .java in .class. Attualmente la versione CVS -gestisce le classi interne come ogni altro costrutto jdk 1.1, ma potrebbe -non essere in grado di compilare un programma complicato -come l'elaboratore XSL xt. -È scritto in C, quindi è abbastanza veloce; -genera bytecode abbastanza buono e naturalmente l'essere in grado di -utilizzare lo stesso compilatore da .java a .class e da .java a codice -nativo ha i suoi vantaggi. - - -<sect>È disponibile Java1 JVM o JIT? - -<p> -Kaffe 1.0.5 è completo in gran parte ed ora include il supporto per -RMI. Non è chiaro se la serializzazione di Kaffe abbia in tutti i casi la -"compatibilità binaria" con le implementazioni di Sun; per questo -motivo, è possibile che si presentino problemi di interoperabilità. -Kaffe è dotato di una estesa libreria di classi. - -<p> -È disponibile anche Japhar. - -<p> -libgcj (la libreria run-time per gcj) adesso include interprete e -ClassLoader. - -<p>tya, un compilatore JIT, è adesso disponibile. - - -<sect>È disponibile un compilatore nativo Java1? - - -<p> -GCC, la GNU Compiler Collection include GCJ, il compilatore Gnu per Java. - - -<sect1>Compilatore nativo Java2 - - -<p> -Non è chiaro se il compilatore nativo si riferisca alla capacità -adattiva di JIT in Java2 o ad un compilatore che interpreti la -semantica di Java2. In entrambi i casi, la strategia del JIT di Kaffe -non è adattiva ma è correttamente performante e si pensa che, -perfezionandolo, il Jikes compiler di IBM possa interpretare i -concept Java2 così come i riferimenti deboli. - - - -<sect>Debian ha le fondamentali librerie Java2? - - -<p> -Molti di questi componenti sono stati clonati sotto licenze -per software libero. Kaffe fornisce molte di queste routine, -compresa un'implementazione RMI up-to-date. Comunque, ci sono -senza dubbio dei difetti. Swing, per quanto se ne sappia, -non è stato clonato. - - - -<sect>È disponibile un debugger Java (equivalente a jdb)? -<p><package>jswat</package> - - -<p> -Gdb può fare il debug del codice nativo prodotto da Gcj. Stuart Grossman -(Cygnus) ha anche scritto un supporto a Gdb per il debug di altre VM -utilizzando JVMDI. Quest'ultimo non è ancora stato rilasciato, perché -gli internals di Gdb sono stati cambiati contemporaneamente e nessuno ha avuto -la possibilità di reintegrare i cambiamenti. Probabilmente è possibile -che Cygnus rilasci il vecchio codice, nel caso qualcuno fosse -interessato a studiare il modo di farlo funzionare con gli attuali -internals di Gdb (un lavoro di una difficoltà non trascurabile). - -<p> -Si veda <url id="http://sourceware.cygnus.com/java/gdb.html"> su come fare -il debug di programmi Java compilati con gcj. - - - -<sect1>Quali sono gli editor interattivi/grafici, -liberi, disponibili in Debian? - -<p>jde, ddd, altri? - -<p> -Una delle più interessanti caratteristiche di jde è l'autoindentazione e -l'evidenziazione della sintassi, ma supporta anche il -debugging e la compilazione. - - -<sect1>Problemi conosciuti - -<p> -La mia versione di <prgn>jdb</prgn> (versione jdb del 01/06/1998) termina -dopo la fine dell'esecuzione di un programma e devo resettare tutti -i breakpoint se intendo eseguire di nuovo il programma. Ciò rende l'uso -di jdb particolarmente frustrante. Jdb non è in grado di scrivere -(facilmente) i valori in un array che abbia più di tre elementi. -Ddd mi permette di aggirare questi problemi. - -<p> -<prgn>ddd</prgn> 3.1 e precedenti andavano in "sospensione" quando -ricevevano certi inserimenti con strani nomi di thread da jdb. Ciò -rende l'uso di ddd assieme a jdb estremamente difficoltoso. -Questo problema è stato risolto con ddd 3.2. Pare che ddd 3.2 non sia -ancora stato pacchettizzato. Temo che la versione pacchettizzata corrente -di ddd non funzioni con jdb. - - -<sect>È disponibile un tool appletviewer? - -<p> -Ci sono molte possibilità per quanto riguarda i programmi appletviewer: - -<list> -<item>Blackdown appletviewer (in jdk1.1). -<item>Kaffe's appletviewer. -<item>Ibm appletviewer (in ibm-jdk). -</list> - - -<sect>È disponibile un tool Jar? - -<p> -<package>FastJar</package> che è davvero molto veloce. -<package>Kaffe</package> ha anche un tool jar. - - -<sect>È disponibile un tool Javadoc? - -<p> -<package>doc++</package> può funzionare con C++ e Java. -In più, ci sono i pacchetti <package>gjdoc</package> e -<package>gjdoc-native</package>. - - - -<sect>Debian supporta Enterprise Java Beans (EJB)? - -<p> -C'è attività in questo campo: degna di nota più di tutte è -l'implementazione Open Source EJB di Bull, in Francia, che prende -il nome di Jonas. Ho lavorato con questo sistema e posso dire che -fornisce un buon inizio per avere le funzionalità di un EJB completo. -Fornisce, in particolare, un monitor transazionale e -un'implementazione di persistenza basata sul tipo di contenitore. Ho usato -questo sistema su Linux con database liberi come Postgresql. -Non sono in grado di rendere il sistema interamente funzionante -con Kaffe. Inoltre, il sistema dipende da molte API della Sun -che non sono ancora state clonate (JTA, JNDI e EJB stesso). - - - -<sect>Cos'è JAIN? - -<p> -Sembra essere un sistema che controlla infrastrutture di comunicazione -integrate su larga scala, modificando gli eventi con tali reti tramite -le API di JavaBeans. Lo sforzo è grande e unisce il lavoro di molte -organizzazioni. Si tratta di un lavoro nuovo e pare che si colleghi alla -strategia di SCSL di Sun, che mi porta a credere che non ci sia poco di -Open Source in questo campo. Alcuni protocolli come l'H.323, comunque, -sono assolutamente open e anche clonati, così che sia possibile che grosse -parti del sistema JAIN possano esistere in modo sparso. Non si sa nulla di -una seria implementazione con software libero di RTP o delle infrastrutture -H.323 in Java. - - - -<sect>Cos'è Jini? - -<p> -Jini presenta un grosso problema in termini di software libero. Jini è -disponibile in sorgente solo da Sun e questo sorgente è disponibile solo -sotto SCSL, che non è compatibile in nessun modo né con i meccanismi -legali del software libero né tantomeno con il suo spirito politico. -L'SCSL rende anche illegale clonare le API di un'implementazione SCSL -che preclude ad una reimplementazione compatibile di Jini. -Per chi fosse interessato alle implementazioni del tipo spazio di tuple, -esistono opzioni Open Source. - - -<sect>C'è una lista completa di pacchetti? - -<p> -Segue una lista di pacchetti reperibili in Debian 3.0 (aka Woody), che non -specifica quali siano inclusi in contrib o in non-free. - -<!-- Segue una lista di pacchetti (che non evidenzia quelli -residenti nella sezione main) reperibili in Debian 3.0 (ovvero, Woody). --> - -<p> - -<list> - <item>Ambiente Virtual Machines runtime. - <list> - <item><package>jdk1.1</package> (Sun JDK 1.1.8) - <item>IBM JDK 1.1.8 (pacchetto con installer) - <item><package>kaffe</package> - <item><package>kissme</package> - </list> - <item>Tool - <list> - <item>Compilatori - <list> - <item><package>jikes</package> (anche <package>jikes-1.14</package>, <package>jikes-gij</package>, - <package>jikes-kaffe</package>) - <item><package>jdk1.1</package> - <item><package>gcj</package> - <item><package>tya</package> (compilatore JIT) - </list> - <item>Tool per il debugger ed il testing - <list> - <item><package>jswat</package> - <item><package>junit</package> - </list> - <item>IDE ed editor - <list> - <item><package>jedit</package> - <item><package>jde</package> - </item> - <item>Build tools - <list> - <item><package>ant</package> - <item><package>jmk</package> - <item><package>mmake</package> - </list> - <item>Altri - <list> - <item><package>fastjar</package> - <item><package>jad</package> (decompilatore) - </list> - </list> -<item>Ant -</list> -<item>Librerie - <list> - <item><package>lib-dom-java</package> - <item><package>lib-gnu.getopt-java</package> - <item><package>lib-gnu.regexp-java</package> - <item><package>lib-saxon-java</package> - <item><package>libavalon-excalibur-java</package> - <item><package>libavalon-framework-java</package> - <item><package>libbcel-java</package> - <item><package>libbsf-java</package> - <item><package>libcrimson-java</package> - <item><package>libcommons-beanutils-java</package> - <item><package>libcommons-collections-java</package> - <item><package>libcommons-digester-java</package> - <item><package>libjdom-java</package> - <item><package>libjunitperf-java</package> - <item><package>libldap-java</package> - <item><package>liblog4j</package> - <item><package>liblogkit-java</package> - <item><package>libnbio-java</package> - <item><package>liboro-java</package> - <item><package>libpgjava</package> - <item><package>libreadline-java</package> - <item><package>libregexp-java</package> - <item><package>libservlet2.3-java</package> - <item><package>libservlet2.2-java</package> - <item><package>libsoap-java</package> - <item><package>libtomcat4-java</package> - <item><package>libxalan-java</package> - <item><package>libxalan2-java</package> - <item><package>libxerces-java</package> - <item><package>libxerces2-java</package> - <item><package>libxt-java</package> - </list> -</list> - - - -<chapt>Situazione di Java in Debian GNU/Linux Testing/Unstable - -<sect>Ci sono molti cambiamenti? -<p> -Decisamente! Negli ultimi tempi per quanto riguarda java in in Debian -ci sono state interessanti novità; sembra che, lentamente, venga -sviluppata una serie di strumenti volti al mantenimento di pacchetti -Debian contenenti applicazioni e librerie Java. Al momento, pare che -ci sia solo dh_javadoc, contenuto nel pacchetto -<package>gjdoc</package>; tuttavia, nel gruppo di discussione su -debian-java, nel 2003, si è parlato di altri strumenti. - -<p> -Inoltre, sembra esserci anche un incentivo a includere -<package>ant</package> in main, cosa che dovrebbe consentirvi -l'inclusione di altri pacchetti. - -<p> -Il pacchetto <package>eclipse</package> sembra piuttosto stabile; nei -primi giorni dell'agosto 2003, la squadra del gcj è riuscita a -compilare l'IDE in codice nativo, usando solo modificazioni di scarsa -importanza. - -<p> -Consultare, come prima cosa, la sezione su Java in Debian GNU/Linux -Woody è molto utile (dato che i pacchetti di woody sono anche nella -testing), ma ci sono dei cambiamenti, che vengono elencati qui di -seguito: - -<list> - <item><package>eclipse</package> una IDE - <item><package>sablevm</package> una Virtual Machine - <item><package>free-java-sdk</package> Un Java SDK libero - (compilato con strumenti Java compatibili con DSFG) - <item><package>libgnome0-java</package> Binding Java alla libreria - della GUI di Gnome - <item><package>gjdoc</package> Un sostituto di Javadoc 1.3 - (implementa 90% delle Doclet API) -</list> - - -<chapt>Lo sviluppo di Java -<p> - - -<sect>Quali piattaforme di sviluppo complete, per Java, sono - disponibili in Debian? - - -<p> -Se si stanno cercando una java virtual machine integrata, un compilatore -ed un ambiente in runtime, Debian effettivamente li fornisce. Certo, questo -dipende dalla versione Debian GNU/Linux che si usa, generalmente sono -le seguenti: - -<list> -<item>jdk 1.1 Sun (port a cura di Blackdown, si veda in - <ref id="blackdown-pack"> o presso il relativo sito web: - <url id="http://www.blackdown.org">) -<item><prgn>kaffe</prgn>. -<item>jdk di ibm (si veda in <ref id="installer">) -</list> - -<p> -Debian Sid ha il pacchetto <package>free-java-sdk</package> che -fornisce una versione libera del Java Software Development Kit (SDK). -Tutto il software da cui dipende è conforme alle DFSG Debian. - - - -<sect id="free">Quali piattaforme libere ci sono per Debian e come posso -contribuire allo sviluppo? - -<p> -Per chi desidera utilizzare Java su Debian c'è la possibilità -di aiutare nelle implementazioni libere di Java. Ci sono svariati -progetti tra i quali si può scegliere: - -<list> - -<item>kaffe: <url id="http://www.kaffe.org">. -<item>Japhar: <url id="http://www.japhar.org">. La Java virtual -machine di "Hungry Programmer". Altre informazioni in <url -id="http://www.hungry.com/products/japhar">. -<item>gcj e libgcj: <url id="http://sourceware.cygnus.com/java/"> - -<item>jikes: <url id="http://www.research.ibm.com/jikes/">. Un compilatore -veloce scritto in C++ (si controlli anche <url -id="http://www10.software.ibm.com/developerworks/opensource/jikes/">). - Sembra che le nuove licenze sia definitivamente libere -<item>kopi: <url id="http://www.dms.at/kjc/">. Ancora un'altro compilatore -libero per Java, scritto in Java e GPL. Incluso in Kaffe fin dalla versione -1.0.5. -<item>FastJar <url id="http://fastjar.sourceforge.net/">, un tool jar - (questo link sembra non essere corretto, suggerimenti?). -<item>Classpath <url id="http://www.gnu.org/software/classpath/"> o -<url id="http://www.classpath.org">. -Molte delle classi standard per Java 1.2 (fatta eccezione per Swing e RMI) -sono implementate dal ClassPath project, che cerca di creare -un'alternativa all'insieme delle classi di jdk 1.2. -<item>Molte delle classi RMI sono implementate da NinjaRMI -<url id="http://www.cs.berkeley.edu/~mdw/proj/ninja/ninjarmi.html">. -<item>Autoconf macros <url -id="http://www.internatif.org/bortzmeyer/autoconf-Java/"> -è utile per una facile ricompilazione di programmi Java. -<item>Mauve <url -id="http://sourceware.cygnus.com/mauve/"> è una suite libera per testare -se questi tool siano o meno compatibili. - -</list> - -<p> -Gran parte dello sviluppo libero di Java viene svolto da gruppi -che collaborano col <url -id="http://www.gnu.org/software/java/" name="Free Java -Project">. Esiste una mailing list sul Java libero: <url -id="http://www.lists.deus.net/mailman/listinfo/free-java">. - - -<sect id="license-concerns">Domande sulle piattaforme per Debian e tutto -ciò che concerne le licenze - - -<sect1>Java 2 SE (detto anche JDK1.2) -<p> -<sect2>Per quale motivo Java 2 SE di Sun (detto anche jdk 1.2) non è -disponibile? - - -<p> -Ciò avviene a causa di problemi con le licenze. La seconda clausola della -<url id="http://www.sun.com/software/communitysource/java2/license.html" -name="licenza"> (si controllino anche le <url -id="http://www.sun.com/software/communitysource/faq.html" name="FAQ">) -che recita: - -<example> -Il software è segreto e soggetto a copyright. I diritti sul -software e tutti i diritti di proprietà intellettuali sono -detenuti da Sun e/o dai possessori di sue licenze. Ad -eccezione di speciali autorizzazioni contenute in licenze -supplementari è possibile copiare il software in un'unica -copia solo a scopo di archiviazione. -</example> - - -<sect2 id="scsl">Quali sono i problemi con la nuova licenza della Sun? - -<p> -Sun si è spostata su un nuovo tipo di licenza, la -<em>Sun Community License</em>, che come la GPL è una licenza virale, ma -prende in considerazione anche argomenti come il pagamento delle licenze -della Sun. La SCSL arriva al punto di definire qualsiasi implementazione -di una specifica Sun come "opera modificata". Ciò significa, in sostanza, -che chi implementa una qualsiasi parte della nuova API 1.2 o una API Jini, -anche da zero, la Sun sarà "proprietaria" di tale implementazione e -anche chi ha realizzato tale implementazione dovrà pagare per avere -diritto di usufruirne. - -<example> -13. "Modifica(che)" significa (i) qualsiasi cambiamento al - codice protetto; (ii) qualsiasi nuovo file o altra - rappresentazione di un'istruzione di un programma per - computer che contenga una parte qualunque del codice - protetto; e/o (iii) qualsiasi nuovo codice sorgente - che implementi una qualsiasi parte delle specifiche. -</example> - - -<sect2> Cosa è la SCSL? - -<p> -SCSL è la "Sun Community Software License" che si può trovare all'URL -<url id="http://java.sun.com/communitysource/">. Non è compatibile con -il software libero per svariate ragioni ed accettando tale licenza (per es. -scaricando codice sorgente coperto da SCSL) diviene impossibile -contribuire al software libero neanche con reimplementazioni che -partano da zero. -Secondo la Sun, questo comprende anche l'uso della documentazione e delle -specifiche API disponibili solo sotto SCSL. - - -<p> -Per citare uno sviluppatore Open Source, la SCSL è "pressappoco libera -quanto la passata Unione Sovietica". - -<p> -Ad ogni modo, senza sottostare alla SCSL, è ancora ammissibile, -escludendo qualunque brevetto di Sun per la tecnologia, creare una -propria reimplementazione della versione 1.2 dell'API. È -importante non accettare mai tale licenza, neanche per la -documentazione. Per esempio, nel caso si compri un libro stampato -che descriva l'API, esiste un lungo precedente legale (per lo meno, -negli Stati Uniti), che proibisce di allegare questo genere di -contratti ai libri. - - -<sect2>È possibile usare jdk1.2 lavorando con le implementazioni -libere di Java? - -<p> -La Clausola numero 1 delle Supplemental License Terms recita: - -<example> - Non si possono creare o autorizzare i concessionari di licen_ - za a creare classi addizionali, interfacce, o sotto pacchetti - che siano contenuti nei pacchetti "java", "Sun" o simili, - come specificato da Sun, in ogni convenzione che dà il nome - ai file delle classi; -</example> - -<p> -Questo, pare eviti che chiunque faccia implementazioni proprie -degli standard delle classi Java utilizzando le JDK. - -<p> -Non è chiaro, comunque, se la parola "addizionale" includa o meno le -reimplementazioni di classi esistenti o se si applichi solo alle -classi che portano nuovi nomi. - - - -<sect2>Perché (alcuni) software liberi non implementano Java2? - -<p> -Sun ha dichiarato pubblicamente, in riferimento alla propria strategia per -l'azione legale Sun-Microsoft, che la compagnia considera le specifiche -pubblicate di Java2 come una proprietà intellettuale che non può essere -legalmente usata da persone coinvolte in tentativi di creare -reimplementazioni di Java2. Per questo motivo alcuni progetti Open Source -hanno deciso di non implementare Java2, per il momento. Un esempio è Kaffe. -Alcuni progetti (come il Japhar/Classpath project) hanno deciso di -sfidare la posizione legale di Sun procedendo con l'implementazione di Java2. - - -<sect1 id="ibm-jdk1.1">La jdk1.1 di IBM -<P> -<sect2>Debian può distribuire la jdk1.1 di IBM? -<p> -Pare di no. Di seguito la licenza: - -<example> -Program Code - -Consiste nella IBM Developer Kit per Linux(R), Java(tm) -Technology Edition, versione 1.1.8, in forma di codice -binario, così come modificato da IBM per funzionare sui -sistemi operativi RedHat(R), 6.0 Linux o Caldera(R) -OpenLinux 2.2. Il Program Code consiste nella Java -virtual machine, nelle Java platform core classes e nei -file di supporto (detti anche Java Runtime Environment -o JRE), nel Java ToolKit, nella documentazione e i Java -Samples. Program Code può comprendere documentazione -soft copy, file readme, program data e simili. - -È possibile utilizzare il Program Code solo se si è -in possesso di una licenza dei sistemi operativi Linux -Redhat 6.0 o Caldera OpenLinux 2.2 e il Program Code è -utilizzabile solo insieme a questi prodotti. -</example> -<p> -Si veda il bug #54641 per un problema circa il JDK IBM. È possibile -scaricarlo da <url id="http://www.ibm.com/java/jdk/118/linux">. - - -<sect2>C'è la possibilità di ottenere una licenza per Debian 2.1? - - -<p> -Non sarebbe libera, per il punto 8 della DFSG: "Le licenze non possono -essere specifiche per Debian". - - -<sect1>JRE -<p> -<sect2>Debian può distribuire JRE? - -<p> -(da Gene McCulley: <url -id="http://lists.debian.org/debian-java/1999/debian-java-199908/msg00021.html">). -Non penso che si possa voler distribuire il JRE con Debian. I termini -supplementari della licenza del JRE hanno alcune clausole piuttosto -antipatiche: - -<example> - 1.Licenza per la distribuzione. Viene concesso il diritto - di riprodurre e distribuire, libero da royalty, il - software fornito che venga: (i) distribuito come - software completo e non modificato, solo come parte di - e all'unico scopo di far funzionare una propria applet - Java o un'applicazione ("programma") in cui il software - sia incluso; -</example> - -<p> -Si potrebbe passarla liscia con questa clausola, dal momento che lo -distribuiamo insieme alle applicazioni Java che fanno parte di Debian. -Ma occorre anche consentire a chiunque di scaricare il solo il pacchetto jre. - -<example> - (ii) non distribuire software aggiuntivo inteso come - sostituto di qualunque componente del software; -</example> - -<p> -Non è possibile acconsentire su questo punto. L'intenzione è di distribuire -Kaffe, Japhar, Classpath, Gcj, Kopi, Fastjar, ecc. che intendono sostituire -il JRE con una sua versione libera. Anche se non si considerasse -una parte non libera di Debian (il JRE non andrebbe nella principale :)), -ritengo che non si dovrebbe incoraggiare il software che cerca di -prevenire sostituzioni libere. - -<example> - [...](v) non si possono creare, o autorizzare i concessionari - di licenza a creare classi addizionali, interfacce, o - sottopacchetti che siano contenuti nei pacchetti "java", "Sun" - o simili, come specificato da Sun in ogni convenzione che dà - il nome ai file delle classi; -</example> - -<p> -L'esempio riportato precedentemente, sul motivo per cui questa sia -una cattiva clausola non era così centrato, dal momento che -qualcuno ha notato che non si vuole creare qualcosa che non sia -standard. Concordo col fatto che si desideri un'implementazione -standard del nucleo delle classi, ma ritengo anche che si -dovrebbe essere liberi di creare classi non standard (oppure -fissare bug e stupidi errori nelle classi standard). - -<example> - [...] e (vii) acconsentire a risarcire, a rendere inoffensivi - e difendere Sun e chi rilascia le licenze, da qualsiasi - rivendicazione o azione legale, comprese le spese legali, che - derivano o sono il risultato dell'uso o della distribuzione - del programma. -</example> - - -<p>Non credo che Debian (o SPI) possa o voglia far questo. -<p> - -<p> -Sono perciò dispiaciuto del fatto che non si possa distribuire il JRE -di Sun o di Blackdown; ciò non è negativo, dal momento che si tratta di -software non libero, ma è seccante. Come già detto prima, è necessario -aiutare uno dei (tanti) progetti di Java liberi se si desidera vedere -una JVM libera, delle classi standard, un compilatore ecc. in Debian. -Sono lungi dall'essere completi, ma funzionano per la maggior parte degli -scopi. - -<sect1>GPL or LGPL? -<p> -Java usa un linking dinamico al runtime. Usando una reflection API ed un -caricatore di classi, il linking può essere guidato completamente dai dati, -specificando classi e metodi tramite i nomi. Ciò crea problemi legali -nell'uso del codice Java sotto GPL in possesso dell'utente, come una -violazione della GPL non può essere dimostrata dall'eseguibile stesso. A -differenza dei plugin, le classi Java non devono avere una struttura -specifica per essere usate in questo modo. Usando metodi nativi e -selezionando le DLL al runtime, questo problema può essere riscontrato -anche nel codice nativo. - -<P> -Esempio: un checker di dipendenza Java sotto GPL che usa una reflection API. -Il collegamento al runtime di Java, in particolare la reflection API, rende -illeggibili le istruzioni tra codice e dati anche più dei plugin nativi -esemplificati. - -<p> -Chi desidera scrivere codice Java che possa essere usato senza che l'utente -debba preoccuparsi di problemi relativi alle licenze, può prendere in -considerazione la Lesser GPL (LPGL). Questo per evitare di vedere le -proprie classi ed i propri pacchetti utilizzati come software non libero. - - -<sect>Come si crea un programma Java, con interfaccia grafica, compatibile - con DFSG? - -<p> -Molti programmi Java usano la libreria Swing per lo sviluppo di interfacce -grafiche; per questo c'è <package>libswing-java</package>. -La maggior parte dei programmi si compilano tramite questa libreria, -ma ciò non ne garantisce il funzionamento. -Non sempre sono eseguite, o eseguite bene, tutte le classi. - -<p> -Lo Standard Widget Toolkit (SWT, <package>libswt-java</package>), -basato sulla libreria GTK+, è un'alternativa alla libreria Swing. - -<p> -Una terza possibilità è costituita da funzionalità ad interfaccia grafica di -KDE o GNOME. Per KDE, c'è il pacchetto kdebindings tar.gz (ci sarà anche -un deb?), per GNOME il <package>libgnome0-java</package>. - -<sect1>I programmi basati su swing funzionano in Debian? - -<p> -Swing funziona e può essere installato, da notare che le JVM 1.2 e 1.3 -includono swing; altrimenti è necessario scaricarlo per la propria -particolare JVM. Si veda oltre, in <ref id="swing-run">, per scoprire -come farlo funzionare. - - -<sect>Creare pacchetti Debian per programmi Java. -<p> - -<sect1>È possibile inserire il pacchetto in main? - -<p> -Sì, <em>ma solo qualora</em> possa essere creato ed eseguito principalmente con -programmi/tool Java presenti in main ed abbia una licenza Open Source -compatibile con Debian. Se necessita di programmi provenienti dalle sezioni -contrib o non-free, allora <em>deve</em> essere collocato in esse, a seconda -della propria licenza. - -<p> -Più specificatamente, se il programma può essere creato ed eseguito con -<package>free-java-sdk</package>, allora dipende solo da pacchetti -provenienti da main. La descrizione di <package>free-java-sdk</package> -specifica: -"Si installi questo pacchetto, impostando JAVA_HOME in /usr/lib/fjsdk e -cercando di ricreare i propri pacchetti Java: se funziona, i pacchetti -possono essere spostati dalla sezione contrib alla main". - - -<sect1>Quali pacchetti virtuali si potrebbero usare? -<p> -<list> -<item><package>java-common</package>. È la madre di tutti i -pacchetti Java, nella politica proposta. Contiene la Policy (Docbook), -così come gli script di utility, per esempio per costruire una -CLASSPATH da una lista di jar (sono gradite proposte). -<item><package>java-virtual-machine</package> -<item><package>java-compiler</package> -<item><package>java-compiler-dummy</package>. È un piccolo -tool utile per la transizione verso la nuova Policy, finché tutti -i compilatori non vi si conformeranno. Il java-compiler-dummy -offre i seguenti servizi: - -<list> - -<item>fornisce il java-compiler, in modo tale che pacchetti - superiori non abbiano problemi; -<item>imposta CLASSPATH prima di chiamare la vera VM. - -</list> -<item><package>java-virtual-machine-dummy</package>. È un piccolo -tool utile per la transizione verso la nuova Policy, finché tutte le -virtual machine non vi si conformeranno. Il java-virtual-machine-dummy -offre i seguenti servizi: - -<list> -<item>fornisce la java-virtual-machine, in modo tale che pacchetti - superiori non abbiano problemi; -<item>imposta CLASSPATH prima di chiamare la vera VM. -</list> - -</list> - -<sect1>C'è un buon esempio di pacchetto Debian? - -<p>Ci sono molti pacchetti Debian, sia di applicazioni, sia di -librerie Java, che possono servire da buon punto di partenza, come -esempio per farne dei nuovi. - -<p>A tal proposito, si controlli sul progetto pkg-java -(pkg.java-project), presso il sito della Alioth: -<url id="http://pkg-java.alioth.debian.org/">. - -<p>Si noti che ci sono molti modi per realizzare un pacchetto debian, non -importa se tramite Ant o Makefile. Alcuni suggerimenti, utili per -impratichirsi, sono riportati sul sito di pkg-java: -<url id="http://pkg-java.alioth.debian.org/developers.html#rules"> e -<url id="http://pkg-java.alioth.debian.org/building.html">. - - -<sect1>Ci sono strumenti per facilitare il mantenimento di pacchetti Java? - -<p>Attualmente, solo dh_javadoc, presente nella distribuzione unstable -di Debian, nel pacchetto <package>gjdoc</package>. - - - -<chapt>Compilatori Java -<p> - - -<sect>Quali compilatori Java sono disponibili per Debian? -<p> - -<list> - -<item> -<package>guavac</package>, il compilatore della Effective Edge Technologies. -Questo compilatore è privo di upstream; per un corretto funzionamento si può -usare gcj o jikes. -<item><package>tya</package>, un compilatore just-in-time, usato per -compilare codice Java in byte code. -<item><package>jikes</package>, che viene descritto funzionare bene con -tutte le JDK (dalla 1.1 alla 1.3); si suggerisce di usare -E quando -si compila con <prgn>Emacs</prgn>. -<item><package>bock</package>. Compilatore da Java a C. -<item><package>gcj</package>. Compila sorgenti Java in codice nativo, -codice sorgente in bytecode, o bytecode in codice nativo. -<item><package>gck</package>. È disponibile? -<item><prgn>kjc</prgn> è incluso in <prgn>kaffe</prgn> 1.0.5. -Attualmente non ci sono pacchetti separati. - -</list> - - - - -<chapt>Java Virtual Machines (JVM) -<p> - - - -<sect>Quali JVM funzionano in Debian? - -<p> -Attualmente, la JVM di Blackdown, quella di Sun e di Ibm funzionano con -Debian. Per programmi semplici come quelli usati per l'insegnamento, la -VM libera di kaffe può essere sufficiente. Un'altra soluzione è -usare gcj e compilare in codice nativo, per risolvere il problema delle VM. - -<p> -Tutte queste possono essere scompattate in /usr/local con link in -/usr/local/bin: in questo modo funzionano in qualsiasi configurazione -e versione di Debian, il solo problema potrebbe essere la presenza -o meno di versioni delle glibc basate sulle libc5 (le versioni più -vecchie di Debian non avevano il supporto alle glibc finché non è -stato incluso in Debian 2.1, nome in codice slink). - - -<sect>Quali JVM libere sono disponibili per Debian? -<p> - -<list> - -<item><package>kaffe</package>. Non fa funzionare tutti i programmi, -anche se si presume che funzioni con Jigsaw (una distribuzione da 10Mb), -si veda in <url -id="http://lists.debian.org/debian-java/1999/debian-java-199911/msg00038.html">. - -<item><package>sablevm</package>. -</list> - - -<sect>Che tipo di API forniscono queste JVM? - -<p> -È da notare che fornire un API non significa che tutto sia completato, -tanto meno che lo sia in modo corretto; perfino nell'SDK della Sun, nessuno -dei quattro difetti confermati è stato corretto. Quindi non è da disprezzare -l'implementazione libera perché presenta difetti o è realizzata solo in parte. - -<p>Molte API sono messe a confronto per GNU Classpath, GNU gcj, -Kaffe e Wonka con -<url name="japitools" id="http://rainbow.netreach.net/~sballard/japi/">. - - -<sect>In che misura le API sono implementate dalle JVM? - -<p>Si dà qui un riassunto dei risultati delle prove - - -<sect>Ci sono problemi noti? - -<p> -Sì, alcuni, segnalati come difetti relativi a Debian, si possono consultare -sul <url id="http://www.debian.org/Bugs/" name="Debian Bug Track System">, -sistema Debian di ricerca dei bug. -Ecco alcuni pacchetti, come collegamento veloce: - -<list> - -<item><url id="http://bugs.debian.org/kaffe" name="kaffe"> -<item><url id="http://bugs.debian.org/gcj" name="gcj"> -<item><url id="http://bugs.debian.org/sablevm" name="sablevm"> - -</list> - -<p> -Come di norma nell'ambito del progetto Debian, gli sviluppatori apprezzano -relazioni (bug reports) circostanziate sui problemi riscontrati. Questo -include la descrizione del problema, il comando che lo provoca, gli errori -causati dall'esecuzione del comando ed ogni altra informazione rilevante. Uno -strumento appropriato per segnalare i difetti è <package>reportbug</package>. - - -<sect>In Debian, per eseguire un programma java è davvero necessaria una JVM? -<p> -No, si può provare ad eseguire le applicazioni senza una jvm, basta -compilare il codice sorgente in codice nativo. - - - -<sect1>Come compilo il codice nativo? - -<p> -Si dovrebbe essere in grado di usare <prgn>gcj</prgn> o <prgn>jikes</prgn> -(che sono entrambi programmi liberi), per compilare il programma e -usare <prgn>gcj</prgn> per convertire bytecode in codice nativo. -L'intera catena di software è libera. - - - -<sect1>Si tratta di un approccio riuscito? - -<p>Senz'altro, si veda in<url -id="http://lists.debian.org/debian-java/1999/debian-java-199911/msg00044.html"> -come è stato fatto per il parser XML <prgn>xp</prgn>. -<example> -ezili:~/infosystems/XML/Java> gcj --main=UnTag UnTag.java UnTagHandler.java -/usr/share/java/repository/org/xml/sax/helpers/*.class -/usr/share/java/repository/org/xml/sax/*.class /usr/share/java/repository/com/j -clark/xml/sax/*.class /usr/share/java/repository/com/jclark/xml/parse/*.class -/usr/share/java/repository/com/jclark/xml/tok/*.class -/usr/share/java/repository/com/jclark/util/*.class -/usr/share/java/repository/com/jclark/xml/parse/base/*.class -</example> - -<sect1>Ci sono stati problemi con tale approccio? - -<p> -Sì, ci sono stati anche alcuni problemi. - -<p> -<prgn>gcj</prgn> non supporta completamente JNI. Tom Tromey è il -responsabile per l'implementazione di JNI. Nell'aprile del 2000 -mancava ancora un aspetto (non si può, attualmente, compilare un -file .class che usa funzioni JNI per implementare i suoi metodi -nativi), ma Tom ci sta lavorando e spera di completarlo "presto". - -<p> -Il fatto che manchi JNI incide sull'uso di Classpath (per es. come -alternativa a libgcj) così come una piccola applicazione standalone -che sostituisca AWT con qualche GUI veramente semplice (come l'uso di -curses, per es. per piccoli installer). Incide anche sui progetti che -hanno codice nativo per motivi di performance. Al momento, gcj forza -in sostanza una porta CNI. L'unica alternativa di cui siamo certi è -TowerJ, che può andare bene per progetti commerciali, ma non offre -nulla al software libero. - - -<sect1>Funziona con architetture diverse dall'i386? - -<p>È possibile di no, dal momento che libgcj non funziona su sparc -e nessuno ci ha provato. - - - -<chapt>Plugin Java per browser - -<p>La prossima sezione descrive come utilizzare Java all'interno dei -browser, per eseguire le <tt>applet</tt> pubblicate nei web server. - -<sect>Si può usare qualsiasi JVM come plugin Java? - -<p> -Questa è una domanda problematica. La mia risposta è: "In genere no, -ma tentar non nuoce" (non si tralasci di inoltrare le proprie scoperte, -per consentire l'aggiornamento di questo scritto). - - -<sect>Si può usare Java in Konqueror? - -<p> -In Konqueror 3.1.1, sì, dal menu Preferenze->Navigazione -web->browser Konqueror: il Modulo di Controllo, reso open, -ha un sezione Java&JavaScript in cui scrivere la -collocazione della propria JVM. -La configurazione dovrebbe somigliare a: - -<list> - <item>"Abilita java globalmente" - Selezionato - <item>"Mostra la console Java" - Selezionato - <item>"Percorso dell'eseguibile Java" indicante /usr/bin/java -</list> - -<p> -Dicendo <file>/usr/bin/java</file> ci si affida al meccanismo -dell'<prgn>update-alternatives</prgn> per puntare ad una -JVM che funzioni da plugin. Se si è installato J2RE, il -"percorso di Java" potrebbe anche essere -<file>/usr/local/j2sdk1.4.1/jre/bin/java</file>. - - -<sect>Si può usare java in Netscape 6.x/7.x? - -<p> -Sì: basta creare un link simbolico verso il plugin per Java -nella <file>/path/to/netscape/plugins</file>, come si evince nel -J2RE della Sun: -<example> -/usr/local/netscape/plugins $ ls -la -total 960 -drwxr-sr-x 2 root staff 4096 Apr 30 09:46 . -drwxr-sr-x 9 root staff 4096 Apr 8 20:26 .. --rw-r--r-- 1 root staff 2363 Feb 8 07:47 ShockwaveFlash.class --rw-r--r-- 1 root staff 946108 Feb 8 07:47 libflashplayer.so -lrwxrwxrwx 1 root staff 64 Apr 30 09:46 libjavaplugin_oji.so -> /usr/local/j2sdk1.4.1/jre/plugin/i386/ns610/libjavaplugin_oji.so --rwxr-xr-x 1 root staff 19396 Feb 8 07:47 libnullplugin.so -</example> - -<p> -Se si è installato J2RE di Blackdown, il link simbolico deve essere -creato verso -<file>/usr/lib/j2se/1.4/jre/plugin/i386/mozilla/javaplugin_oji.so</file>. - -<sect>Si può utilizzare Java in Mozilla 1.x? - -<p>Sì, seguendo un procedimento identico a quello adottato per Netscape -- la cartella dei plugin, però, in questo caso sarà -<file>usr/lib/mozilla/plugins</file>. - - - -<chapt>Servlet Java -<p> -<sect>Come far funzionare le servlet Java? -<p>Si può usare: -<list> - <item><package>gnujsp</package> - <item>Apache <package>jserv</package>. <url id="http://java.apache.org/jserv/index.html">. - <item>Apache <package>tomcat</package> da - <url id="://jakarta.apache.org/tomcat/">. -</list> -Altri non pacchettizzati per Debian, ma che presto saranno inclusi, sono: - -<list> - -<item>jigsaw da <url id="http://www.w3.org/Jigsaw/">. -<item>Jetty <url id="http://mortbay.com/software/Jetty.html"> (testato -con successo su una macchina con un sistema Debian Potato) - -</list> - - -<sect>Le servlet funzionano con kaffe? -<p> -La <file>servlet.jar</file> in Kaffe non funziona. È solo una shell. -Esiste un'altra implementazione LGPL scritta da Paul e Mark Wielaard. -Disponibile in <url id="http://www.euronet.nl/~pauls/java/servlet"> -dovrà essere (lo è stato?) aggiunto il pacchetto Apache JServ in modo -tale che l'utente non debba scaricare nuovamente le classi Sun. - - -<sect>È necessaria una versione di Java non libera per far funzionare -le servlet? - -<P>Nessuna conosciuta. Possibilmente, no, ma è necessaria una spiegazione. - - - - -<chapt>Le politiche di Java -<p> -<sect>È disponibile una politica Java per Debian? - -<p> -È ancora in fase di elaborazione. L'attuale linea di condotta si -rivolge solo ad <em>alcuni</em> problemi e non è stata rilasciata -ufficialmente: è reperibile all'indirizzo -<url id="http://www.debian.org/doc/packaging-manuals/java-policy/"> ed -anche nel pacchetto <package>java-common</package>. - - - -<sect>Ci sono delle imperfezioni nella politica di Java? - -<p> -Sì, su alcuni punti la discussione è aperta. Per favore, si veda in -<url id="http://bugs.debian.org/java-common" name="bugs against the -java-common package">. Così è <em>veramente</em> sconveniente -usare diversi compilatori di virtual machine -prima che sia impostata la CLASSPATH per ognuno di essi. - - - - -<chapt>Altre alternative Java per Debian -<p> -Se i pacchetti Java forniti in Debian non fossero sufficienti alle nostre -esigenze, si potrebbe aver bisogno di cercare delle alternative. -Occorre comprendere che queste alternative non sono supportate dal -progetto Debian direttamente, ma è possibile trovare supporto dalla -mailing list debian-java in caso ci fossero problemi. - -<p> -Alcune di queste alternative utilizzano pacchetti Debian, cosa che non crea -problemi, dal momento che l'utente o l'amministratore non devono -preoccuparsi per problemi nell'installazione. Ad ogni modo, mischiare -pacchetti che provengono da sorgenti che non sono del progetto Debian -potrebbe, a volte, causare conflitti con l'installazione. Naturalmente, -Debian cerca di integrare più software libero possibile, in modo che -alcune delle alternative descritte qui sotto possano (licenza permettendo) -essere incluse in Debian in un prossimo futuro. - - - -<sect id="blackdown-pack">Come procurarsi pacchetti da BlackDown - -<p> -Se la release fornita non è sufficientemente recente, è -possibile installare i file scaricati dai mirror di Blackdown. -È possibile anche usare i pacchetti Debian forniti da -Blackdown o scaricare i file tar. - -<p> -(contributo di Federico Mennite) Se si desidera utilizzare i loro pacchetti, -occorre aggiungere la seguente riga - -<footnote> -È necessario usarne una sola, potrebbe essere per -<em>potato</em> o <em>woody</em>, in base alla versione di Debian -in uso, o potrebbe anche essere <em>testing</em> o <em>unstable</em> -se si tratta di una release in sviluppo. -</footnote> - -in <file>/etc/apt/sources.list</file>: - -<example> -deb proto://url/debian potato main non-free -deb proto://url/debian woody main non-free -deb proto://url/debian testing main non-free -deb proto://url/debian unstable main non-free -</example> - -<p> -Dove <em>proto://url</em> è uno dei mirror disponibili dalla lista -in <url id="http://www.blackdown.org/java-linux/mirrors.html">. - -<footnote> -È necessario l'archivio <em>main</em>, dal momento -che ora lì c'è un pacchetto <package>j2se-common</package>. -Se sono già state installate le j2sdk quando non esistevano -le dipendenze di cui sopra, si otterranno dei warning -quando vengono eseguiti i comandi <prgn>apt-get update</prgn> -o <prgn>apt-get upgrade</prgn>. -</footnote> - -Ad esempio, in Debian 3.0, che usa il mirror di Metalab si usa: - -<example> -deb ftp://metalab.unc.edu/pub/linux/devel/lang/java/blackdown.org/debian woody main non-free -</example> - -<p>Poi: - -<example> -$ apt-get update -$ apt-get install j2sdk1.3 -</example> - -<P>Si noti che, al momento della stesura di questo scritto, ci -sono pacchetti di Blackdown, in fase beta, solo per la versione -<em>unstable</em> di Java 1.4. - - -<p> -(contributo di Paul Reavis) Scaricare e installare le JDK dai -file tar.gz, scompattarli in <file>/usr/local/jdk1.1.x</file> e -usare dei link simbolici per creare <file>/usr/local/jdk</file> ed i -link ai binari in <file>/usr/local/bin</file> o equivalenti. -Non è affatto difficile fare tale installazione. Ad ogni modo, -si possono avere dei segfault in alcuni casi, a seconda delle -librerie che si hanno. - -<p> -Ecco una lista dei rilasci che certamente funzionano con ciascuna -versione di Debian e di tutto il software necessario perché -funzionino, se esiste. - -<list> -<item>rex/bo: 1.1.5v7 (libc5). -<item>hamm:1.1.5v7 (glibc), ha bisogno dell'ultima glibc di slink. -<item>slink: 1.1.6-test2 (glibc). -</list> - - -<sect1 id="swing-run">Far funzionare swing in Debian - - -<p> -(da Paul Reavis) [Una cosa fatta in fretta per far sì che -Swing funzioni davvero sotto Debian o qualsiasi altro Linux] - -<p> -Sì, funziona con le JDK Linux; Swing è al 100% Pure Java (tm)(c)(SFD) -e per questo dovrebbe andare con qualsiasi JVM compatibile. -Reavis lo ha ottenuto convertendo un'applicazione commerciale -(350 e più classi) in un'interfaccia grafica totalmente Swing. -Io non ho avuto alcun problema. - -<p> -Chi usa la jdk 1.1.3 o inferiori, ha solo bisogno dei file class. -Perciò la cosa più semplice da fare è prendere la distribuzione -solaris in formato tar.Z da javasoft. In base alla fase lunare, viene -chiamato swing o JFC 1.1 (per distinguerlo dall'1.2, che è parte di -Java 1.2). La versione attuale è Swing 1.2 (da non confondersi con -Java 1.0.2!). Se si usa jdk 1.2.2 non si deve scaricare Swing (è -già integrato nella jdk). - -<p> -Non ho l'archivio sotto mano, così lo chiameremo -swing.tar.Z. Si consiglia di installarlo in /usr/local così: - -<example> - skronk# cd /usr/local - skronk# tar xzf /tmp/swing.tar.Z -</example> - -<p> -Ora è necessario avere una directory /usr/local/swing. Per fare un test, -assicurarsi che la propria variabile JAVA_HOME sia impostata, che -CLASSPATH invece non lo sia e far andare lo script "runnit" in ciascun -esempio. Giusto per essere terribilmente ovvi, si agisca in questo modo: - -<example> - skronk$ cd /usr/local/swing/examples/SwingSet - skronk$ echo $JAVA_HOME - /usr/local/jdk - skronk$ unset CLASSPATH - skronk$ echo $CLASSPATH - - skronk$ ./runnit -</example> - -<p> -Naturalmente le directory, il prompt della shell e le esperienze fatte -potranno differire. -Per utilizzare le proprie applicazioni, basta aggiungere gli jar che -servono al proprio classpath. - - - -<sect1>Far funzionare Java 2 in Debian - -<p> -Se si desidera usare la jdk 1.2 di Sun o di Blackdown in Debian, occorre -scaricare i pacchetti forniti da Blackdown (disponibili in directory -usabili da <prgn>apt</prgn>) dai diversi mirror disponibili qui: -<url id="http://www.blackdown.org/java-linux/mirrors.html"> -(si controllino le subdirectory debian). -Attualmente ci sono pacchetti i386 per le Java SDK e RE, JAI, Java3D e -JMF. È raccomandato seguire questo metodo, per ulteriori -informazioni si veda in <ref id="blackdown-pack">. - -<P><em>O</em>, se si desidera fare da soli e scaricarsi gli -archivi (quindi tar.gz e non pacchetti .deb), si può anche seguire -quest'altra strada: - -<list> -<item>Creare una directory in <file>/usr/local</file> - (per esempio <file>/usr/local/sun</file>). -<item> Scaricare l'archivio in questa directory e scompattarlo. Verrà - creata una directory jdk1.X - <footnote><em>X</em> dipenderà dalla versione del Java 2 - state trasferendo, potrà essere 1.2.1, 1.2.2, 1.3 o - persino 1.4</footnote>. -<item> Sistemare le alternative perché funzioni correttamente: -<example> - update-alternatives --install /usr/bin/javac javac /usr/local/sun/jdk1.2.2/bin/javac 120 - update-alternatives --install /usr/bin/java java /usr/local/sun/jdk1.2.2/bin/java 120 -</example> -<item> Controllare le proprie alternative con "type" -<example> - type javac - type java -</example> -</list> - -A questo punto si dovrebbe avere un ambiente jdk 1.X perfettamente -funzionante, inclusi una virtual machine ed un compilatore. - -<p>Potrebbe essere necessario cambiare il proprio - <file>/etc/profile</file> aggiungendovi le variabili d'ambiente - (<tt>CLASSPATH</tt>, <tt>JAVA_COMPILER</tt> and <tt>JAVA_HOME</tt>) - che i programmi Java cercheranno nell'installazione. Il seguente - esempio mostra come impostare le cose nel caso aveste il jdk - 1.2.2 della Sun: - -<example> -# JDK 1.2.2 (.tar) -export CLASSPATH=.:/usr/local/sun/jdk1.2.2/lib:/usr/local/sun/jdk1.2.2/jre/lib -export JAVA_COMPILER=javacomp -export JAVA_HOME=/usr/local/sun/jdk1.2.2 -export PATH=$PATH:/usr/local/sun/jdk1.2.2/bin -</example> - -<p> -Nota: Come Juergen Kreileder mi ha correttamente fatto notare, il nome -preferenziale per versioni >= 1.2 è Java 2 SE (Standard Edition). -La jdk1.3 ora si chiama "Java2 SDK v1.3" o "J2SDK 1.3". -La jre1.3 ora si chiama "Java2 RE v1.3" o "J2RE 1.3". - - - - - -<sect>Come integrare J2SE SDK con Debian Testing? - -<p> -Ce lo spiega Warren Dodge: anzitutto, scaricare i componenti di J2SE -SDK da <url id="http://java.sun.com/j2se/downloads.html"> in -<file>/var/install/java/1.4.1</file>, per esempio, assicurarsi di -avere il permesso di scrittura sulla cartella e rendere eseguibile -il programma d'installazione <prgn>./j2sdk-1_4_1_02-linux-i586.bin</prgn>; -la sua esecuzione creerà la cartella <file>j2sdk1_4_1_02</file>, che -può essere spostata in <file>/usr/local/lib</file>. Quindi, creare un -link simbolico -<tt>ln -s /usr/local/lib/j2sdk1_4_1_02 /usr/local/lib/jdk</tt>, che -permette di utilizzare la collocazione più recente nel riferimento -all'ambiente Java e rende molto più semplice un futuro aggiornamento. - -<p>Siccome Debian non ha un programma d'installazione di pacchetti -per J2SE della Sun, occorre creare un pacchetto fittizio che informi -Debian dell'avvenuta installazione di J2SE medesimo, in questo modo; -per soddisfare le dipendenze, si dovranno usare i file di controllo del -pacchetto fittizio forniti da <package>java-common</package>: - -<tt> -cd /var/install/java -mkdir pkg -cp /usr/share/doc/java-common/dummy-packages/*.control /var/install/java/pkg -equivs-build java-compiler-dummy.control -equivs-build java-virtual-machine-dummy.control -equivs-build java1-runtime-dummy.control -equivs-build java2-compiler-dummy.control -equivs-build java2-runtime-dummy.control -</tt> - -Ora, in <file>/var/install/java/pkg</file> dovrebbero esserci cinque -pacchetti installati. - -<p> -Per scegliere il pacchetto da usare, fra molti che possano svolgere -la stessa funzione, in Debian si usa il comando -<prgn>update-alternatives</prgn> ("Java" è fornito anche da kaffe, -Blackdown [cfr. sopra], ecc.); per maggiori dettagli, si veda -"man update-alternatives". Per installare i programmi desiderati, -si usi tale comando con questi ordini: -<tt> -update-alternatives --verbose --install /usr/bin/java java /usr/local/lib/jdk/bin/java 500 \ - --slave /usr/share/man/man1/java.1 java.1 /usr/local/lib/jdk/man/man1/java.1 -</tt> - -<p> -Per consentire la creazione di cartelle per le preferenze di sistema -e per verificare il corretto funzionamento di <prgn>java</prgn> della -Sun, lo si esegua una volta da root: -<tt> - java -version -</tt> - - - -<sect>Come integrare J2SE SDK della Sun con Debian Stable? -<p> -Con la stessa procedura descritta per Debian Testing (cfr. sopra); -tuttavia, il pacchetto java-common della versione stable non ha -i file *.control, perciò occorre installare quello di testing o -di unstable. Le versioni 0.19 e 0.20 possono essere installate -tranquillamente e richiedono l'installazione del pacchetto -equivs, anche la versione di stable, comunque, va benissimo. - - - - -<sect>Altri programmi Java che non sono ancora disponibili per Debian - -<p> -I programmi che non sono ancora stati pacchettizzati per Debian o che non -hanno ancora un installer sono i seguenti. Ci sono molti programmi Java -e questa lista non può dirsi esaustiva, in quanto include solo programmi -che <em>potrebbero</em> essere pacchettizzati per Debian o quelli per i -quali qualcuno sta preparando un installer: - -<list> - -<item>BlueJ. Un ambiente di sviluppo per Java con un editor, un compilatore, - una virtual machine ed un debugger. Si veda in - <url id="http://bluej.monash.edu.au/"> -<item>Jacob (Java Commando Base): project maintainer e visualiser - per Java in Emacs. Si veda in - <url id="http://home.pages.de/~kclee/clemens/jacob">. -<item>Emacs in Java. Si veda in <url id="http://jemacs.sourceforge.net/">. -<item>Netbeans developer, ora chiamato <em>Forte</em>. Basato - sull'architettura Javabeans. Si veda in - <url id="http://www.netbeans.com">. Recentemente Sun ha annunciato - che intende renderlo Open Source. Si veda in - <url id="http://www.sun.com/forte/tools4dotcom/opensource.html">. -<item>AnyJ. Ambiente grafico per sviluppare applicazioni, applet e - servlet. Per maggiori informazioni: - <url id="http://www.netcomputing.de">. -<item>Free Builder. Un IDE Java scritto in Java e distribuito sotto - GPL <url id="http://www.freebuilder.org">. - -<item>CodeGuide. <url id="http://www.omnicore.com">. Licenza non libera, ma - non ci sono spese in caso di uso non commerciale (da controllare). - -</list> - - - - -<sect>Installer di pacchetti -<p> -<sect1 id="installer">Quali programmi Java hanno un installer? -<p> -<list> - -<item><prgn>vajava</prgn> è un IDE per Java. Lo si può trovare in - <url id="http://software.ibm.com/ad/vajava">. - <em>TODO: controllare il copyright</em>. -<item><prgn>ibm-jdk1.1</prgn>. Installer per l' IBM Developer Kit per Linux, -Java(tm) Technology Edition. Installa la versione alfa 1.1.6 dell'IBM -Developer Kit. L'IBM Developer Kit è un ambiente di sviluppo per -scrivere applet ed applicazioni che siano conformi al nucleo delle API di -Java 1.1. Il suo compilatore e gli altri tool si lanciano da -shell e non hanno un'interfaccia grafica. -<p> -L'IBM Developer Kit include la IBM JIT (libjitc.so), usata da tutti -i tool predefiniti. Si veda in <url id="http://master.debian.org/~doko">. -Necessita un aggiornamento alla 1.1.8. Sembra comunque che fornire -un installer possa violare la loro licenza (si veda in <ref id="ibm-jdk1.1">). - -<item><prgn>jdk1.2-installer</prgn>. Si veda, per questo, in <url -id="http://www.pobox.com/~julio/debian/jdk1.2-installer/">. -Quest'ultima funziona con la versione pre-release e occorre -fare un po' di lavoro per installare la release candidate version. -(Aggiornamento, aprile 2000, il link sembra non essere corretto, suggerimenti?) - -</list> - - - -<sect1>Quali programmi Java si potrebbero sviluppare con un installer? -<p> - -Un importante programma di installazione mancante è quello per -J2SDK serie 1.4 della Sun. - -<p> -Alcuni altri sono: - -<list> -<item><prgn>jdk-1.2.2</prgn> SE Standard Edition - <url id="http://www.javasoft.com/products/jdk/1.2/download-linux.html">. -<item><prgn>jbuilder3</prgn>. Un IDE Java da Inprise (scritto in -java) <url -id="ftp://ftp.inprise.com/pub/jbuilder/jb3foundation/sol_linux/">. -Funziona bene. -<item><prgn>netbeans</prgn>. Un altro IDE Java (anch'esso scritto in java) -<url id="http://www.netbeans.com/"> per scrivere piccole applicazioni -grafiche. - -</list> - - - -<appendix>Versioni più vecchie di Debian GNU/Linux - -<p>Questa appendice è inclusa per ragioni di carattere puramente -storiografico e contiene informazioni fornite, di solito, nella -FAQ (come infatti avviene!). - - -<sect>Debian 2.2 "potato" -<p> -<list> - -<item>Librerie -<list> -<item>lib-fop-java -<item>lib-gnu.getopt-java -<item>lib-gnu.regexp-java -<item>lib-openxml-java -<item>lib-rxtx-java -<item>lib-sax-java -<item>lib-xp-java -<item>lib-xslp-java -<item>lib-xt-java -<item>lib-dom-java -<item>libpgjava -<item>libgcj0 -</list> - -<item><package>bock</package> Bootstrap-only compiler kit per un -sottoinsieme di Java(tm) - -<item><package>doc++</package> Un sistema di documentazione per C/C++ e Java - -<item><package>fastjar</package> un completo sostituto per le utility -jar scritto in C sotto licenza GPL <url -id="http://www.engr.orst.edu/~burnsbr/fastjar/"> (controllare <url -id="http://lists.debian.org/debian-java/1999/debian-java-199908/msg00015.html">). - -<item><package>java2html</package> Sorgenti Java evidenziati per -presentazioni WWW. - -<item><package>gcj</package> Il compilatore GNU per Java(tm). - -<item><package>global</package> Ricerca e consultazione di codice sorgente. - -<item><package>guavac</package> Un compilatore Java. - -<item><package>jikes</package> Un veloce compilatore Java aderente al -linguaggio e alle specifiche delle VM. - -<item><package>jikes-pg</package> Jikes Parser Generator. - -<item><package>oo-browser</package> Object Oriented (X)Emacs Class Browser. - -<item><package>mmake</package> Un generatore di Makefile per programmi -Java. - -<item><package>cocoon</package> Una servlet XML/XSL per publishing framework. - -<item><package>bsh</package> Un'ambiente Java scripting. -<item><package>cup</package> LALR generatore parser per Java. -<item><package>freetds-jdbc</package>. Un driver Java JDBC per MS SQL -e Sybase. - -<item><package>gnujsp</package> Un'implementazione libera del -Sun Java Server Pages (JSP 1.0) - -<item><package>jlex</package> Un generatore di analisi lessicali Lex-style -per Java. - -<item><package>jserv</package> Un motore Java Servlet 2.0 con un modulo -opzionale per Apache. - -<item><package>tya</package> Un compilatore JIT per Java. - -<item><package>ibm-jdk1.1-installer</package>. Installer per l'IBM -Developer Kit per Linux, Java(tm) Technology Edition. (vedere <ref -id="installer">). - -<item><package>jdk1.1</package>.JDK 1.1.x (Java Development Kit) - -Solo runtime. - -<item><package>jdk1.1-dev</package> JDK 1.1.x (Java Development Kit) - -<item><package> biss-awt</package> Un'applicazione GUI per la -programmazione Java in framework. - -<item><package>jdk1.1-native</package> JDK 1.1.x Runtime - estensioni -dei thread nativi. - -<item><package>jdk1.1-native-dev</package> JDK 1.1.x - estensioni -dei thread nativi. - -<item><package>vrwave</package> VRML 2.0, un browser basato su java. - -</list> - -<p>Molti editor (jed, elvis, vim, emacs, fte, xcoral, zed ....) hanno -il supporto per la sintassi Java. - -<sect>Debian 2.1 "slink" -<p> -<list> -<item><package>jdk 1.1.5v5</package> -<item><package>vrwave</package>. Un browser VRML Java. -<item><package>icq-java</package>. Un installer per programmi ICQJava. -<item><package>jde</package>. Un Java Development Enviroment per Emacs -<url id="http://sunsite.auc.dk/jde">. -<item><package>jlex</package>. Un generatore di analisi lessicale simile -allo UNIX <prgn>lex</prgn>. -<item><package>mmake</package>. Un generatore di Makefiles per -programmi Java. Ulteriori informazioni presso -<url id="http://www.tildeslash.com/mmake"> -<item><package>libpgjava</package>. Una classe Java che abilita le -comunicazioni con il database PostgreSQL usando JDBC. -<item><package>cup</package>. Un parser simile a <prgn>yacc</prgn>. -<item><package>ilu-javadev</package>. Header e librerie di sviluppo per -l'Inter-Language Unification System. -</list> - - -<sect1> -Ho installato l'ultimo pacchetto jde... cosa devo fare affinché Emacs entri -in jde-mode automaticamente, al caricamento di un file di codice sorgente Java? - -<p> -Come viene spiegato in <file>/usr/doc/jde/README.Debian</file>, tutto -quello che occorre fare è inserire: - -<example> - (require 'jde) -</example> -nel proprio file <file>~/.emacs</file>. -<p> -Da notare che altri pacchetti add-on per Emacs non sono abilitati in modo -predefinito, per esempio, AucTeX. - -<sect>Debian 2.0 "hamm" -<p> -<list> -<item><package>jdk 1.1.5v5</package> -</list> - -<sect>Debian 1.3.1 "bo" -<p> -<list> -<item><package>jdk 1.0.2</package> -</list> - - - - -<appendix id="traduzione">Traduzione - -<p> - -La traduzione del documento è stata effettuata da -Chiara Bianchi <email/piposkj@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 <link> tag in ant. An -example: - -<example> -# command line example of linking against system doc. -javadoc -link /usr/share/doc/default-jdk-doc/api [other arguments] - -<!-- Ant example of linking against system doc --> -<javadoc [attributes]> - <link href="/usr/share/doc/default-jdk-doc/api/" /> - [other tags] -</javadoc> -</example> -</p> - -<p>The documentation must be installed at the time the linking is -done; so in the example cases above the package would need a -Build-Depends or a Build-Depends-Indep on -<package>default-jdk-doc</package>. -</p> - -<p> -Here is a short list of packages that can be used for reference: -<list> - <item><package>commons-jci</package></item> - <item><package>ow-util-ant-tasks</package></item> - <item><package>libhamcrest-java</package></item> - <item><package>libfreemarker-java</package></item> -</list> -</p> - -<chapt>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/<package>. - </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<N>-runtime</emphasis> - or <emphasis>java<N>-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/<package>/api/</filename> or - <filename>/usr/share/doc/<package>/api-<component>/</filename>. - </para> - - <para> - The API &must; be placed in a separate doc package. This package - &must; recommend the doc packages it was linked against. - </para> - </sect1> - - <sect1 id="policy-gcj-native"> - <title>Native Java Bytecode (gcj packages)</title> - - <para> - Java bytecode compiled into native code is referred to as - gcj-code and packages containing gcj-code as gcj-packages. - </para> - - <para> - gcj-packages has been added in order to improve - performance of Java libraries and programs. This is - particularly useful on architectures where the JVM - does not have a &JIT;. However, this performance comes - at the cost of size, extra compilation time and - creates architecture dependent packages. - </para> - - <para> - Packages &mustnot; ship gcj-code without the permission of - the Java team (&djmail;). Source packages that shipped - gcj-packages as of March 22nd,2010, have been given this - permission through the ratification of this policy. - </para> - - <para> - A request for permission to add gcj should convince - the Java Team that the performance boost of adding - the gcj-packages out-weights the disadvantages. - </para> - - <para> - Source packages compiling gcj-packages &must; Build-Depend on - &g-n-h; (formerly known as &d-jbdep;). The gcj-code &should; - only be shipped for a selected set of architectures. - </para> - - <para> - The gcj-code &must; be installed in <filename>/usr/lib/gcj/</filename> - and shipped separately from the original jar file. The gcj-package - &must; also install the classmap file generated by aot-compile in - <filename>/usr/share/gcj/classmap.d/</filename>. - </para> - - <para> - The gcj-package &must; call rebuild-gcj-db in the postinst and - postrm script, if rebuild-gcj-db is present. - </para> - - <para> - The gcj-package &must; depend on the package providing the jar - file, it is a native compilation. - The package containing the jar file &must; declare either a - Suggests or a Recommends relationship on the gcj-package. - </para> - - </sect1> - - <sect1 id="policy-politics"> - <title>Main, contrib or non-free</title> - - <para> - About politics: packaging Java stuff changes nothing to the - rules Debian uses to find if a program is free or not. Since there are - not many free Java tools, keep in mind the following: - </para> - - <itemizedlist> - <listitem> - <para> - If your source package can compile (correctly) only - with non-free tools, it cannot go to main. If your package itself - is free, it &must; go to contrib. - </para> - </listitem> - - </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> |