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

Gio 20 Lug 2017 10:23:19 CEST

2017-07-19 21:29 GMT+02:00 Diego Roversi <diegor@tiscali.it>:

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

Dimentichi una cosa fondamentale: la trasformazione da bytecode a codice
macchina avviene tramite due compilatori interni alla JVM. Il primo si
chiama C1 (aka client compiler) ed e' veloce ma non particolarmente
intelligente. L'altro compilatore si chiama C2 (aka server compiler) ed
entra in azione dopo qualche migliaio di esecuzioni. C2 si avvantaggia
della profilazione dell'esecuzione per generare codice ottimale (anche GCC
ha una feature simile chiamata PGO).

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

Non sono neanche sullo stesso pianeta :) Con la reflection di Java posso
analizzare e manipolare qualsiasi classe a runtime, creare proxy di
invocazione che intercettano i metodi. E' grazie alla reflection che sono
possibili librerie come Hibernate.

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

Per scrivere 10 righe di codice, forse. Quando devi mantenere 1M-linee di
codice, diciamo che la tua flessibilita' si traduce in fragilita'.
Linguaggi diversi per scopi diversi.

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

Aggiungo che da Java 7 hanno aggiunto un bytecode chiamato invokedynamic
proprio per venire incontro al connubio del mondo dinamico e le necessita'
di un compilatore ottimizzante: utilizzando le informazioni  di
profilazione, i tipi che una variable possono assumere in un particolare
punto del codice diventano prevedibili e ottimizzabili.

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

I linguaggi fortemente tipizzati (Java, C++) rivelano la loro utilita'
quando il numero di linee di codice inizia a crescere: ti sfido a scrivere
e a mantenere un progetto Node.js da 100k-righe. Java sacrifica un po' di
performance (ma neanche poi tanta) rispetto ad un linguaggio con
compilatore AOT, ma il Garbage Collector garantisce una robustezza molto
superiore.

Infatti il futuro sono i linguaggi che uniscono AOT con GC (vedi Go e
Rust).

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

In realta' IcedTea e' un po' di piu', ma se parliamo di Java Web Start,
quello e' il male in generale. Java sta bene sul server, sul client in modo
indipendente (IntelliJ, Eclipse, etc), non cosi' tanto come modo di
distribuire applicazioni nel browser (Applet e Java Web Start).

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

Esattamente come con le n versioni di Python o con qualsiasi altro
linguaggio/interprete. Voglio ricordare G++ e il fatto che la ABI si
rompesse ad ogni minor release del compilatore/stdlib...

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

Come in tutte le cose, alcuni aggiornamenti possono causare problemi (vale
per qualsiasi libreria). In quel caso il bug e' stato risolto con la 1.6u30.

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7103725

Executive summary: ogni linguaggio/libreria/piattaforma ha i suoi aspetti
positivi e negativi. Se dobbiamo proprio scegliere roba da flammare
puntiamo su PHP: li' si' che c'e' da divertirsi...
L'importante e' sempre "choose the right tool for the job".

Tri
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.linux.it/pipermail/gl-como/attachments/20170720/46df4c81/attachment-0001.html>