Forum libero

Scritto da: ::1
> Scritto da:
> >
> > Io ho un'idea migliore... buttiamo nel cesso le tecnologie che nel tempo hanno più e più volte dimostrato di essere insicure. Chiaramente la JavaVM è un colabrodo, lo dimostra la quantità di falle scoperte e sfruttate negli anni. O buttano via tutto e ricominciano da capo, stavolta tenendo in buon conto la sicurezza di ciò che scrivono, oppure è meglio farne a meno.
>
> Java client-side è implementato male secondo me. Basterebbe una libreria specifica per windows che lavora via jni ma permette di gestire la gui usando le primitive win32; andrebbe integrata nella jvm client per windows però.

Se vuoi fare una jvm portabile non puoi basarti sulle primitive win32 per la gui, oppure avresti risultati diversi su piattaforme diverse. Il problema è che chi programma in C/C++ non si rende conto di quanto sia facile creare bug con quello specifico linguaggio... oppure non gli importa. In C++ un po' si corre ai ripari con la loro libreria standard che mette a disposizione strutture dati sicure... ma nessuno ti obbliga ad usarle e molti pensano di essere più furbi di chi le ha scritte reinventandosi strutture dati già esistenti che hanno il forte svantaggio di non essere verificate da nessuno o di essere "resource save" (ovvero di liberare tutte le risorse quando quella struttura dati è distrutta).

Questo genere di problemi lo vedi quasi ovunque si usino linguaggi che permettono l'aritmetica dei puntatori. Per diventare programmatori non serve nessuna laurea, però questo ha messo sul mercato un sacco di persone che quando creano qualcosa pensano prima di tutto all'obiettivo immediato e solo dopo, quando di solito è troppo tardi, all'aspetto sicurezza... anche perché, da un punto di vista commerciale, la sicurezza costa tanto e i clienti/datori di lavoro propensi a pagarti ore e ore di lavoro in più per un qualcosa che il cliente nemmeno vede e tocca sono pochi.

Probabilmente gli svariati bug della JVM si trascinano avanti dalle sue origini, quando era un piccolo progettino poco conosciuto/usato della SUN. Sarebbe il caso di reimplementare tutto (magari nel contempo dare un po' una revisionata anche al linguaggio che è davvero troppo verboso per essere piacevole da usare) tenendo però in conto la sicurezza come parametro fondamentale, magari anche assumendo chi si occupa di scovare bug che ha una buona esperienza nel riconoscere pattern pericolosi per fare i test prima di rilasciare qualsiasi pezzo di codice in più (o in meno).

Questo sicuramente non elimina la possibilità di bug, ma ne potrebbe impedire parecchi o per lo meno limitarne i danni. Sarebbe anche una buona idea implementare un update automatico e non disabilitabile dall'utente se non dopo enormi sbattimenti che sia in grado di sostituire solo le parti affette dal problema senza costringerti a reinstallare tutto da capo. Inoltre dovrebbero smetterla di rompere le cose negli update successivi... c'è molta gente che ha ancora Java 6 perché se aggiorna a Java 7 o Java 8 rompe dei programmi per loro fondamentali che non possono sostituire o aggiornare velocemente.

Prendi ad esempio il Framework .NET di Microsoft. Anche quello ha bug, ecc. Però gli update sono automatici e sostituiscono i singoli assembly buggati e sono imposti da Windows Updater (l'utente nemmeno se ne rende conto). Solo i cambi primari di versione (cioè ad esempio passare dal 3 al 4) richiedono una installazione della nuova versione (e di questo spesso se ne occupano gli installer dei singoli programmi).

Inoltre le varie versioni del Framework continuano a convivere fra loro tranquillamente, così un programma scritto per il Framework 2.0 funzionerà anche se hai installato l'ultima versione del Framework 4.5 e non ci sono aggiornamenti che rompono programmi che prima erano perfettamente funzionanti. Anche in Java puoi installare ad esempio la versione 6 e la versione 7 contemporaneamente... peccato che poi devi stare a sbatterti a modificare le variabili di ambiente dei singoli programmi per andare a pescare la versione adatta per loro e mi è capitato che ci fossero rogne persino installando Java 7 32 bit assieme a Java 7 64 bit (un programma richiedeva la 32 bit, l'altro la 64) dove l'updater si era messo ad aggiornare solo l'ultima installata ignorando completamente l'altra.