Accorgimenti in JVM per uso di software basato su java

Questo articolo si riferisce al software dell’Agenzia delle Entrate/SO.GE.I. le cui guide per l’uso con GNU/Linux sono riportate qui:
Unico SP 2007
Moduli di controllo sogei
Registrazione telematica contratti di locazione
Attribuzione Partita IVA soggetti diversi da persone fisiche
Attribuzione Partita IVA persone fisiche
Variazione Partita IVA soggetti diversi da persone fisiche
Variazione Partita IVA persone fisiche
Cessazione Partita IVA
FileInternet Fisconline
Unico PF 2007
Entratel
F24Intermediari
F24Online
Gerico 2007
.

Prima di continuare la lettura si prega di prendere conoscenza delle CONDIZIONI DI UTILIZZO ed accettarle.
.

NOTE SULLA JAVA VM DELLA SERIE 1.3.x

SCARICAMENTO E INSTALLAZIONE
Ciascuno dei programmi elencati dipende da Java per il suo funzionamento. Essi utilizzano di regola lo stesso numero di versione (vecchia, 1.3.1-13, e non proprio portentosa) della macchina virtuale java della SUN di altre applicazioni AdE/SO.GE.I. per windows.
La macchina virtuale java per GNU/Linux in versione 1.3.1_13 potete trovarla sul sito dell’Agenzia delle Entrate, p.es. qui
Il binario eseguibile si chiama j2re_linux.bin.

In considerazione, però, del fatto che quella macchina java risale a diversi anni fa e vi sono non pochi bug, consiglio di NON installare la 1.3.1-13, ma l’ultima java della serie 1.3.x prodotta dalla Sun, ovvero la 1.3.1-20, compatibile con la precedente ma mediamente più sicura, scaricabile sul sito di Sun, a partire da qui, premendo su JRE download in corrispondenza della riga Windows/Linux/Solaris SPARC/Solaris x86, accettando la licenza sul sito e scegliendo poi Linux platform – self-extracting file – j2re-1_3_1_20-linux-i586.bin

Se la macchina virtuale java non è già stata installata in occasione di precedenti installazioni di programmi Agenzia delle Entrate/SO.GE.I. provvediamo a farlo ora:
Muoviamoci nella directory /opt. Dopo averlo reso eseguibile, avviamo il programma j2re-1_3_1_20-linux-i586.bin e accettiamo la licenza. Verranno scompattati i file della macchina virtuale java in una sotto-directory di nome /opt/jre1.3.1_20.
N.B. Attenzione perché il programma non chiederà dove scompattare il suo contenuto, ma lo scompatterà nella directory corrente.
.
.
CARATTERI
E’ molto probabile, o almeno è quello che è capitato a me, che i caratteri usati dalla macchina java 1.3.1_20 siano di dimensioni inadeguate o brutti e rendano difficoltosa quindi la visualizzazione di diverse parole nel programma.
Ci sono tre possibilità:

A) (preferibile) Se si dispone di un’installazione di Java della serie 1.5.x, copiare, coi privilegi di root, se necessario sovrascrivendoli, i font, dalla directory in cui è installata una java jre della serie 1.5.x o 1.6.x (probabilmente /opt/java/jre/lib/fonts, /opt/jre1.5.0_XX/lib/fonts, /opt/jre1.6.0/lib/fonts o /usr/lib/jre/lib/fonts, ecc… a seconda del tipo di installazione), alla directory /opt/jre1.3.1_20/lib/fonts
I font che servono a java sono (solo) questi:

LucidaBrightItalic.ttf
LucidaSansRegular.ttf
LucidaBrightDemiBold.ttf
LucidaBrightRegular.ttf
LucidaTypewriterBold.ttf
LucidaBrightDemiItalic.ttf
LucidaSansDemiBold.ttf
LucidaTypewriterRegular.ttf

.
oppure B) Cancellare completamente tutto quanto è contenuto nella directory /opt/jre1.3.1_20/lib/fonts. In tal caso dovrebbero essere utilizzati i set di caratteri di sistema, più piacevoli alla vista (ma purtroppo non è detto). Si consiglia a questo proposito di installare nel sistema e far utilizzare dal sottosistema grafico Xorg (fare riferimento alla propria distribuzione per il come) pacchetti come mscorefonts o liberation di Red-Hat

oppure C) Se le altre possibilità non funzionano è consigliabile copiare anche altri font TrueType, dalla directory in cui sono installati (probabilmente /usr/share/fonts/TTF, /usr/share/fonts/Truetype, /usr/lib/X11/lib/fonts/TTF, o /usr/lib/X11/lib/fonts/Truetype, ecc…, a seconda del tipo di installazione), alla directory /opt/jre1.3.1_20/lib/fonts
Su Windows p.es. viene normalmente utilizzato il font LucidaSansRegular.ttf.
Inoltre è necessario ricostruire i file fonts.scale e fonts.dir, con i comandi mkfontscale e mkfontdir all’interno della directory in cui sono stati copiati i nuovi caratteri.
.
Si consiglia, in ogni caso, una volta avviati i programmi fiscali e se questi lo permettono nel menu, di selezionare il tipo di carattere e la dimensione, secondo le preferenze (probabilmente è meglio evitare il grassetto, tranne per i bottoni, e mantenere una dimensione di 10-12).
P.S. Per una minuziosa gestione dei caratteri da parte di java può essere necessario modificare il file /opt/jre1.3.1_20/lib/font.properties indicando i set di caratteri che si vogliono usare e gli eventuali alias; alcune istruzioni (in inglese) sono riportate qui. La modifica non è comunque immediata né indispensabile.
.
.
LIBRERIE CONDIVISE
Come già detto la macchina java in versione 1.3.1_20, l’ultima della serie 1.3.x usata dall’Agenzia delle Entrate, è piuttosto datata; essa si basa su librerie c++ di sistema (libstdc++-libc6.1-1.so.2) che erano in uso al momento in cui venne prodotta (credo ai tempi della Redhat 6.2) e che normalmente non sono più disponibili sui moderni sistemi GNU/Linux.
Avviando l’applicazione, infatti, questa si rifiuterà di partire dando questo errore:

/opt/jre1.3.1_20/bin/i386/native_threads/java: error while loading shared libraries: libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or directory

Dobbiamo quindi procurarci queste librerie datate. Andiamo su rpmfind.net e ricerchiamo dove è contenuta questa libreria; personalmente consiglio di scaricare questa libreria per Fedora Core 5 (compat-libstdc++-296-2.96-135.i386.rpm); ma dovrebbe andar bene qualsiasi pacchetto con il medesimo contenuto (es. cxxlibs della Slackware 8.1, 9.0, 9.1, 10.0, 10.1, 10.2 o 11, ma NON oltre).

Anche se si dispone della distribuzione per cui il pacchetto fu creato, sconsiglio nella maniera più assoluta di installare così com’è il pacchetto .rpm o .tgz scaricato, onde evitare confusione con i pacchetti installati della propria distribuzione ed eventuali malfunzionamenti sicuri dovuti a sovrascrittura di importanti file di sistema.

L’obiettivo è invece quello di scompattare il contenuto del pacchetto in una directory provvisoria (es. $HOME/tmp) e prendere i file che servono.
Vi sono molti modi per farlo, a seconda degli strumenti offerti dalla distribuzione in uso e delle preferenze:
*) rpm2targz nomepacchetto.rpm ; tar xvzf nomepacchetto.tar.gz (se c’è il comando rpm2targz)
*) tar xvzf nomepacchetto.tgz (se è un pacchetto .tgz di Slackware)
*) rpmextract.sh nomepacchetto.rpm (per es. per ArchLinux)
*) rpm -ivh --nodeps --relocate /=$HOME/tmp/ --root=$HOME/tmp/ nomepacchetto.rpm (per le distribuzioni basate su .RPM)
*) alien -t nomepacchetto.rpm ; tar xvzf nomepacchetto.tgz (per le distribuzioni che dispongono del pacchetto alien)
*) altre possibilità sono quelle di usare:
rpmunpack nomepacchetto.rpm ; gunzip nomepacchetto.cpio.gz ; cpio -i nomepacchetto.cpio
oppure rpm2cpio ecc… e cpio ecc…

In tutti i casi, dopo lo scompattamento, si dovrebbero avere alcuni file nella sotto-directory $HOME/tmp/usr/lib/, precisamente:
libstdc++-2-libc6.1-1-2.9.0.so
libstdc++-3-libc6.2-2-2.10.0.so
libstdc++-libc6.2-2.so.3 (link simbolico a libstdc++-3-libc6.2-2-2.10.0.so)
Quello che interessa a noi, per far funzionare la vecchia java, è il primo. La soluzione più immediata è questa: assumendo i privilegi di root, copiamo quindi libstdc++-2-libc6.1-1-2.9.0.so in /opt/jre1.3.1_20; creiamo un link simbolico alla libreria richiesta

ln -s /opt/jre1.3.1_20/libstdc++-2-libc6.1-1-2.9.0.so /opt/jre1.3.1_20/libstdc++-libc6.1-1.so.2

poi diamo un ldconfig.

Può essere utile dare uno sguardo anche alle note di installazione di java 1.3.x per GNU/Linux sul sito di Sun
.
.
EVENTUALI PROBLEMATICHE
A) Può accadere che lo script che avvia un programma basato su java vada in crash prima dell’avvio dando un “Segmentation Fault”; il fatto può essere dovuto a molti motivi, tra cui quello che la serie java 1.3.x non è più regolarmente mantenuta dalla Sun. Normalmente è sufficiente riavviare il programma e l’errore non si dovrebbe più ripresentare.

B) Può accadere che gli script di avvio di un programma basato su java diano avvertimenti sulla mancanza di set di caratteri (font); se la visualizzazione successiva del testo non presenta problemi l’avvertimento può essere senza problemi ignorato.

C) Nella schermata del programma di installazione LaunchAnywhere richiamato da uno script relativo ai programmi basati su Java, prima del completamento dell’installazione stessa, l’utente sarà avvertito del fatto che l’installazione è completata ma si sono verificati degli errori gravi. L’avvertimento dipende dal fatto che non si riesce ad installare alcuni file concepiti per Windows; pertanto può normalmente essere ignorato (sebbene vi siano ancora dei problemi irrisolti per taluni programmi, segnalati nelle guide relative).

D) Può accadere che all’avvio di uno script che richiama la macchina virtuale java appaia questo errore, per la quantità della memoria di stack non è sufficiente per l’esecuzione del programma:
Fatal: Stack size too small. Use ‘ulimit -s’ to increase default stack size
… Abortito (Aborted) …
In tal caso basta eseguire, dalla riga di comando:
ulimit -s

E) Nel caso in cui si esegua un programma java da parte di un utente diverso da quello, originario, che ha avviato il server grafico X (Xorg/X11), può succedere che appaia il seguente errore (per la verità molto criptico e per niente esplicativo):
No protocol specified
Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)

Stack Trace:
java.lang.NoClassDefFoundError
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:115)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:53)
at java.awt.Window.(Window.java:183)
at java.awt.Frame.(Frame.java:310)
at java.awt.Frame.(Frame.java:257)
at com.zerog.ia.installer.LifeCycleManager.g(DashoA8113)
at com.zerog.ia.installer.LifeCycleManager.h(DashoA8113)
at com.zerog.ia.installer.LifeCycleManager.a(DashoA8113)
at com.zerog.ia.installer.Main.main(DashoA8113)
at java.lang.reflect.Method.invoke(Native Method)
at com.zerog.lax.LAX.launch(DashoA8113)
at com.zerog.lax.LAX.main(DashoA8113)
This Application has Unexpectedly Quit: Invocation of this Java Application has caused an InvocationTargetException. This application will now exit. (LAX)

Questo è dovuto al fatto che l’utente in uso per ragioni di sicurezza non è autorizzato ad accedere alle risorse grafiche di X. In tal caso è necessario che l’utente originario conceda il permesso all’altro: normalmente il comando più utilizzato è:
xhost +local:
.
.
.

NOTE SULLA JAVA VM DELLA SERIE 1.5.x

Nel caso in cui il programma possa funzionare anche con una macchina virtuale java della serie 1.5.x (non tutti i programmi sono del tutto compatibili) essa è scaricabile dal sito di Sun a partire da qui, scegliendo l’ultima java JRE della serie 5.0 [al momento Java Runtime Environment (JRE) 5.0 Update 15] premendo su download; in seguito accettare la licenza sul sito e scegliendo poi Linux platform – self-extracting file – jre-1_5_0_15-linux-i586.bin

Se la macchina virtuale java non è già stata installata in occasione di precedenti installazioni di programmi Agenzia delle Entrate/SO.GE.I. provvediamo a farlo ora:
Muoviamoci nella directory /opt. Dopo averlo reso eseguibile, avviamo il programma jre-1_5_0_15-linux-i586.bin e accettiamo la licenza. Verranno scompattati i file della macchina virtuale java in una sotto-directory di nome /opt/jre1.5.0_15.
N.B. Attenzione perché il programma non chiederà dove scompattare il suo contenuto, ma lo scompatterà nella directory corrente.

Nota: La java della serie 1.5.x può convivere comodamente a fianco della serie 1.3.x
Per la serie 1.5.x NON sono necessari gli accorgimenti riportati sopra per la java 1.3.x
Se la java 1.5.x era installata precedentemente ed è stata aggiornata, ricordarsi di cambiare il riferimento negli script delle guide alla directory della nuova versione.