Sun stucca alcuni buchi di Java

Rilasciata una versione aggiornata di Java Runtime Environment, che corregge alcune vulnerabilitÓ potenzialmente serie. All'orizzonte, intanto, si scorge giÓ Java 7

Roma - Nel diffusissimo software Java Runtime Environment (JRE) di Sun si celano alcune vulnerabilità che potrebbero consentire ad un aggressore remoto di eseguire del codice a propria scelta.

Come noto, JRE contiene la macchina virtuale Java (JVM) di Sun, e consente agli utenti di PC, Mac e altre piattaforme di eseguire le applicazioni Java in modo stand alone o all'interno di un browser. Le ultime patch rilasciate da Sun sono integrate in JRE 6 Update 13, e correggono sette diversi bug, tra i quali alcuni di rilevante impatto sulla sicurezza.

Oltre all'esecuzione di codice a distanza, alcune delle vulnerabilità corrette da Sun potrebbero essere sfruttate da malintenzionati per elevare i loro privilegi o lanciare attacchi di denial of service.
La mamma di Java ha anche distribuito una versione aggiornata di JRE 5 che include alcuni degli aggiornamenti di sicurezza introdotti in JRE 6 Update 13. Entrambe le versioni del software possono essere scaricate da questa pagina.

Negli scorsi giorni il progetto OpenJDK ha pubblicato una roadmap dello sviluppo di Java Development Kit for Java 7 (JDK 7), il cui rilascio è atteso per l'inizio del 2010. Stando alla tabellina di marcia, prima di questo traguardo verranno rilasciate altre sei milestone: la prossima, chiamata M3, dovrebbe arrivare entro i prossimi due mesi, e probabilmente poco prima della conferenza JavaOne di inizio giugno.
87 Commenti alla Notizia Sun stucca alcuni buchi di Java
Ordina
  • ciao, io mi ricordo la Java 350, che andava da Dio Sorride
    non+autenticato
  • verrà definitivamente spazzato via.
    non+autenticato
  • Uno degli aspetti criticati di Java, non è la lentezza ma come tale è scambiata. Si tratta del bootstrap. Dubito fortemente che py sia più veloce di j, ma è innegabile che uno script sia preferibile in py, semplicemente per i tempi di bootstrap.

    Una cosa che mi sarebbe piaciuta leggere nell'articolo, sono le novità di OpenJDK7. La IMHO più importante è che si sono ingegnati per risolvere la questione del bootstrap (sia come tempi che come RAM) inserendo un meccanismo di modularizzazione della JVM, tale per cui il bootstrap è velocissimo (non facendo in pratica nulla) e facendo un caricamento della JVM in lazy loading!
  • - Scritto da: Giambo
    > > che java fu ideato per creare le schermate
    > > merdose per i network televisivi
    >
    > Fonte ?

    me lo ha detto mio cugginoA bocca aperta
    cmq se ti interessa questa storia l'ha raccontata colui che ha inventato la VM.
    vatti a leggere le interviste passate e ne troverai delle belle.
    la Sun a quel periodo voleva entrare nel mondo della grafica in particolare quella 3d
    non ci riusci per via delle performance scadenti e la superiorità della SGI.
    per rimediare alla grassa figura di m...a raffazzonarono il tutto ci piazzarono un sistema a finestre scandaloso e cercarono di piazzarlo come il santo graal della programmazione.
    che poi abbia avuto successo in particolare in ambito server è un'altro discorso certo è che con le metologie odierne e la programmazione agile JAVA inizia a perdere colpi e questo non lo dico io lo dicono le statistiche.
    come linguaggio rimarra confinato dentro le banche per un altro pò di anni,poi anche li inizierà il graduale spostamento verso tecnologie piu performanti.
    non+autenticato
  • quali tecnologie dici?
    non+autenticato
  • - Scritto da: Jean Claude Fan Damm

    > come linguaggio rimarra confinato dentro le
    > banche per un altro pò di anni,poi anche li
    > inizierà il graduale spostamento verso tecnologie
    > piu
    > performanti.

    Mah, "tecnologie piu' performanti" mi pare una definizione un po nebulosa: Quali sono, e in che modo Java non potrebbe integrarle ?
    11237
  • - Scritto da: Jean Claude Fan Damm
    > come linguaggio rimarra confinato dentro le
    > banche per un altro pò di anni,poi anche li
    > inizierà il graduale spostamento verso tecnologie
    > piu performanti.

    Bah considerando che nelle banche persistono ancora (molti) applicativi scritti in COBOL e solo da qualche anno a questa parte e per i soli nuovi sviluppi viene usato Java, credo proprio che tutto ciò permetterà a quest'ultimo di sopravvivere per un sacco di tempo.
    mura
    1730
  • > Bah considerando che nelle banche persistono
    > ancora (molti) applicativi scritti in COBOL e
    > solo da qualche anno a questa parte e per i soli
    > nuovi sviluppi viene usato Java, credo proprio
    > che tutto ciò permetterà a quest'ultimo di
    > sopravvivere per un sacco di
    > tempo.
    Mi permetto di segnalarti questa perlaOcchiolino
    http://sourceforge.net/projects/cobolanywhere/
    non+autenticato
  • - Scritto da: pippo
    > > Bah considerando che nelle banche persistono
    > > ancora (molti) applicativi scritti in COBOL e
    > > solo da qualche anno a questa parte e per i soli
    > > nuovi sviluppi viene usato Java, credo proprio
    > > che tutto ciò permetterà a quest'ultimo di
    > > sopravvivere per un sacco di
    > > tempo.
    > Mi permetto di segnalarti questa perlaOcchiolino
    > http://sourceforge.net/projects/cobolanywhere/

    Le finalità del progetto non mi sembrano male ma se fossi una banca non mi affiderei a software in versione beta e senza nessuna azienda alle sue spalle per scrivere programmi che fanno girare un sacco di soldi tutti i giorni.
    mura
    1730
  • Ma queste tecnologie più performanti sono portabili come Java?

    Lo sai che Java + QT Jambi permette di fare software graficamente bello, valido e performante e che gira ovunque ci sia un JRE e le librerie QT (Windows, Linux, Mac, Solaris, *BSD)?

    E i web service con firma e criptazione per procedure che si connettono ad Oracle li fai con .NET?

    Java e i suoi application server e tutto il mondo di libri, letteratura, forum per programmatori, aziende che fanno assistenza, sono ordini di grandezza superiori a quanto esiste per .NET.
    non+autenticato
  • > Ma queste tecnologie più performanti sono
    > portabili come
    > Java?

    C++ ?A bocca aperta
    non+autenticato
  • Non è proprio uguale uguale, senza parlare della complessità.
    non+autenticato
  • > Non è proprio uguale uguale, senza parlare della
    > complessità.
    Vero è mooooolto meglio Innamorato
    non+autenticato
  • Si si a chiacchiere so tutti bravi!!!!

    Poi voglio vedere qualcuno che implementa una piattaforma di servizi SOA con annessa Web application tutta custom in c++.

    Poi magari raccontami quanto costa in tempi e risorse...

    Dimmi se, quali e quanti vantaggi "reali" ottieni rispetto ad una soluzione in Java EE con l'uso di un Application Server.

    Poi dimmi quanti considerando il rapporto costi benefici preferirebbero quella fatta in C++.

    Strano che Oracle, IBM, Red Hat, Sun abbiano scelto Java invece di c++ per vendere le loro Piattaforme Enterprise,

    strano che Google abbia scelto Java come linguaggio di sviluppo per il Web (GWT) e per Android...
    Ma si alla fine che vuoi che ne capiscano loro di informatica....i 4 benchmark fatti all'università tanto per dare senso ai corsi di dottorato sì che contano, invece i miliardi di fatturato delle grani aziende americane sono solo un caso!!!!

    - Scritto da: pippo
    > > Non è proprio uguale uguale, senza parlare della
    > > complessità.
    > Vero è mooooolto meglio Innamorato
    non+autenticato
  • Senza voler entrare nel merito della bontà e della sicurezza dell'una o dell'altra piattaforma, ricordo che:

    1) qualsiasi buon programmatore è in grado di fare anche il caffè con il linguaggio che padroneggia meglio, e che per questo tenderà a ritenere quel linguaggio migliore degli altri;

    2) Java è open, mentre .Net no, e questo condiziona anche il tipo di clienti a cui puoi proporti, e le soluzioni che puoi realizzare.
  • - Scritto da: andy61
    > Senza voler entrare nel merito della bontà e
    > della sicurezza dell'una o dell'altra
    > piattaforma, ricordo
    > che:
    >
    > 1) qualsiasi buon programmatore è in grado di
    > fare anche il caffè con il linguaggio che
    > padroneggia meglio, e che per questo tenderà a
    > ritenere quel linguaggio migliore degli
    > altri;
    >
    > 2) Java è open, mentre .Net no, e questo
    > condiziona anche il tipo di clienti a cui puoi
    > proporti, e le soluzioni che puoi
    > realizzare.

    Dopo tante cavolate, almeno un post ragionevole.
    Usate quello che volete, basta che il risultato sia buono, efficiente e soprattutto UTILE!!!
  • > 2) Java è open, mentre .Net no, e questo
    > condiziona anche il tipo di clienti a cui puoi
    > proporti, e le soluzioni che puoi
    > realizzare.

    mi spiegheresti tre cose:

    - cosa è java

    - cosa è .net

    - cosa è mono.

    Credo che possa dare una spiegazione alla tua affermazione.
  • 1) .Net è la concorrente di Java, inventata dalla Microsoft quando si è presa una batosta perché la Sun le ha fatto causa quando questa ha cercato di introdurre delle personalizzazioni proprietarie nella propria implementazione per Windows;

    2) Java è stato rilasciato sotto licenza open source, e questo significa che nessuno potrà mai impedirti di utilizzarlo, modificarlo o personalizzarlo, portarlo su una nuova piattaforma, e così via;

    3) .Net è proprietario della Microsoft, gira solo su piattaforma Windows (http://msdn.microsoft.com/en-us/library/ms973853.a...), non puoi vedere come è fatto dentro, non puoi portarlo su piattaforme diverse da quelle della Microsoft, e devi sottostare a tutte le condizioni e restrizioni d'uso della licenza Microsoft (EULA);
    attualmente è arrivato alla release 3.5 (e c'è in cantiere la 4.0);

    4) Mono è una libera implementazione delle API dichiarate del framework .Net, implementata ex novo con codice cross platform e sotto licenza open source, e per forza di cose è all'inseguimento delle specifiche che di volta in volta la Microsoft rilascia;
    a differenza di .Net, non c'è nessuno che può dirti se e quanto devi pagare, e se sei autorizzato o meno ad utilizzarlo per qualsiasi scopo ti venga in mente.

    Date le precisazioni di cui sopra, evidenzio almeno un paio casi tipici in cui non puoi utilizzare .Net:

    a. situazioni in cui il cliente non dispone di server Microsoft per fare girare applicazioni .Net;

    b. situazioni in cui i requisiti del cliente non consentono di utilizzare software di cui non possa verificare i contenuti (ambiente militare, etc.)

    Conclusioni:
    - con Java puoi adattarti a qualsiasi situazione;
    - con .Net puoi sfruttare meglio lo stato dell'arte della piattaforma Microsoft, ma devi accettare di orientarti verso un target senza requisiti troppo stringenti (ed anche disposto a pagare qualche soldo in più di licenze software e dei relativi futuri upgrade software e hardware).

    Non sono stato esaustivo, ma spero di aver chiarito un po' la differenza tra i due mondi.
  • > 1) qualsiasi buon programmatore è in grado di
    > fare anche il caffè con il linguaggio che
    > padroneggia meglio, e che per questo tenderà a
    > ritenere quel linguaggio migliore degli
    > altri;

    Ma un linguaggio è più adatto ad essere utilizzato per alcuni progetti rispetto ad altri per ragioni di velocità, mantenibilità del codice ecc...

    > 2) Java è open, mentre .Net no, e questo
    > condiziona anche il tipo di clienti a cui puoi
    > proporti, e le soluzioni che puoi
    > realizzare.

    Si ma se fai errori la responsabilità e' tutta tua non puoi dire che è colpa di scandenti prodotti M$
    non+autenticato
  • 1) vero, ma non sempre, o meglio molto raramente, puoi disegnare sistema e piattaforma intorno al linguaggio che preferisci utilizzare;

    2) gli errori li fa chiunque e con qualunque linguaggio; se i tuoi programmatori non sono adatti alla piattaforma stabilita, o rinunci al progetto, o rischi di fare un cattivo lavoro, o assumi dei programmatori adeguati al tipo di progetto.
CONTINUA A LEGGERE I COMMENTI
Successiva
(pagina 1/2 - 6 discussioni)