Questo documento è una introduzione al mondo di Java e HotJava incentrata su Linux. Queste tecnologie sono in rapida eoluzione, e accettiamo contribuzioni da chiunque.
Parti di questo documento che hanno seriamente bisogno di verifica o di completamento sono racchiuse da *** ***. Vedi inoltre più sotto la sezione Da Aggiungere .... Per favore aiutateci a migliorare questo HOWTO.
Inviate aggiornamenti e richieste di modifiche a Eric S. Raymond.
Aggiornamenti specifici alla versione Italiana possono essere inviati a Fabrizio Polacco.
Questa sezione è una introduzione generica (non specifica su Linux) a Java e HotJava.
Java è un linguaggio conscio della rete, che ricorda
superficialmente il C++, ma molto più piccolo e più compatto
e progettato in modo più pulito.
E` un linguaggio a raggio illimitato dotato di garbage collection
(raccolta dei rifiuti) come il Lisp, ma con il controllo statico sui
tipi (è stato correttamente descritto come uno 'Smalltalk con una
corretta sintassi').
Comprende gli thread (processi leggeri) come una capacità
nativa ed ha potenti caratteristiche per la sicurezza della rete.
HotJava è un browser per il WWW scritto in Java.
Il suo maggiore vantaggio sugli altri browser è dato dal suo
essere a conoscenza di un nuovo costrutto HTML chiamato un
APPLET,che consiste in qualche classe Java che viene eseguita
sulla macchina cliente.
Perciò, documenti WWW scritti pensando a Java possono incorporare
oggetti-codice 'vivi', invece di solo dati.
La capacità di mandare in giro intatti oggetti-codice rappresenta probabilmente il più significativo avanzamento nella tecnologia WWW fin dal primo rilascio di Mosaic. Come minimo, fornisce un browser Web che non necessita di perpetui aggiornamenti per gestire nuovi formati di immagine e nuovi tipi di tag.
Java viene compilato in uno pseudo-codice chiamato `J-code'; gli interpreti Java eseguono J-code. Lo J-code corre il rischio di diventare un codice-macchina virtuale universale indipendente dall'architettura o un linguaggio intermedio di compilazione. Vi sono voci che un compilatore ADA-95 che genera J-code sia già stato costruito e che un compilatore C sia in fase avanzata; eventualmente, è verosimile che linguaggi a facciata multipla saranno disponibili per scrivere, su una qualunque macchina dotata di interprete Java, sia applet che programmi completi.
Java e HotJava sono stati sviluppati presso la Sun Microsystems da un team diretto da James Gosling (ben noto come progettista di Gosling Emacs e di NeWS).
L'ultima volta che la Sun ha provato ad imporre uno standard
tecnico consistente è stato con NeWS, il suo Network Window System
(Sistema di Finestre in Rete). Benchè NeWS fosse quasi
universalmente considerato tecnicamente superiore a X, X vinse
perchè i suoi sorgenti erano liberamente ridistribuibili.
La Sun ha imparato da questo errore, e ha reso Java e HotJava
molto più generalmente disponibili; i sorgenti possono essere
recuperati sotto una licenza piuttosto rilassata (vedi
Java come Software Liberamente Ridistribuibile).
La Sun sta incoraggiando sbarchi in ambienti non-Sun.
Netscape ora interpreta Java. La Microsoft ha preso la licenza della tecnologia nel Dicembre 1995. Così sembra che il supporto per Java probabilmente diverrà universale nel 1996.
Java era stato chiamato Oak. HotJava era noto come WebRunner.
Il 12 Dicembre 1995 la Sun ha rilasciato la versione ''Beta 2'' di Java. Un mese più tardi ha rilasciato la 1.0, la prima versione di `produzione'. La API (l'interfaccia di programmazione) dell'ambiente Java che definiscono l'accesso al Sistema Operativo dell'host ed al sistema di visualizzazione (windowing) è stata dichiaratamente semi-congelata; può venire estesa, ma non sarà modificata in modo incompatibile.
La versione 1.0 di questo FAQ è stata pubblicata con la beta 1.0 del kit per sviluppatori Java (JDK) per Linux, portatovi da Randy Chapman.
Si sa che esistono buchi significativi nell'implementazione della sicurezza di Java. Non è ancora una buona idea quella di usare Java per applicazioni delicate. Si attendono soluzioni per questi problemi nelle release in produzione dopo la beta.
La Sun mantiene un esteso web HTML di documenti relativi a Java e HotJava su http://java.sun.com. Questi documenti sono replicati su http://java.blackdown.com ed altrove; vedi la lista della Sun dei siti speculari.
La serie ufficiale di libri su Java della SunSoft Press è in fase di realizzazione alla Addison-Wesley. Dettagli su questi si possono trovare nel FAQ del newsgroup comp.lang.java.
Parecchi utilizzatori di Java della prima ora hanno raccomandato ''Hooked on Java'' scritto da membri del team Java. ''Ben scritto, benchè avrei preferito qualcosa meno di base'' era un commento.
O'Reilly & Associates sta preparando la sua serie di libri su Java in cooperazione con la Sun. Sarà incluso (almeno) una ''Nutshell Guide To Java'' (Guida a Java in un guscio di noce: Le guide in un guscio di noce sono una serie di manuali UNIX di gran successo della OR&A. NdT), un manuale di riferimento al linguaggio, un manuale di riferimento alla libreria di classi, e un libro sulla macchina virtuale a byte-code. (Full-disclosure statement: Your HOWTO editor has been invited by O'Reilly Associates to serve as primary technical reviewer for this series, and is being paid for that work.) (Il curatore dell'HOWTO avverte di essere pagato dalla O'Reilly & Associates in qualità di principale revisore tecnico.)
SAMS ha un libro chiamato ''Learning Java in 21 Days'' (Imparare Java in 21 giorni). Non ho ancora recensioni.
Uno dei nostri contributori, spulciando un catalogo locale, ha trovato 3 libri già pubblicati:
Il nostro informatore continua:
Ho comprato il terzo (quello di Tim Richey). Il CD-ROM contiene roba dalla versione alfa, benchè suggerisca che la versione beta dovrebbe essere pronta in quei tempi, ed indica java.sun.com come un buon posto dove trovare informazioni più recenti. A parte questo, è piuttosto buono, anche nel far notare che bene, è fuori luogo per me riempirvi di pagine e pagine di descrizione della API perchè 1) quadruplicherebbe le dimensioni del libro e 2) vengono continuamente modificate e 3) potete trovare queste informazioni on-line ... ecc.
Dave Dittrich scrive:
direi che 'Java in 60 minutes' potrà anche essere letto in 60 minuti, ma non vi insegnerà a programmare in Java in 60 minuti (sorpresa, sorpresa!). Mi sembra che ''Java in 60 minuti'' sia solo uno dei molti concorrenti alla corsa per essere per primi in libreria con un libro sull'argomento del momento. Non sembra di avere più di quanto si possa trovare sul Web, compreso un sacco di testo che sembra proprio tirato fuori dal Java Language Specification (http://java.sun.com/JDK-beta2/psfiles/javaspec.ps).
Continua Dave:
lo stesso per ''Java!'', solo che quest'ultimo entra molto più nei dettagli sui concetti della programmazione orientata agli oggetti, ecc. Qualcuno mi ha consigliato un'altro testo che ugualmente parla di astrazione di dati/metodi ed altri concetti della programmazione orientata agli oggetti, che è ''Structure and Interpretation of Computer Programs'' di Abelson, Sussman e Sussman (MIT Press).
Nota finale: a tutt'oggi (Gennaio 1996), è probabilmente una buona idea stare lontani dal libro di Ritchey e su ogni altra cosa basata sulla API alfa. La Api beta è sostanzialmente diversa, e la Java 1.0 in fase di realizzazione avrà le sue differenze.
Non ho notizia di libri o riviste originali italiani , mentre so di diverse traduzioni di libri americani:
NOTA: Poichè il vostro traduttore non vive in Italia, ha ovvie difficoltà a recarsi in libreria per reperire informazioni di prima mano. In questo ha estremo bisogno di aiuto da parte vostra: sono ben accetti elenchi di libri, riviste e recensioni. Contattate liberamente Fabrizio Polacco.
Archivi WWW di applet sono disponibili nelle seguenti locazioni:
Altri pagine verranno segnalate nel FAQ del newsgroup comp.lang.java.
Molti programmatori Linux sono impegnati nel produrre software liberamente ridistribuibile (FRS), e cercano di evitare di dedicare un mucchio di tempo a strumenti i cui sorgenti non siano generalmente disponibili. In questa sezione discutiamo il rapporto tra la Sun e Java ed il mondo FRS.
(Attenzione: non sono un avvocato. Non sono neppure impiegato, nè agente, nè distributore della Sun Microsystems. Questa sezione è basata sulla mia interpretazione delle attuali leggi sul copyright ed il linguaggio della licenza della Sun. Tenetela come una introduzione; la licenza della Sun, http://www.blackdown.org/Java/licensing.html, è definitiva. Se avete seri dubbi sul suo significato, consultate un avvocato.)
Lo sono se li scrivete voi e scegliete di renderli FRS attraverso qualche metodo (quale la licenza GPL, o una tipo-BSD, o dichiarandoli di pubblico dominio).
La pagina della licenza della Sun ha questo da dire:
Gli eseguibili binari non-modificati di Java e HotJava rilasciati possono essere ridistribuiti senza oneri sia in applicazioni commerciali che non-commerciali.Inoltre:
Società o individui che desiderino creare un nuovo sbarco del linguaggio Java in base a codesto contratto hanno il diritto di pubblicare su Internet gli eseguibili binari di questo sbarco per farli usare da altri, purchè questi eseguibili siano liberi da oneri e superino le suite di test pubblicamente disponibili. (Le suite di test saranno disponibili in qualche momento nella prima metà del 1996.) Le differenze -- con i sorgenti rilasciati (NdT) -- potranno essere pubblicate sul Web puchè il codice sorgente originale non venga pubblicato. Il codice sorgente di Java è ...Così se avete gli ese guibili funzionanti di Java o HotJava, potete darli ai vostri amici. O metterli in un CD-ROM. O qualunque altra cosa eccetto modificarli e chiamare ancora Java la versione modificata. (Questo è ragionevole. La Sun ovviamente non vuole restare senza risorse contro ''Cavalli di Troia'' che viaggino sotto la bandiera di Java.) Gli eseguibili binari sono FRS.
In base alla licenza della Sun, nulla di questi lo è. Ma ciò suona più severo di quanto sia. In pratica, ogniuno può ottenere i sorgenti di Java e HotJava per scopi educativi, di sbarco, e non-commerciali compilando una form sul Web che obbliga a non ridistribuire i sorgenti. Ed il contratto permette la ridistribuzione di differenze sui sorgenti.
La sola circostanza che vi richiede di firmare una licenza commerciale con la Sun e di pagar loro denaro è se volete usare i sorgenti in un prodotto commerciale. In particolare, per il modo in cui è scritto, è nella lettera e nello spirito del contratto che voi firmiate la licenza dei sorgenti della Sun per uso non-commerciale, arraffiate il sorgente, lo sbarchiate altrove e diate via gli eseguibili binari ottenuti come freeware completamente libero da ipoteche!
La Sun dice che il suo scopo primario nel mentenere tanto controllo quanto ne ha, è per impedire che il linguaggio muti in dialetti incompatibili. Il linguaggio della licenza lo sostiene: sembra essere stata progettata per permettere agli smanettoni di giocarci liberamente.
La pagina della licenza Sun dice:
Le specifiche per il Linguaggio Java w la Macchina Virtuale Java sono aperte (OPEN) e sono coperte da copyright dalla Sun Microsystems Inc.
Reimplementazioni del Compilatore java e dell'Interprete a Runtime di Java sono permesse senza necessità di licenza dalla Sun a patto che tali implementazioni siano create direttamente dalle specifiche pubblicate e senza l'uso diretto o indiretto dell'implementazione della Sun o altri diritti di proprietà intellettuale, inclusi i marchi commerciali.Così se volete fare lo sforzo di creare un clone FRS di Java partendo dalle specifiche pubblicate , la Sun non vi fermerà.
La gente alla Sun usa il termine ''rogue port'' (sbarco briccone) per implementazioni di Java che a) siano eseguite fuori dalla Sun, o b) non si basino su codice concesso in licenza dalla Sun (alcune volte il termine sembra avere uno dei significati, altre volte l'altro). Loro sembrano ritenere che già ne esistano, ma noi non sappiamo dove siano, nè se siano FRS. Sono piuttosto tranquilli sulla situazione.
La Sun ha una suite di validazione. Hanno detto che certificheranno qualunque sbarco che la superi.(non è noto se questa validazione sarà onerosa, ma la Sun dice per iscritto che la suite sarà ''pubblicamente disponibile'' nel 1996, il che almeno suggerisce che non sarà onerosa.) Sono pronti a certificare sbarchi bricconi, benchè apparentemente questo non sia ancora successo.
Esiste un clone del compilatore di Java in fase iniziale di sviluppo. E` chiamato guavac. Potete trovare più informazioni a http://http.cs.berkeley.edu/~engberg/guavac
Circolavano voci che il progetto GROW della Cygnus Software avesse piani per un interprete del byte-code Java da porre sotto GPL. Questo è falso; quello su cui stanno lavorando è un traslatore da Java a Scheme che non passi attraverso il J-code. Potete avere dettagli sul progetto GROW a http://www.cygnus.com/tiemann/grow/.
EriK Troan della Red Hat ed il vostro umile redattore stanno cercando di mettere insieme un gruppo di sviluppo per fare il resto del lavoro. Per il momento sembra che useremo guavac come compilatore, Erik preparerà la libreria di classi mentre il vostro umile redattore preparerà l'interprete di byte-code (se Cygnus non arriverà prima). Questo progetto era sperimentalmente denominato ''Mr. Coffee'', ma ora probabilmente sarà JOE (per Java Open to Everyone = Java Aperto a Tutti).
C'è una modalità GNU Emacs per editare Java. Potete ottenerlo da ftp://java.sun.com/pub/java/contrib/emacs. Notate: questa modalità presume stiate usando c++mode.el, e non funziona con cc-mode.el distribuito con Emacs 19.
Qui troverete la parte pratica di come far girare Java sul vostro Linux.
No, non ancora, ma aspettatevelo da un momento all'altro.
Guardate in ftp://java.blackdown.org/pub/Java/linux. Il più recente Java-per-Linux può essere scaricato da lì. Prima dovreste dare una scorsa a ftp://java.blackdown.org/pub/Java/linux/README.
I file di cui avrete bisogno sono linux.jdk-1.0-try1.common.tar.gz e uno tra linux.jdk-1.0-try3.static-motif-bin.tar.gz o linux.jdk-1.0-try3.shared-motif-bin.tar.gz, in base al fatto se avete le librerie shared di Motif sul vostro sistema.
Se avete il Linux di Red Hat o qualche altro sistema che parli RPM, potete installare la beta 1.0 da ftp://java.blackdown.org//pub/Linux/RPMS/i386/JDK-linux-common-1.0b-1.i386.rpm e ftp://java.blackdown.org//pub/Linux/RPMS/i386/JDK-linux-static-1.0b-1.i386.rpm o ftp://java.blackdown.org//pub/Linux/RPMS/i386/JDK-linux-shared-1.0b-1.i386.rpm.
Per gli Europei, il contenuto di ftp://java.blackdown.org/pub/Java/linux e ftp://java.blackdown.org/pub/Linux/RPMS/i386/JDK-linux* sono ora copiati nel Regno Unito in ftp://ftp.linux.org.uk/pub/linux/java. Che è zen.btc.uwe.ac.uk, in caso a qualcuno interessi. La copiatura avviene quotidianamente alle 6 del mattino (UT).
NdT: sarebbe necessario riportare qui i link a siti italiani o più vicini (network wise) ai vari provider italiani. Se ne siete a conoscenza potete riferirlo al traduttore .
Questo sbarco su Linux realizzato da Randy Chapman dai sorgenti Sun, è quello a cui facciamo riferimento in questo HOWTO come il JDK.
Di base, avete bisogno di un Linux basato su ELF. Non c'è supporto a.out, e, data la velocità con cui il mondo Linux sta passando a ELF, non ce ne sarà alcuno in futuro.
Avete bisogno del kernel 1.2.13 o successivo. Il kernel 1.2.12 e precedenti sembra abbiano un baco in getcwd(3) che ingabbia bin/javac perchè non controlla il valore ritornato da getcwd(3).
Avrete bisogno di questi pezzi:
Se non le avete, prelevate libc.5.2.18.bin.tar.gz da ftp://tsx-11.mit.edu/pub/linux/packages/GCC/. Scompattate e copiate i file dal sottodirettorio lib del più alto livello della gerarchia in /lib.
Se non avete una versione attuale di ld.so (o libdl.so.1.7.*) dovrete aggiornarla. ld.so.1.7.9 e .11 funzionano: la .10 e altre versioni precedenti no. Prelevate ld-so.1.7.14.tar.gz da ftp://ftp.ods.com/linux/; Scompattate ed eseguite instldso.sh che si trova nel più alto livello della gerarchia originata.
Troverete una Libreria Xpm funzionante in ftp://sunsite.unc.edu/pub/Linux/libs/X/libXpm.3.4f-ELF.tar.gz.
Sì, hai bisogno di Netscape. HotJava non è ancora disponibile per la release beta 1.0. Randy Chapman dice:
La Sun ha cambiato massicciamente l'interfaccia awt quando ha varato la beta JDK e non ha ancora convertito HotJava a ciò. Hanno promesso di farlo, e dovrebbe andare alla grande con Linux-JDK quando lo rilasceranno.Non è noto quando ciò avverrà.
Le versioni di Netscape a partire dalla 2.0b3 sono pronte per Java.
La trovate su ftp[1-7].netscape.com ( cioè ftp1.netscape.com,
ftp2.netscape.com, ecc)
La versione 2.0b4 vi permette di caricare gli applet con la URL file:,
la 2.0b3 no. Questo dovrebbe essere molto d'aiuto ai ragazzi con
macchine con poca memoria (perchè non serve far girare httpd).
La versione attuale è la 0.6.
Il file da prelevare è /2.0beta6/unix/netscape-v20b6a-export.i486-unknown-linux.tar.Z.
Notate che Netscape gira su un sistema a.out, cosi sarebbe, in teoria, possibile scrivere la vostra applicazione (o applet) Java, passarla a qualcun altro per la compilazione (come forse il Compilatore Pubblico Blackstar), e vedere l'output sul vostro sistema. Se volete di più, procuratevi un sistema ELF.
Assicuratevi che CLASSPATH non sia impostato prima di lanciare Netscape; sembra faccia cadere Netscape.
Netscape per Linux ha un pò di problemi noti. Non esegue suoni. Solo i display a 8-bit funzionano; 16bpp falliscono. La versione 2.0b3 occasionalmente produce un bus-error quando richiama il metodo dispose per i frame. Benchè sia altrimenti piuttosto robusto, l'applet 'Impressionism' di Gamelan è noto farlo fallire.
In questa sezione, raccogliamo ricette inviateci su come montare lo sbarco di Java creato da Randy Chapman su diverse attuali distribuzioni di Linux:
John Franks <john@math.nwu.edu> scrive che vi è riuscito con i seguenti passi:
Steve Greene <sgreene@access.digex.net> suggerisce i seguenti passi. Ho leggermente modificato la ricetta, per cui lamentatevi degli errori con me. Il 'JDK' cui si fa riferimento è lo sbarco del Java Developer's Kit di Chapman.
/pub/mirrors/redhat-2.1/updates/RPMS/ld.so-1.7.14-i386.rpm
So che è disponibile su ftp.pht.com, ftp.caldera.com. come
probabilmnte sugli altri siti speculari di Red Hat.
Arraffatelo ed eseguite `rpm -Uvh ld.so-1.7.14-1.i386.rpm'
sul vostro sistema.
Stefan Middendorf scrive: Unifix è una popolare versione di Linux in Tedesco. (Imitare, imitare! NdT) Esistono alcune distribuzioni basate su di esso: Linux Universe, venduto negli USA, Linux 4U, attualmente distribuito solo in Germania e Linux FT in Gran Bretagna. Si sa che questa ricetta funziona con Unifix 1.7, Linux 4U 1st Edition, Linux Universe 2nd Edition, e Linux FT 1.1.
PRG=`which $0` >/dev/null 2>&1
---
PRG=`type $0 | cut -d ' ' -f 3` >/dev/null 2>&1
Alternativamente alla modifica del PATH, Ralf Strobel suggerisce:
.java_wrapper e appletviewer
e i link @java, @javac, @javadoc, @javap, e
@jdb da /usr/local/java/bin a /usr/local/bin e li potrete
uasre ovunque vi troviate.
#!/bin/sh
`dirname $0`/java sun.tools.javadoc.Main -d <yourhtmldir> $
Per lanciare un demo senza passare per il visore degli applet, potete immettere questo comando stando in cima all'albero dei direttori Java (/usr/local/java su molti sistemi):
bin/java sun.applet.AppletViewer demo/<directory_name>/exampleN.html
dove <directory name> è il sottodirettorio del demo, ed N è numero del file di esempio (alcuni direttori ne hanno più d'uno).
Steve Greene dice: ho lanciati gli esempi disponibili nei siti Java della Sun e quelli simili messi in giro dal NTMUG. Ho trovato alcuni problemi con la sintassi negli esempi della Sun, così ho seguito il programma NYMUG invece.
appletviewer si aspettap per argomento un file html con un tag APPLET dentro.
Per esempio, mettiamo che il vostro file Hello.html contenga:
<HTML>
<HEAD>
<TITLE> Hello test program </TITLE>
</HEAD>
<BODY>
This is an appletviewer test
<APPLET CODE="Hello1.class" WIDTH=150 HEIGHT=25>
</APPLET>
</BODY>
</HTML>
Lanciando ''appletviewer Hello.html'' appare l'applet. Un vantaggio nell'usare appletviewer è che gli eventi passati all'applet ( start(), init() ecc) sono conformi con le specifiche della Sun all'opposto di Netscape 2.0b4 (probabilmente un baco in Netscape).
Uno svantaggio nell'usare appletviewer è che è molto più lento di Netscape.
La prima volte che lanciate Java, appare uno schermo con una licenza che ricorda quella di Netscape.
Versioni recenti di libc correggono un baco che nascondeva un errore in GNU Make (il sintomo è che make non cerca più le regole in Makefile). Le note alla release 5.2.8 di libc contengono un patch che corregge il problema.
La variabile CLASSPATH non è correttamente inizializzata. In .java_wrapper, c'è del codice simile a questo:
PRG=`which $0`
J_HOME=`dirname $PRG`/..
Sfortunatamente, il comando 'which' di linux è scorretto, e certe shell impostano $0 all'intero pathname. Randy Chapman dice di corregerlo sia usando:
J_HOME=`dirname $0`/..
che, in modo più sicuro:
J_HOME=/usr/local/java
Una correzione alternativa da Dave Dittrich è:
PRG=`csh -c "which $0"`
E un'altra da Tim Farnum è di cambiare la riga
PRG=`which $0` con:
PRG=$0
Lutz Behnke suggerisce:
PRG=`type -path $0` >/dev/null 2>&1
Un simile cambiamento deve essere fatto anche nello script appletviewer.
La variabile CLASSPATH non è correttamente inizializzata. Vedi sopra.
Da root eseguite chmod 666 /dev/zero.
Occasionalmente potreste trovarvi con lo schermo pieno di messaggi d'errore, e il sistema riempie allegramente la vostra area di swap e si blocca.
Probabilmente vi manca una libreria da qualche parte. Rilanciate ldconfig -v e guardate cosa manca. Forse LD_LIBRARY_PATH o CLASS_PATH non sono impostate. Infine, alcuni applet sono bacati o bloccano il JDK Linux.
(Ad ogni modo, potete fermare il blocco usando un'altra Xterm con top; usate top per killare il processo java prima che riempia la swap e che il sistema si blocchi!)
Java sembra richiedere un mucchio di risorse, così dovreste tenere il numero di applicazioni aperte nel desktop al minimo. Su un 486DX2/75 con 8MB di RAM e 16MB di swap sono in grado di lanciare due applet di animazione simultaneamente prima che il mio sistema riempia la swap e si impicchi. (ci mette un minuto, comunque).
avete dimenticato qualche parametro su una riga di comando.
Un errore comune che produce questo risultato consiste nello sbagliare il tipo MIME dell'applet. Il vostro server deve inviare un header con l'applet indicante che il tipo MIME è 'text/plain', 'application/octet-stream', o qualche altro tipo che non ha un gestore definito sul lato client. Come correggere questo dipende da quale server state usando. (John Franks)
E' stato inoltre riferito che tinyhttpd, un HTTP server scritto in Perl, fornisce un errato tipo di contenuto. Apache, invece, è piuttosto affidabile.
Joey Oravec ci dice che HotJava tiene traccia di ciò che fa e dei problemi che incontra. Se cercate di diagnosticare qualcosa da voi, guardate in $HOME/.hotjava/weblog. Quel file vi farà notare se forse vi manca una libreria o altro.
Per informazioni generiche su java, c'è il FAQ del newsgroup comp.lang.java; è disponibile su http://www.city-net.com/~krom/java-faq.html.
Esiste un più vecchio documento in stile FAQ di Joey Oravec joey@sun.science.wayne.edu che soprattutto si riferisce alla versione alfa. Lo trovate su http://www.science.wayne.edu/~joey/java/linux.html. Ad un perto punto questi documenti potrebbero fondersi.
Ecco alcune pagine relative a Java:
Un grazie a tutti i contributori, inclusi:
Questa versione incorpora il vociferato ma mai pubblicato mini-HOWTO Red Hat/Caldera di Steve Greene. Ho inoltre rubacchiato roba che trovavo utile dalla pagina di Joey Oravec -- un grazie speciale a lui.
Per gli altri HOWTO e FAQ che io curo, guardate la mia home page a http://www.locke.ccil.org/~esr/home.html.
Nota del Traduttore Questo documento viene continuamente aggiornato. Ad oggi, sono state rilasciate le seguenti versioni:
A questa versione in Italiano hanno contribuito (e qui si ringraziano caldamente):