[gl-como] OT Java (was: perdita di supporto per macchine a 32 bit)

[Diego Roversi]

On Wed, 19 Jul 2017 16:57:00 +0200
"Pietro \"m0nt0\" Montorfano" <monto84@gmail.com> wrote:

> Ammetto di essere partito sul flammoso e l'ho anche scritto, volevo
> essere un po' flammoso a caso, comunque ti argomento meglio i punti,
> chiedo scusa del top post, ma almeno rispondo ai vari pezzi :D
> 

Non e' mica top posting, questo. Direi che e' questo:

https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

Che mi pare giusto e sacrosanto (e se vuoi partiamo con un nuovo flame su come si quotano le mail :P)


> On 14/07/2017 18:14, Tristan Tarrant wrote:
> > 
> > 2017-07-14 18:02 GMT+02:00 Pietro "m0nt0" Montorfano <monto84@gmail.com
> > <mailto:monto84@gmail.com>>:
> 
> Bytecode è una via di mezzo, è un linguaggio "macchina" quindi compilato
> per la jvm (che lo interpreta e lo traduce in istruzioni native per
> l'architettura sulla quale lavora). Quindi è uno pseduo linugaggio
> compilato che poi viene re-interpretato da altro (jvm).

Ma non funziona cosi'. Il bytecode poi viene trasformato in codice nativo, la stessa cosa che fa poi il compilatore C. Anche il gcc, prende il codice C, lo trasforma in una cosa intermedia, che poi diventa codice nativo. La differenza e' che il compilatore C dovendolo fare una volta sola, se anche impiega qualche minuto non si fa problemi, la jvm se ci impiega piu' di qualche secondo non va bene. Risultato, il codice scritto in C e' 10-20% piu' veloce, grazie alle maggiori ottimizzazioni.

Che se non stai minando bitcoin, un po' chissene :)

PS: sto barando, perche' poi alcune cose in java sono molto piu' lente. Ma non c'entrano nulla con il codice compilato, quindi ne parlo piu' avanti.

> Non conosco la reflection in particolare che ho letto or ora e boh, pare
> si possa fare in maniera simile anche in c++ con questo
> http://www.ischo.com/xrtti/

Non e' la stessa cosa, anche se ci assomiglia. Un esempio carino e' jython. E' un interprete python scritto in java. Che detto cosi' magari non sembra molto utile, ma la cosa bella e' che puoi inserire tale interprete

> Il concetto è che in java hai molti vincoli che hai con i linguaggi
> compilati (dichiarazioni delle variabili, tipizzazione,....). Roba che
> con un python non hai e sei mooooolto più flessibile

Infatti, esistono "compilatori" anche per python (Pypy) ma che faticano ad avere le stesse prestazioni di java. Con il dynamic typing (non sai il tipo di variabile, finche non esegui il codice), rende estremamente difficile creare codice nativo ottimizzato.

> 
> Il concetto che volevo esprimere era che java si pone nel mezzo tra un
> interpretato e un compilato e prende (a mio parere == mia opinione)
> aspetti negativi da entrambi

Oppure i vantaggi di entrambi? Dipende se guardi se il bicchiere e' mezzo pieno o mezzo vuoto.

Ho programmato per svariati anni, e lungi da me dire che java e' meglio di altri linguaggi. Ma ha alcuni aspetti che in vari casi lo rendono preferibile sia a python che a C o C++.

Mia personalissima lista:

Svantaggi:
----------

1) librerie Orientate agli Oggetti, scritte da fanatici OOP. Risultato che sono flessibilissime, e puoi fare cose complicate, in modo poco complicato, e cose facili ... in modo poco complicato. Che diciamocelo: il 90% delle volte ci servono fare cose semplici, sarebbe meglio che si possano fare in modo facile...

2) garbage collection: e' un arma a doppio taglio. Da una parte e' molto piu' semplice scrivere codice, ed e' quasi impossibile avere memory leak (ma se ti ci metti di impegno...). Le performance ne risentono. Gli oggetti sono tutti dinamici, ed hanno un costo di creazione.

3) le api (vedi anche il punto 1) sono ad un livello di verbosita' medio-alto. Con gli anni e' migliorato, ma all'inizio leggere un file di testo richiedeva almeno una decina di righe codice e istanziare due classi. 

4) sempre parlando di verbosita', anche il linguaggio non scherza. Questo e' hello world in java:

public class HelloWorld {
    public static void main(String[] args) {
        // Prints "Hello, World" to the terminal window.
        System.out.println("Hello, World");
    }
}

Credo che solo il cobol, faccia di peggio, e potrebbe non essere un caso :P. Vuoi mettere con:

print("hello world!")

Vantaggi:
---------

1) portabilita'. Write once, run everywhere. A parte problemi con i nomi dei file, per il resto se scrivi codice normale, gira ovunque.

2) reflection + classloader, ti permette fare cose carine, compreso programmi java che caricano altro codice java. In C/C++ puoi farlo usando il dynamic linking, ma auguri e con mille limitazioni.

3) estremamente pignolo, e mille volte piu' semplice del C++. Che visti i programmatroti che ci sono in giro, ben venga. Se il codice poi e' piu' lento pazienza. Non e' che ora dobbiamo scrivere tutti in assembler, perche' cosi' il codice e' velocissimo.

Secondo me in ambito enterprise ha il suo perche'. Poi i vincoli da codice compilato, non sono solo per il compilatore, tieni conto che se devi scrivere applicazioni complesse, con molte persone che ci lavorano assieme, controllare se a un metodo passi un numero invece che una stringa e' tutto di guadagnato :)

> >     Tolto questo, il problema sono le jvm e gli update di oracle (eh sì
> >     perchè icedtea NON è uguale alla oracle jre e un sacco di cose non ci
> >     girano). 

E va beh. Se non sai le cose javose sappile!

Iced Tea != jvm

Iced tea e' la controparte di java web start di sun^Woracle. Serve semplicemente per scaricare un programma java dall'internet, ed eseguirlo con una jvm. Ma non e' la jvm.

> Premetto che faccio il sistemista e ho a che fare con applicazioni
> sviluppate da n persone di n aziende su n apparati in n versioni, quindi
> ne vedo tante sia di applicazioni che di versioni.

Come ti capisco, io sono passato da programmatore java a sistemista, e posso apprezzare meglio come di sovente vengano scritte con il fondoschiena le applicazioni.

> 
> Vero che sono simili ma simili non è uguali e, per quello che ci devo
> fare io, la icedtea non va bene. O usi la oracle jvm o non funzionano
> parti di programmi e parti di interfacce.

Volevi dire openjdk? O forse stai parlando di java web start?
 
> >     Ti costringono ad aggiornare java 
> > Nessuno ti costringe a fare proprio niente.
> 
> Ehm... permettimi di dissentire. Se rilasci una nuova applicazione che è
> compatibile con java >=1.8 e io ho java 1.6 perchè un'altra applicazione
> usava quello, tu mi costringi ad aggiornare. 

Permettimi di dissentire, ma io ho visto pc con installate n versioni di java, per n*m applicazioni, comprese differenze di minor release. E ogni applicazione poteva girare con qualsiasi versione installata (compresa una java web start ibm per la console delle lame che voleva la sua versione di java 1.6).

> Oltre a questo ci sono le
> innumerevoli patch di sicurezza (che ben vengano!!) e l'updater
> automatico che ti stressa. Se sei una persona giudiziosa aggiorni java,
> se sei un'azienda e non ti puoi permettere di giocare con le varie
> versioni di java, prima di aggiornarlo ti fai tutti gli scongiuri del caso.
> Come esperienza personale ti dico che da un cliente ci siamo trovati a
> fare una matrice per trovare quale java installare a livello di sistema
> per far funzionare in contemporanea 3 software.

Installa 3 jvm e sei a posto. Seriamente: la cosa e' ampiamente documentata e supportata. Se poi siete riusciti a usarne una sola tanto meglio.

> Questo provato sulla pelle di molti clienti
> 
> jre 1.6.26 -> jre 1.6.29
> A bit of research shows that it looks like Oracle made some change in
> their API that affects our SSL socket read handling, hence failure to
> authenticate. The changes were made not only in Java 6 Update 29
> (1.6.29), but also in Java 7 Update 1 (7.0.1).
> 
> http://www.backupcentral.com/forum/8/219919/nmc_wont_accept_password_after_java_update

Dato che non spiega veramente quale sia il problema, mi astengo dal commentare.  Sarei curioso di sapere quale sarebbe esattamente il cambiamento delle api incriminato.

Comunque nota nei commenti, la gente che dice: "basta installare in parallelo la vecchia versione e tutto funziona". :)


> Non a caso le aziende spesso includono la jvm sulla quale sviluppano nei
> loro programmi e usano quella in modo da slegarsi da tutto quello che
> può accadere su pc.

Guarda, mia esperenza personale. Ho visto mucchio di programmi java, a cui abbiamo aggiornato la java di major release sotto il culo e non hanno fatto una piega. In un caso contrario, in cui ero programmatore, il problema di incompatibilita' era dovuto ad un collega molto furbo che usava metodi non documentati (nota che devi cercarli con il lanternino, perche' appunto non sono documentati).

> Questo perchè nelle intenzioni è una buona cosa "write once runs
> everywhere" ma nella pratica non è così.

La mia esperienza che nella maggior parte dei casi e cosi'. Che e' sempre meglio del 0% di altre soluzioni. Vedi programmi per windows, che si portano dietro tutte le .dll del compilatore sempre. Perche' le dll sono nate apposta per caricarle una volta sola e tutti i programmi le condividono anche a livello di memoria, ma chissa' perche' poi molti programmi di terze parti, nel dubbio installano sempre tutto a parte :)

-- 
Diego Roversi <diegor@tiscali.it>