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

Pietro "m0nt0" Montorfano monto84@gmail.com
Mer 19 Lug 2017 16:57:00 CEST


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


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>>:
> 
>     [OT flammoso su java]
> 
> 
> Benissimo, ma se flammi, fallo portando esempi veri, non FUD.
>  
> 
>     Adesso, java a livello concettuale non mi piace, 
> 
> 
> E ci sta
>  
> 
>     pseudocodice, 
> 
> 
> Cosa vuol dire ?

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).
>  
> 
>     velocità di un interpretato 
> 
> 
> Falso.

Hai ragione, ma comunque non è e non sarà mai veloce ed efficente come
un linguaggio compilato nativo (c, c++ e compagnia), solo per il fatto
che esiste la jvm ci perdi. Poi si può discutere di come l'hw attuale
sopperisca più che egregiamente a questo, ma non coglie il fatto che non
possa rendere come un compilato.

>     ma leggibilità e flessibilità di un compilato....
> 
> 
> Trovami un compilato che fa reflection come Java

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

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

> 
>     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). 
> 
> 
> Il delta è sempre più ridotto. Le ultime OpenJDK 8 sono molto vicine
> (mancano alcune cose della client JVM e Flight Recorder).

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.

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.

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

>     MA la nuova versione cambia
>     il funzionamento di alcune funzioni o le rimuove. E no, non stiamo
>     parlando di major release (1.6 to 1.7 ad esempio), parliamo anche di
>     semplici patch e questo fa funzionare i programmi dando risposte
>     inconsistenti.
> 
> 
> Prove ? Come in tutti i bugfix ci possono essere dei side-effect, ma
> questo vale per qualsiasi altro software. Se la applicazione Java è
> scritta coi piedi, non è colpa di Java.

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

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.
Questo perchè nelle intenzioni è una buona cosa "write once runs
everywhere" ma nella pratica non è così.


Comunque era un palese flame dichiarato come dire che "kakka di e" non è
un bel desktop.... ma qui sarebbe lunga... (va che scherzo eh).

Ciao!

Pietro


Maggiori informazioni sulla lista gl-como