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