From a426b9ed992fd467856bce42ce1b960379911d9b Mon Sep 17 00:00:00 2001 From: Emmanuel Bourg Date: Wed, 7 Oct 2015 21:31:37 +0200 Subject: Removed the policy and the FAQ (now in the java-policy package) --- Makefile | 86 -- debian-java-faq/Makefile | 42 - debian-java-faq/debian-java-faq.it.sgml | 1953 ------------------------------- debian-java-faq/debian-java-faq.sgml | 502 -------- debian/README.Debian | 8 - debian/changelog | 1 + debian/control | 14 +- debian/java-common.dirs | 1 - debian/java-common.doc-base.faq | 13 - debian/java-common.doc-base.policy | 13 - debian/rules | 3 - html.dsl | 29 - patches/0.16-policy.author | 7 - patches/0.16-policy.patch | 56 - patches/0.18-jni-policy.author | 1 - patches/0.18-jni-policy.patch | 52 - policy.xml | 559 --------- 17 files changed, 5 insertions(+), 3335 deletions(-) delete mode 100644 Makefile delete mode 100644 debian-java-faq/Makefile delete mode 100644 debian-java-faq/debian-java-faq.it.sgml delete mode 100644 debian-java-faq/debian-java-faq.sgml delete mode 100644 debian/README.Debian delete mode 100644 debian/java-common.dirs delete mode 100644 debian/java-common.doc-base.faq delete mode 100644 debian/java-common.doc-base.policy delete mode 100644 html.dsl delete mode 100644 patches/0.16-policy.author delete mode 100644 patches/0.16-policy.patch delete mode 100644 patches/0.18-jni-policy.author delete mode 100644 patches/0.18-jni-policy.patch delete mode 100644 policy.xml 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/* $.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 @@ - - - - - -Debian Java FAQ - -Javier Fernández-Sanguino Peña -jfs@computer.org - - -Per la traduzione si veda l'Appendice B - -$Revision: 1.3 $ -lunedì, 28 luglio 2003 22:52:30 +0200 - - -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. - - - -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. - - - - - - - - - -Introduzione -

- -Introduzione alle FAQ di questo documento - -

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

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

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

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

-Questo documento non è dedicato ad altre distribuzioni Linux o a problemi -che non siano specificamente relativi a Debian. Vedi le - -per queste informazioni. Per informazioni più specifiche si possono -controllare le -. - - -Pubblicazione delle FAQ - -

-Questa raccolta di FAQ è reperibile presso il Debian Documentation Project -. -java-common (disponibile in -), 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. - - -Segnalare difetti di queste FAQ - -

-Si tenga conto di come questa FAQ sia molto datata (si veda -) -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 -). - -

-Eventuali difetti di questa FAQ devono essere segnalati all'attuale -manutentore, sempre che riguardino la sua ultima versione, disponibile presso -. -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. - - - -Introduzione a Java - -Cos'è Java? -

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

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

-Il supporto multithreading può avvenire sia nei kernel thread che in -quelli utente, in base all'implementazione della -Java virtual machine in uso. - -

-Naturalmente, Java è anche il nome di una popolare isola dell'Indonesia: -potete verificarlo presso la pagina -. - - - -Perché essere curiosi di Java? - -

-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. - - - -Cos'è un JIT? - -

-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. - - -Dove trovare altre informazioni su Java? - - -

-Naturalmente, 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: - - - -Le pagine della Sun . -Blackdown's . -GNU -Enterprise in a Nutshell di Gary Meyer: . -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: -. -Il , -vale la pena di leggere i seguenti articoli: - -Numero 105 - -Numero 94 - -Numero 66 e . - - - -La , i seguenti articoli potrebbero essere utili: - -Numero 87 -Numero 69 -Numero 48 -Numero 45 -Numero 33 -Numero 32 -Numero 25 - - - - - - - - - -, un giornale libero disponibile in più lingue: - - -marzo 2003: - -gennaio 1999: - -luglio 1998: - - -Il Java-CGI HOWTO di David H. Silber: -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. -Java Programming on Linux di Nathan Meyers, -con sito presso , libro dedicato -all'uso di Java in Linux (anche se non c'è una sua versione in linea). - - - -Altri siti web riguardanti Java potrebbero essere: - -The Java Lobby . -Brewing Java: un piccola guida, presso . - - - -Per informazioni gratuite su Java, si può consultare la rete con Google; per -applet con codice sorgente, -. -Si veda anche per puntatori disponibili alle piattaforme -java gratuite, che potrebbero anche non essere riportati nelle pagine GNU in -rete dedicate a Java. - - -Dove posso fare domande su java in Debian? - -

-Il posto giusto dove porre domande è -debian-java at lists.debian.org. È possibile -iscriversi presso la pagina delle -. - - - - -La situazione di Java in Debian GNU/Linux 3.0 (Woody) - - - -Dove sta andando Java? - -

-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 - - -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 -. - - - -nella distribuzione standard di Debian per motivi concernenti le licenze e -non per motivazioni tecniche (si veda in ). - -

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

-Per chi è veramente interessato, si consiglia di leggere: -e . -Questa sezione è un sunto delle informazioni in essi contenute. - - -È disponibile un compilatore Java1 (da .java a .class)? - - -

-Esiste il Kopi Java Compiler, scritto in Java ed il super veloce -Jikes scritto in C++. - -

-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. - - -È disponibile Java1 JVM o JIT? - -

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

-È disponibile anche Japhar. - -

-libgcj (la libreria run-time per gcj) adesso include interprete e -ClassLoader. - -

tya, un compilatore JIT, è adesso disponibile. - - -È disponibile un compilatore nativo Java1? - - -

-GCC, la GNU Compiler Collection include GCJ, il compilatore Gnu per Java. - - -Compilatore nativo Java2 - - -

-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. - - - -Debian ha le fondamentali librerie Java2? - - -

-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. - - - -È disponibile un debugger Java (equivalente a jdb)? -

jswat - - -

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

-Si veda su come fare -il debug di programmi Java compilati con gcj. - - - -Quali sono gli editor interattivi/grafici, -liberi, disponibili in Debian? - -

jde, ddd, altri? - -

-Una delle più interessanti caratteristiche di jde è l'autoindentazione e -l'evidenziazione della sintassi, ma supporta anche il -debugging e la compilazione. - - -Problemi conosciuti - -

-La mia versione di jdb (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. - -

-ddd 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. - - -È disponibile un tool appletviewer? - -

-Ci sono molte possibilità per quanto riguarda i programmi appletviewer: - - -Blackdown appletviewer (in jdk1.1). -Kaffe's appletviewer. -Ibm appletviewer (in ibm-jdk). - - - -È disponibile un tool Jar? - -

-FastJar che è davvero molto veloce. -Kaffe ha anche un tool jar. - - -È disponibile un tool Javadoc? - -

-doc++ può funzionare con C++ e Java. -In più, ci sono i pacchetti gjdoc e -gjdoc-native. - - - -Debian supporta Enterprise Java Beans (EJB)? - -

-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). - - - -Cos'è JAIN? - -

-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. - - - -Cos'è Jini? - -

-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. - - -C'è una lista completa di pacchetti? - -

-Segue una lista di pacchetti reperibili in Debian 3.0 (aka Woody), che non -specifica quali siano inclusi in contrib o in non-free. - - - -

- - - Ambiente Virtual Machines runtime. - - jdk1.1 (Sun JDK 1.1.8) - IBM JDK 1.1.8 (pacchetto con installer) - kaffe - kissme - - Tool - - Compilatori - - jikes (anche jikes-1.14, jikes-gij, - jikes-kaffe) - jdk1.1 - gcj - tya (compilatore JIT) - - Tool per il debugger ed il testing - - jswat - junit - - IDE ed editor - - jedit - jde - - Build tools - - ant - jmk - mmake - - Altri - - fastjar - jad (decompilatore) - - -Ant - -Librerie - - lib-dom-java - lib-gnu.getopt-java - lib-gnu.regexp-java - lib-saxon-java - libavalon-excalibur-java - libavalon-framework-java - libbcel-java - libbsf-java - libcrimson-java - libcommons-beanutils-java - libcommons-collections-java - libcommons-digester-java - libjdom-java - libjunitperf-java - libldap-java - liblog4j - liblogkit-java - libnbio-java - liboro-java - libpgjava - libreadline-java - libregexp-java - libservlet2.3-java - libservlet2.2-java - libsoap-java - libtomcat4-java - libxalan-java - libxalan2-java - libxerces-java - libxerces2-java - libxt-java - - - - - -Situazione di Java in Debian GNU/Linux Testing/Unstable - -Ci sono molti cambiamenti? -

-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 -gjdoc; tuttavia, nel gruppo di discussione su -debian-java, nel 2003, si è parlato di altri strumenti. - -

-Inoltre, sembra esserci anche un incentivo a includere -ant in main, cosa che dovrebbe consentirvi -l'inclusione di altri pacchetti. - -

-Il pacchetto eclipse 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. - -

-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: - - - eclipse una IDE - sablevm una Virtual Machine - free-java-sdk Un Java SDK libero - (compilato con strumenti Java compatibili con DSFG) - libgnome0-java Binding Java alla libreria - della GUI di Gnome - gjdoc Un sostituto di Javadoc 1.3 - (implementa 90% delle Doclet API) - - - -Lo sviluppo di Java -

- - -Quali piattaforme di sviluppo complete, per Java, sono - disponibili in Debian? - - -

-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: - - -jdk 1.1 Sun (port a cura di Blackdown, si veda in - o presso il relativo sito web: - ) -kaffe. -jdk di ibm (si veda in ) - - -

-Debian Sid ha il pacchetto free-java-sdk che -fornisce una versione libera del Java Software Development Kit (SDK). -Tutto il software da cui dipende è conforme alle DFSG Debian. - - - -Quali piattaforme libere ci sono per Debian e come posso -contribuire allo sviluppo? - -

-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: - - - -kaffe: . -Japhar: . La Java virtual -machine di "Hungry Programmer". Altre informazioni in . -gcj e libgcj: - -jikes: . Un compilatore -veloce scritto in C++ (si controlli anche ). - Sembra che le nuove licenze sia definitivamente libere -kopi: . Ancora un'altro compilatore -libero per Java, scritto in Java e GPL. Incluso in Kaffe fin dalla versione -1.0.5. -FastJar , un tool jar - (questo link sembra non essere corretto, suggerimenti?). -Classpath o -. -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. -Molte delle classi RMI sono implementate da NinjaRMI -. -Autoconf macros -è utile per una facile ricompilazione di programmi Java. -Mauve è una suite libera per testare -se questi tool siano o meno compatibili. - - - -

-Gran parte dello sviluppo libero di Java viene svolto da gruppi -che collaborano col . Esiste una mailing list sul Java libero: . - - -Domande sulle piattaforme per Debian e tutto -ciò che concerne le licenze - - -Java 2 SE (detto anche JDK1.2) -

-Per quale motivo Java 2 SE di Sun (detto anche jdk 1.2) non è -disponibile? - - -

-Ciò avviene a causa di problemi con le licenze. La seconda clausola della - (si controllino anche le ) -che recita: - - -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. - - - -Quali sono i problemi con la nuova licenza della Sun? - -

-Sun si è spostata su un nuovo tipo di licenza, la -Sun Community License, 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. - - -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. - - - - Cosa è la SCSL? - -

-SCSL è la "Sun Community Software License" che si può trovare all'URL -. 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. - - -

-Per citare uno sviluppatore Open Source, la SCSL è "pressappoco libera -quanto la passata Unione Sovietica". - -

-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. - - -È possibile usare jdk1.2 lavorando con le implementazioni -libere di Java? - -

-La Clausola numero 1 delle Supplemental License Terms recita: - - - 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; - - -

-Questo, pare eviti che chiunque faccia implementazioni proprie -degli standard delle classi Java utilizzando le JDK. - -

-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. - - - -Perché (alcuni) software liberi non implementano Java2? - -

-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. - - -La jdk1.1 di IBM -

-Debian può distribuire la jdk1.1 di IBM? -

-Pare di no. Di seguito la licenza: - - -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. - -

-Si veda il bug #54641 per un problema circa il JDK IBM. È possibile -scaricarlo da . - - -C'è la possibilità di ottenere una licenza per Debian 2.1? - - -

-Non sarebbe libera, per il punto 8 della DFSG: "Le licenze non possono -essere specifiche per Debian". - - -JRE -

-Debian può distribuire JRE? - -

-(da Gene McCulley: ). -Non penso che si possa voler distribuire il JRE con Debian. I termini -supplementari della licenza del JRE hanno alcune clausole piuttosto -antipatiche: - - - 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; - - -

-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. - - - (ii) non distribuire software aggiuntivo inteso come - sostituto di qualunque componente del software; - - -

-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. - - - [...](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; - - -

-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). - - - [...] 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. - - - -

Non credo che Debian (o SPI) possa o voglia far questo. -

- -

-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. - -GPL or LGPL? -

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

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

-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. - - -Come si crea un programma Java, con interfaccia grafica, compatibile - con DFSG? - -

-Molti programmi Java usano la libreria Swing per lo sviluppo di interfacce -grafiche; per questo c'è libswing-java. -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. - -

-Lo Standard Widget Toolkit (SWT, libswt-java), -basato sulla libreria GTK+, è un'alternativa alla libreria Swing. - -

-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 libgnome0-java. - -I programmi basati su swing funzionano in Debian? - -

-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 , per scoprire -come farlo funzionare. - - -Creare pacchetti Debian per programmi Java. -

- -È possibile inserire il pacchetto in main? - -

-Sì, ma solo qualora 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 deve essere collocato in esse, a seconda -della propria licenza. - -

-Più specificatamente, se il programma può essere creato ed eseguito con -free-java-sdk, allora dipende solo da pacchetti -provenienti da main. La descrizione di free-java-sdk -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". - - -Quali pacchetti virtuali si potrebbero usare? -

- -java-common. È 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). -java-virtual-machine -java-compiler -java-compiler-dummy. È 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: - - - -fornisce il java-compiler, in modo tale che pacchetti - superiori non abbiano problemi; -imposta CLASSPATH prima di chiamare la vera VM. - - -java-virtual-machine-dummy. È 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: - - -fornisce la java-virtual-machine, in modo tale che pacchetti - superiori non abbiano problemi; -imposta CLASSPATH prima di chiamare la vera VM. - - - - -C'è un buon esempio di pacchetto Debian? - -

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

A tal proposito, si controlli sul progetto pkg-java -(pkg.java-project), presso il sito della Alioth: -. - -

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: - e -. - - -Ci sono strumenti per facilitare il mantenimento di pacchetti Java? - -

Attualmente, solo dh_javadoc, presente nella distribuzione unstable -di Debian, nel pacchetto gjdoc. - - - -Compilatori Java -

- - -Quali compilatori Java sono disponibili per Debian? -

- - - - -guavac, il compilatore della Effective Edge Technologies. -Questo compilatore è privo di upstream; per un corretto funzionamento si può -usare gcj o jikes. -tya, un compilatore just-in-time, usato per -compilare codice Java in byte code. -jikes, che viene descritto funzionare bene con -tutte le JDK (dalla 1.1 alla 1.3); si suggerisce di usare -E quando -si compila con Emacs. -bock. Compilatore da Java a C. -gcj. Compila sorgenti Java in codice nativo, -codice sorgente in bytecode, o bytecode in codice nativo. -gck. È disponibile? -kjc è incluso in kaffe 1.0.5. -Attualmente non ci sono pacchetti separati. - - - - - - -Java Virtual Machines (JVM) -

- - - -Quali JVM funzionano in Debian? - -

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

-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). - - -Quali JVM libere sono disponibili per Debian? -

- - - -kaffe. Non fa funzionare tutti i programmi, -anche se si presume che funzioni con Jigsaw (una distribuzione da 10Mb), -si veda in . - -sablevm. - - - -Che tipo di API forniscono queste JVM? - -

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

Molte API sono messe a confronto per GNU Classpath, GNU gcj, -Kaffe e Wonka con -. - - -In che misura le API sono implementate dalle JVM? - -

Si dà qui un riassunto dei risultati delle prove - - -Ci sono problemi noti? - -

-Sì, alcuni, segnalati come difetti relativi a Debian, si possono consultare -sul , -sistema Debian di ricerca dei bug. -Ecco alcuni pacchetti, come collegamento veloce: - - - - - - - - - -

-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 è reportbug. - - -In Debian, per eseguire un programma java è davvero necessaria una JVM? -

-No, si può provare ad eseguire le applicazioni senza una jvm, basta -compilare il codice sorgente in codice nativo. - - - -Come compilo il codice nativo? - -

-Si dovrebbe essere in grado di usare gcj o jikes -(che sono entrambi programmi liberi), per compilare il programma e -usare gcj per convertire bytecode in codice nativo. -L'intera catena di software è libera. - - - -Si tratta di un approccio riuscito? - -

Senz'altro, si veda in -come è stato fatto per il parser XML xp. - -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 - - -Ci sono stati problemi con tale approccio? - -

-Sì, ci sono stati anche alcuni problemi. - -

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

-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. - - -Funziona con architetture diverse dall'i386? - -

È possibile di no, dal momento che libgcj non funziona su sparc -e nessuno ci ha provato. - - - -Plugin Java per browser - -

La prossima sezione descrive come utilizzare Java all'interno dei -browser, per eseguire le applet pubblicate nei web server. - -Si può usare qualsiasi JVM come plugin Java? - -

-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). - - -Si può usare Java in Konqueror? - -

-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: - - - "Abilita java globalmente" - Selezionato - "Mostra la console Java" - Selezionato - "Percorso dell'eseguibile Java" indicante /usr/bin/java - - -

-Dicendo /usr/bin/java ci si affida al meccanismo -dell'update-alternatives per puntare ad una -JVM che funzioni da plugin. Se si è installato J2RE, il -"percorso di Java" potrebbe anche essere -/usr/local/j2sdk1.4.1/jre/bin/java. - - -Si può usare java in Netscape 6.x/7.x? - -

-Sì: basta creare un link simbolico verso il plugin per Java -nella /path/to/netscape/plugins, come si evince nel -J2RE della Sun: - -/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 - - -

-Se si è installato J2RE di Blackdown, il link simbolico deve essere -creato verso -/usr/lib/j2se/1.4/jre/plugin/i386/mozilla/javaplugin_oji.so. - -Si può utilizzare Java in Mozilla 1.x? - -

Sì, seguendo un procedimento identico a quello adottato per Netscape -- la cartella dei plugin, però, in questo caso sarà -usr/lib/mozilla/plugins. - - - -Servlet Java -

-Come far funzionare le servlet Java? -

Si può usare: - - gnujsp - Apache jserv. . - Apache tomcat da - . - -Altri non pacchettizzati per Debian, ma che presto saranno inclusi, sono: - - - -jigsaw da . -Jetty (testato -con successo su una macchina con un sistema Debian Potato) - - - - -Le servlet funzionano con kaffe? -

-La servlet.jar in Kaffe non funziona. È solo una shell. -Esiste un'altra implementazione LGPL scritta da Paul e Mark Wielaard. -Disponibile in -dovrà essere (lo è stato?) aggiunto il pacchetto Apache JServ in modo -tale che l'utente non debba scaricare nuovamente le classi Sun. - - -È necessaria una versione di Java non libera per far funzionare -le servlet? - -

Nessuna conosciuta. Possibilmente, no, ma è necessaria una spiegazione. - - - - -Le politiche di Java -

-È disponibile una politica Java per Debian? - -

-È ancora in fase di elaborazione. L'attuale linea di condotta si -rivolge solo ad alcuni problemi e non è stata rilasciata -ufficialmente: è reperibile all'indirizzo - ed -anche nel pacchetto java-common. - - - -Ci sono delle imperfezioni nella politica di Java? - -

-Sì, su alcuni punti la discussione è aperta. Per favore, si veda in -. Così è veramente sconveniente -usare diversi compilatori di virtual machine -prima che sia impostata la CLASSPATH per ognuno di essi. - - - - -Altre alternative Java per Debian -

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

-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. - - - -Come procurarsi pacchetti da BlackDown - -

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

-(contributo di Federico Mennite) Se si desidera utilizzare i loro pacchetti, -occorre aggiungere la seguente riga - - -È necessario usarne una sola, potrebbe essere per -potato o woody, in base alla versione di Debian -in uso, o potrebbe anche essere testing o unstable -se si tratta di una release in sviluppo. - - -in /etc/apt/sources.list: - - -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 - - -

-Dove proto://url è uno dei mirror disponibili dalla lista -in . - - -È necessario l'archivio main, dal momento -che ora lì c'è un pacchetto j2se-common. -Se sono già state installate le j2sdk quando non esistevano -le dipendenze di cui sopra, si otterranno dei warning -quando vengono eseguiti i comandi apt-get update -o apt-get upgrade. - - -Ad esempio, in Debian 3.0, che usa il mirror di Metalab si usa: - - -deb ftp://metalab.unc.edu/pub/linux/devel/lang/java/blackdown.org/debian woody main non-free - - -

Poi: - - -$ apt-get update -$ apt-get install j2sdk1.3 - - -

Si noti che, al momento della stesura di questo scritto, ci -sono pacchetti di Blackdown, in fase beta, solo per la versione -unstable di Java 1.4. - - -

-(contributo di Paul Reavis) Scaricare e installare le JDK dai -file tar.gz, scompattarli in /usr/local/jdk1.1.x e -usare dei link simbolici per creare /usr/local/jdk ed i -link ai binari in /usr/local/bin 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. - -

-Ecco una lista dei rilasci che certamente funzionano con ciascuna -versione di Debian e di tutto il software necessario perché -funzionino, se esiste. - - -rex/bo: 1.1.5v7 (libc5). -hamm:1.1.5v7 (glibc), ha bisogno dell'ultima glibc di slink. -slink: 1.1.6-test2 (glibc). - - - -Far funzionare swing in Debian - - -

-(da Paul Reavis) [Una cosa fatta in fretta per far sì che -Swing funzioni davvero sotto Debian o qualsiasi altro Linux] - -

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

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

-Non ho l'archivio sotto mano, così lo chiameremo -swing.tar.Z. Si consiglia di installarlo in /usr/local così: - - - skronk# cd /usr/local - skronk# tar xzf /tmp/swing.tar.Z - - -

-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: - - - skronk$ cd /usr/local/swing/examples/SwingSet - skronk$ echo $JAVA_HOME - /usr/local/jdk - skronk$ unset CLASSPATH - skronk$ echo $CLASSPATH - - skronk$ ./runnit - - -

-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. - - - -Far funzionare Java 2 in Debian - -

-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 apt) dai diversi mirror disponibili qui: - -(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 . - -

O, se si desidera fare da soli e scaricarsi gli -archivi (quindi tar.gz e non pacchetti .deb), si può anche seguire -quest'altra strada: - - -Creare una directory in /usr/local - (per esempio /usr/local/sun). - Scaricare l'archivio in questa directory e scompattarlo. Verrà - creata una directory jdk1.X - X dipenderà dalla versione del Java 2 - state trasferendo, potrà essere 1.2.1, 1.2.2, 1.3 o - persino 1.4. - Sistemare le alternative perché funzioni correttamente: - - 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 - - Controllare le proprie alternative con "type" - - type javac - type java - - - -A questo punto si dovrebbe avere un ambiente jdk 1.X perfettamente -funzionante, inclusi una virtual machine ed un compilatore. - -

Potrebbe essere necessario cambiare il proprio - /etc/profile aggiungendovi le variabili d'ambiente - (CLASSPATH, JAVA_COMPILER and JAVA_HOME) - 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: - - -# 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 - - -

-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". - - - - - -Come integrare J2SE SDK con Debian Testing? - -

-Ce lo spiega Warren Dodge: anzitutto, scaricare i componenti di J2SE -SDK da in -/var/install/java/1.4.1, per esempio, assicurarsi di -avere il permesso di scrittura sulla cartella e rendere eseguibile -il programma d'installazione ./j2sdk-1_4_1_02-linux-i586.bin; -la sua esecuzione creerà la cartella j2sdk1_4_1_02, che -può essere spostata in /usr/local/lib. Quindi, creare un -link simbolico -ln -s /usr/local/lib/j2sdk1_4_1_02 /usr/local/lib/jdk, che -permette di utilizzare la collocazione più recente nel riferimento -all'ambiente Java e rende molto più semplice un futuro aggiornamento. - -

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 java-common: - - -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 - - -Ora, in /var/install/java/pkg dovrebbero esserci cinque -pacchetti installati. - -

-Per scegliere il pacchetto da usare, fra molti che possano svolgere -la stessa funzione, in Debian si usa il comando -update-alternatives ("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: - -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 - - -

-Per consentire la creazione di cartelle per le preferenze di sistema -e per verificare il corretto funzionamento di java della -Sun, lo si esegua una volta da root: - - java -version - - - - -Come integrare J2SE SDK della Sun con Debian Stable? -

-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. - - - - -Altri programmi Java che non sono ancora disponibili per Debian - -

-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 potrebbero essere pacchettizzati per Debian o quelli per i -quali qualcuno sta preparando un installer: - - - -BlueJ. Un ambiente di sviluppo per Java con un editor, un compilatore, - una virtual machine ed un debugger. Si veda in - -Jacob (Java Commando Base): project maintainer e visualiser - per Java in Emacs. Si veda in - . -Emacs in Java. Si veda in . -Netbeans developer, ora chiamato Forte. Basato - sull'architettura Javabeans. Si veda in - . Recentemente Sun ha annunciato - che intende renderlo Open Source. Si veda in - . -AnyJ. Ambiente grafico per sviluppare applicazioni, applet e - servlet. Per maggiori informazioni: - . -Free Builder. Un IDE Java scritto in Java e distribuito sotto - GPL . - -CodeGuide. . Licenza non libera, ma - non ci sono spese in caso di uso non commerciale (da controllare). - - - - - - -Installer di pacchetti -

-Quali programmi Java hanno un installer? -

- - -vajava è un IDE per Java. Lo si può trovare in - . - TODO: controllare il copyright. -ibm-jdk1.1. 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. -

-L'IBM Developer Kit include la IBM JIT (libjitc.so), usata da tutti -i tool predefiniti. Si veda in . -Necessita un aggiornamento alla 1.1.8. Sembra comunque che fornire -un installer possa violare la loro licenza (si veda in ). - -jdk1.2-installer. Si veda, per questo, in . -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?) - - - - - -Quali programmi Java si potrebbero sviluppare con un installer? -

- -Un importante programma di installazione mancante è quello per -J2SDK serie 1.4 della Sun. - -

-Alcuni altri sono: - - -jdk-1.2.2 SE Standard Edition - . -jbuilder3. Un IDE Java da Inprise (scritto in -java) . -Funziona bene. -netbeans. Un altro IDE Java (anch'esso scritto in java) - per scrivere piccole applicazioni -grafiche. - - - - - -Versioni più vecchie di Debian GNU/Linux - -

Questa appendice è inclusa per ragioni di carattere puramente -storiografico e contiene informazioni fornite, di solito, nella -FAQ (come infatti avviene!). - - -Debian 2.2 "potato" -

- - -Librerie - -lib-fop-java -lib-gnu.getopt-java -lib-gnu.regexp-java -lib-openxml-java -lib-rxtx-java -lib-sax-java -lib-xp-java -lib-xslp-java -lib-xt-java -lib-dom-java -libpgjava -libgcj0 - - -bock Bootstrap-only compiler kit per un -sottoinsieme di Java(tm) - -doc++ Un sistema di documentazione per C/C++ e Java - -fastjar un completo sostituto per le utility -jar scritto in C sotto licenza GPL (controllare ). - -java2html Sorgenti Java evidenziati per -presentazioni WWW. - -gcj Il compilatore GNU per Java(tm). - -global Ricerca e consultazione di codice sorgente. - -guavac Un compilatore Java. - -jikes Un veloce compilatore Java aderente al -linguaggio e alle specifiche delle VM. - -jikes-pg Jikes Parser Generator. - -oo-browser Object Oriented (X)Emacs Class Browser. - -mmake Un generatore di Makefile per programmi -Java. - -cocoon Una servlet XML/XSL per publishing framework. - -bsh Un'ambiente Java scripting. -cup LALR generatore parser per Java. -freetds-jdbc. Un driver Java JDBC per MS SQL -e Sybase. - -gnujsp Un'implementazione libera del -Sun Java Server Pages (JSP 1.0) - -jlex Un generatore di analisi lessicali Lex-style -per Java. - -jserv Un motore Java Servlet 2.0 con un modulo -opzionale per Apache. - -tya Un compilatore JIT per Java. - -ibm-jdk1.1-installer. Installer per l'IBM -Developer Kit per Linux, Java(tm) Technology Edition. (vedere ). - -jdk1.1.JDK 1.1.x (Java Development Kit) - -Solo runtime. - -jdk1.1-dev JDK 1.1.x (Java Development Kit) - - biss-awt Un'applicazione GUI per la -programmazione Java in framework. - -jdk1.1-native JDK 1.1.x Runtime - estensioni -dei thread nativi. - -jdk1.1-native-dev JDK 1.1.x - estensioni -dei thread nativi. - -vrwave VRML 2.0, un browser basato su java. - - - -

Molti editor (jed, elvis, vim, emacs, fte, xcoral, zed ....) hanno -il supporto per la sintassi Java. - -Debian 2.1 "slink" -

- -jdk 1.1.5v5 -vrwave. Un browser VRML Java. -icq-java. Un installer per programmi ICQJava. -jde. Un Java Development Enviroment per Emacs -. -jlex. Un generatore di analisi lessicale simile -allo UNIX lex. -mmake. Un generatore di Makefiles per -programmi Java. Ulteriori informazioni presso - -libpgjava. Una classe Java che abilita le -comunicazioni con il database PostgreSQL usando JDBC. -cup. Un parser simile a yacc. -ilu-javadev. Header e librerie di sviluppo per -l'Inter-Language Unification System. - - - - -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? - -

-Come viene spiegato in /usr/doc/jde/README.Debian, tutto -quello che occorre fare è inserire: - - - (require 'jde) - -nel proprio file ~/.emacs. -

-Da notare che altri pacchetti add-on per Emacs non sono abilitati in modo -predefinito, per esempio, AucTeX. - -Debian 2.0 "hamm" -

- -jdk 1.1.5v5 - - -Debian 1.3.1 "bo" -

- -jdk 1.0.2 - - - - - -Traduzione - -

- -La traduzione del documento è stata effettuata da -Chiara Bianchi - - - 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 @@ - - - - - -Debian Java FAQ. - -Torsten Werner -twerner@debian.org - - -Niels Thykier -niels@thykier.net - - -Javier Fernández-Sanguino Peña -jfs@debian.org - - -Sylvestre Ledru -sylvestre@debian.org - -$Revision: 7831 $, $Date: 2013-06-05 21:17:15 +0100 $ - - -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 . - - - -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. - - - - - - - - - -Introduction -

- -Introduction to this FAQ - -

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

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

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

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

This document does not address issues with other Linux -distributions, or with non-Debian-specific problems. - - -Location of this FAQ - -

This FAQ is published under the Debian Documentation Project -at . -The java-common (available at -) 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. - -Sending bugs on this FAQ - -

Please note that this FAQ is still outdated but gets updated step by step. - -

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 before -filing a bug report. Translations, if available, and the offline version in -the java-common package might be out of date. - -What is Java? -

-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 . - -Where can I ask questions about Java on Debian? - -

The appropriate place to ask such questions is debian-java -at lists.debian.org. You can subscribe at the page. - -Complementary information - -

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 - at the Debian's wiki. - -

Since Ubuntu is based on Debian, some users might find it helpful -to check the tips on on Ubuntu's wiki. - -Uncovered issues - -

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: - - - -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. - -Specific information targeted for non-i386 users (PowerPC users and AMD64 users), some can be found in Ubuntu's wiki. - - - - - -Java Development -

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

If you are looking for an integrated, java virtual machine, -compiler and runtime environment Debian does provide them. Of course -that would depend on the Debian GNU/Linux version you are using, -generally speaking they would be: - - - -Sun's OpenJDK 6, available since the Debian 5.0 Lenny -release in the main section. - -Oracle's OpenJDK 7, available since the Debian 7.0 Wheezy -release in the main section. - -The combination GCJ, GIJ, and Classpath in the main section. - - -

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. - -What free platforms are there and how can I contribute? -

-Please help one of the Free Java implementations if you want to use Java -in Debian. There are a lot of projects that you can choose from: - - -openjdk: - -gcj and libgcj: - -Classpath . 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) - -Mauve is a free suite to test if -these tools are 'compliant'. - - - -

Most free Java development is grouped under the . - -Questions on platforms and license concerns - -Java 6 and 7 - -

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: - - -apt-get install openjdk-6-jdk - - -or the Java runtime environment: - - -apt-get install openjdk-6-jre - - -

Similarly, you can install the Java 7 development kit: - - -apt-get install openjdk-7-jdk - - -or the Java 7 runtime environment: - - -apt-get install openjdk-7-jre - - -

You might want to update the alternatives system to have Sun's tools as the -default: - - -update-java-alternatives -s java-1.6.0-openjdk-amd64 - - -Or for java 7: - - -update-java-alternatives -s java-1.7.0-openjdk-amd64 - - -Oracle proprietary JVM - -

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

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 . The program make-jpkg will take an upstream archive and convert it to a Debian package. For example: - - make-jpkg jdk-6u31-linux-x64.bin - -

For more information see . - - -Making Debian packages for Java programs. - -Can the package go into main? - -

Yes, but only if it can be build and run with Java programs/tools -in main, and if it has a Debian compliant open source license. -If it needs programs from contrib or non-free, then is must -go into contrib or non-free, depending on the license of the program itself. - -Is there a good example Debian package? - -

There are many Debian packages of both Java applications and libraries. -These may serve as an good starting point, as it can serve as an example -for making a new Debian package. - -

A good start would be to check out the pkg-java project on -Alioth: . - -

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: - and -. - - -What tools are available to make maintaining a Java packages easier? - -

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 javahelper -or maven-debian-helper. gcj-jdk -also has a dh_javadoc tool.

- -Linking package Javadoc to system javadoc. - -

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: - - -# 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> - -

- -

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 -default-jdk-doc. -

- -

-Here is a short list of packages that can be used for reference: - - commons-jci - ow-util-ant-tasks - libhamcrest-java - libfreemarker-java - -

- -Managing Java (for users and administrators) -

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

- -

-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 java-common -). Some examples of how to do this are: -

- -

- -# 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 - -

- -

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

- -Java Virtual Machines (JVM) -

-What JVMs are available in Debian? - -

The following JVMs are currently available in Debian Wheezy: - - -openjdk-6-jre -openjdk-7-jre -gcj-4.7-jre - - -

- -

The following lists JVMs available in Debian 6.0 release ('Squeeze'): - - -openjdk-6-jre -sun-java6-jre (non-free) -gcj-4.4-jre - - -

-What Java Compilers are available in Debian? -

- - -openjdk-6-jdk - -openjdk-7-jdk - -gcj. 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. - - - -

- -What API do these JVMs provide? - -

Note that providing an API does not mean that everything is -implemented, and certainly not implemented correctly. - -Are there known problems? - -

Yes, there are. Some of these are reported as Debian bugs. You can -look up the bugs for a specific Debian package at the . As -a quick link, here are some packages: - - - - - - - - -

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 -reportbug. - -How can I use the proprietary version of the JDK/JRE from Oracle as a Debian package? -

-The package provides an easy way to convert an upstream installer into a Debian package. It should be as easy as: -make-jpkg ~/Downloads/jdk-6u31-linux-x64.bin - -

For more information, see this - -Do I need a JVM to run a Java program in Debian? -

-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). - -How do I compile to native code? - -

You might be able to use gcj to compile the program. -And use gcj to convert bytecode to native code. The entire -software chain is free. - - -Java Plugins for Browsers - -

- - -You can install the package icedtea-6-plugin or icedtea-7-plugin in wheezy - - - - -Java Servlets -

-How can I make Java servlets work? -

You can use: - - Apache tomcat6 from . - Eclipse jetty from . - - - -Java Policy -

-Is there a Java policy for Debian? -

-It is still in the works. The current policy addresses some -of the problems. It has not been officially released. You can find -it at . -The Java Policy can also be found in the java-common -package. - -Are there holes in the Java Policy? -

Yes, some until under discussion. Please check out the -. Thus it is very inconvenient to -use several compilers of virtual machines since there is not one -CLASSPATH setting for all of them. - -Other Java alternatives for Debian -

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

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. - -Java programs not yet available on Debian -

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

A list of missing packages is maintained on the -. - - 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 Uploaders: Matthias Klose , Torsten Werner , 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 @@ - - - -]> - - - - - - -(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 - - - - - - - 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 - -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. - - -- I &should; use /etc/alternatives -+ They &should; use /etc/alternatives - for the name 'java' if they are command-line compatible with the - Sun's java program. - -@@ -155,7 +155,7 @@ - - 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;). - - - -@@ -175,11 +175,11 @@ - /usr/bin and be executable. They can be Java - classes (using binfmt_misc) or wrappers. In any case, they &must; run - without specific environment variables (see -- Policy -- 3.8), for instance CLASSPATH. They &must; respect the Policy -+ Policy -+ 10.9), for instance CLASSPATH. They &must; respect the Policy - rules for executables (for instance a manual page per executable, see -- -- Policy 6.1). -+ -+ Policy 13.1). - - - If they have their own auxiliary classes, they -@@ -324,8 +324,8 @@ - - - Sun's Community Source Licence. Can we use it? How? -- Where can we -- find the text? -+ The 2.3 version of the text can be found -+ here. - - - -@@ -370,7 +370,7 @@ - Advices to Java packagers - - -- Warning: they are just advices, they are not part of the policy. -+ Warning: These are just advices, they are not part of the policy. - - - 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 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. - - -+ -+ 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 /usr/lib/jni in its -+ search path for these dynamic libraries. -+ - - - -@@ -245,18 +253,27 @@ - This applies only to libraries, not to the core - classes provied by a the runtime environment. - -- -+ -+ -+ 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. -+ -+ - -- 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 /usr/lib/jni. 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. - - - 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. - diff --git a/policy.xml b/policy.xml deleted file mode 100644 index 8a51ee5..0000000 --- a/policy.xml +++ /dev/null @@ -1,559 +0,0 @@ - -must"> -must not"> -may"> -should"> -java1-runtime"> -java2-runtime"> -java5-runtime"> -java5-runtime-headless"> -java6-runtime"> -java6-runtime-headless"> -java7-runtime"> -java7-runtime-headless"> -java8-runtime"> -java8-runtime-headless"> -default-jdk"> -default-jre"> -default-jre-headless"> -default-jdk-builddep"> -default-jdk-doc"> -gcj-native-helper"> -JVM"> -JIT"> - -debian-java@lists.debian.org"> -]> - - - - Debian policy for Java - $Revision:$ $Date:$ - - - Thykier - Niels - - - niels@thykier.net - - - The current author of the Java policy. - - - - - Ledru - Sylvestre - - - sylvestre@debian.org - - - - - - Lundqvist - Ola - - - opal@debian.org - - - A previous author of the Java policy. - - - - - Bortzmeyer - Stephane - - - bortzmeyer@debian.org - - - The original author of the Java policy. - - - - - - - Most issues of the Java policy have been discussed on the - &djmail; mailinglist. - - - - - - Abstract - - 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. - - - The policy covers Java virtual machines, Java compilers, Java - programs and Java libraries. - - - This policy is published under the GNU GPL v2 or later license. - - - - - - Background - - - There are several "subpolicies" in Debian. They all want to make - the Debian Policy 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 - Perl. - - - - Feel free to report comments, suggestions and/or disagreements to the - java-common package (java-common@packages.debian.org) - or the Debian Java mailing list &djmail;. Change requests should be - sent as a bug to the java-common package. - - - - - - Policy - - - Virtual packages are created: &j1r;, &j2r;, &j5r;, &j5rh;, &j6r;, &j6rh;, - &j7r;, &j7rh;, &j8r; and &j8rh;. - - - - 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. - - - - Both &must; be shipped as Java bytecode (*.class - files, packaged in a *.jar 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;. - - - - 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. - - - - Programs and libraries &should; enable unit tests, if these are present. - The build &may; ignore test failures. - - - - Virtual machines - - - 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. - - - - They &should; use /etc/alternatives - for the name 'java' if they are command-line compatible with the - Oracle's java program. - - - - They &should; have a CLASSPATH predefined which include the needed - runtime environment. - - - - If a given source (like the JDK does) brings both a compiler and a - virtual machine, you &may; name the compiler package xxxx-dev. - - - - 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 /usr/lib/jni in its - search path for these dynamic libraries. - - - - - Building Java packages - - - 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. - - - - Packages must be built with &d-jdk;. This package provides a dependency - on the recommended Java Development Kit. If needed, the right - JAVA_HOME is - /usr/lib/jvm/default-java/ - - - - The javahelper package - provides helper to build either with CDBS or dh. They are strongly - recommended for Java packaging. - - - - For Maven based packages, the usage of maven-debian-helper - is recommended. - - - - - Java programs - - - Programs &must; have one or more executables in one or more of - the directories defined by - 9.1 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 - Policy 10.9), for - instance CLASSPATH. They &must; respect the Policy rules for - executables (for instance a manual page per executable, see - - Policy 13.1). - - - - 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. - - - - 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>. - - - - Programs &must; depend on the needed runtime environment (&d-jre; or - &d-jre-h; if need a GUI or not, and java<N>-runtime - or java<N>-runtime-headless as provided - by alternative Java environments). - - - - There is no naming rules for programs, they are ordinary programs, - from the user point of view. - - - - - Java libraries - - - Libraries are not separated between developers (-dev) and users - versions, since this is meaningless in Java. - - - - Libraries &must; not depend on a Java runtime. - - - - 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. - - - - Their classes &must; be in jar archive(s) in - the directory /usr/share/java, with the name - packagename[-extraname]-fullversion.jar. - 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. - - - - Some package &must; also provide a symbolic link from - packagename-extraname.jar to the most compatible - version of the available - packagename-extraname-version.jar files. - - - - Class files in a Java library &must; be built with debug symbols. - - - - All jar files &must; have a well-documented CLASSPATH, so - that developers should know what to add to their wrappers. - - - - This applies only to libraries, not to the core - classes provided by a the runtime environment. - - - - 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. - - - - If a Java library relies on native code, the dynamic libraries - containing this compiled native code &should; be installed into - the directory /usr/lib/jni. 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. - - - - 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. - - - - 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 - /usr/share/doc/<package>/api/ or - /usr/share/doc/<package>/api-<component>/. - - - - The API &must; be placed in a separate doc package. This package - &must; recommend the doc packages it was linked against. - - - - - Native Java Bytecode (gcj packages) - - - Java bytecode compiled into native code is referred to as - gcj-code and packages containing gcj-code as gcj-packages. - - - - 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. - - - - 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. - - - - 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. - - - - 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. - - - - The gcj-code &must; be installed in /usr/lib/gcj/ - and shipped separately from the original jar file. The gcj-package - &must; also install the classmap file generated by aot-compile in - /usr/share/gcj/classmap.d/. - - - - The gcj-package &must; call rebuild-gcj-db in the postinst and - postrm script, if rebuild-gcj-db is present. - - - - 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. - - - - - - Main, contrib or non-free - - - 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: - - - - - - 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. - - - - - - - - - Issues to discuss - - - The following points are discussions about the policy, either - because they have to be studied more, or are controversial. - - - - - Name and existence of the repository. It was removed - in the latest version. - - - - - - Minimal version of the class version files (50 for Java 6, 51 for Java 7, etc) - - - - - - The symbolic links in /usr/share/java be - made by a script instead, similar to the c-libraries. - - - - - - Core classes (java.*). More study - needed. - - - - 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. - - It should exist some tool to parse this. How should it work? - - Should the tool also be used to create the necessary symbolic - links needed by servlets under tomcat? - - - - - - 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? - - - - - How to check for a good enough &JVM;, and to select a - proper one to use. Are /etc/alternatives - not good enough? - - - - - - Should the &JVM; internal classes be possible to - override entirely and how? - - - - - - - Advices to Java packagers - - - Warning: These are just advices, they are not part of the policy. - - - - - - Be sure to manage all dependencies by hand in - debian/control. 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). - - - - - - Many calls in debian/rules can be removed - which are meaningless for Java, like dh_strip and dh_shlibdeps. - - - - - - Source package handling is painful, since most Java - upstream programs come with .class files. I - suggest to make a new .orig tarball after - cleaning them, otherwise, dpkg-source will complain. - - - - - - Java properties files are probably better under - /etc and flagged as configuration files (this - will be integrated in the policy, one day). - - - - - - - -- cgit v1.2.3