<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2017-07-19 21:29 GMT+02:00 Diego Roversi <span dir="ltr"><<a href="mailto:diegor@tiscali.it" target="_blank">diegor@tiscali.it</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> Bytecode è una via di mezzo, è un linguaggio "macchina" quindi compilato<br>
> per la jvm (che lo interpreta e lo traduce in istruzioni native per<br>
> l'architettura sulla quale lavora). Quindi è uno pseduo linugaggio<br>
> compilato che poi viene re-interpretato da altro (jvm).<br>
<br>
</span>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.<br></blockquote><div><br></div><div>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). <br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> Non conosco la reflection in particolare che ho letto or ora e boh, pare<br>
> si possa fare in maniera simile anche in c++ con questo<br>
> <a href="http://www.ischo.com/xrtti/" rel="noreferrer" target="_blank">http://www.ischo.com/xrtti/</a><br>
<br>
</span>Non e' la stessa cosa, anche se ci assomiglia. </blockquote><div><br></div><div>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.<br></div><div></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> Il concetto è che in java hai molti vincoli che hai con i linguaggi<br>
> compilati (dichiarazioni delle variabili, tipizzazione,....). Roba che<br>
> con un python non hai e sei mooooolto più flessibile<br></span></blockquote><div><br></div><div>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.<br><br></div><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
</span>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.<br></blockquote><div><br></div><div>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.<br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-">> Il concetto che volevo esprimere era che java si pone nel mezzo tra un<br>
> interpretato e un compilato e prende (a mio parere == mia opinione)<br>
> aspetti negativi da entrambi<br></span></blockquote><div><br></div><div>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.<br></div><div><br>Infatti il futuro sono i linguaggi che uniscono AOT con GC (vedi Go e Rust). <br></div><div><br></div><br><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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 :)<br>
<span class="gmail-"><br>
> > Tolto questo, il problema sono le jvm e gli update di oracle (eh sì<br>
> > perchè icedtea NON è uguale alla oracle jre e un sacco di cose non ci<br>
> > girano).<br>
<br>
</span>E va beh. Se non sai le cose javose sappile!<br>
<br>
Iced Tea != jvm<br>
<br>
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.<br></blockquote><div><br></div><div>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).<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
</span>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.<br>
<span class="gmail-"><br></span><span class="gmail-"><br>
> > Ti costringono ad aggiornare java<br>
> > Nessuno ti costringe a fare proprio niente.<br>
><br>
> Ehm... permettimi di dissentire. Se rilasci una nuova applicazione che è<br>
> compatibile con java >=1.8 e io ho java 1.6 perchè un'altra applicazione<br>
> usava quello, tu mi costringi ad aggiornare.<br></span></blockquote><div><br></div><div>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...<br> <span class="gmail-"></span><br><span class="gmail-"></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">> Questo provato sulla pelle di molti clienti<br>
><br>
> jre 1.6.26 -> jre 1.6.29<br>
> A bit of research shows that it looks like Oracle made some change in<br>
> their API that affects our SSL socket read handling, hence failure to<br>
> authenticate. The changes were made not only in Java 6 Update 29<br>
> (1.6.29), but also in Java 7 Update 1 (7.0.1).<br>
><br>
> <a href="http://www.backupcentral.com/forum/8/219919/nmc_wont_accept_password_after_java_update" rel="noreferrer" target="_blank">http://www.backupcentral.com/<wbr>forum/8/219919/nmc_wont_<wbr>accept_password_after_java_<wbr>update</a><br>
<br>
</span>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.<br>
<br>
Comunque nota nei commenti, la gente che dice: "basta installare in parallelo la vecchia versione e tutto funziona". :)<br></blockquote><div><br></div><div>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.<br><br><a href="http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7103725">http://bugs.java.com/bugdatabase/view_bug.do?bug_id=7103725</a><br><br></div><div>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...<br>L'importante e' sempre "choose the right tool for the job". <br></div><div><br></div></div>Tri<br></div></div>