Inserito da Dustin Marx i
Con Java 7 considerato praticamente un affare fatto (ho avuto lo installato sul mio computer di casa come il JRE primario per settimane), molti di noi stanno iniziando a sognare ciò che potrebbe venire con Java 8 . In questo post ho brevemente guardare a ciò che mi piacerebbe vedere in Java 8 prima di guardare ad un certo altre persone 'liste dei desideri per Java 8. Finisco questo post con le mie idee su ciò che più probabilità di andare in Java 8.
La mia lista dei desideri Java 8
Generici Runtime pieno supporto
Penso che la cosa che vorresti di più vedere in una futura versione di Java (e la prima è meglio è) è reificato generici. Anche se ci sono molte piccole modifiche zucchero sintattico che sarebbe bello, la cancellazione di tipo cancellazione generici sarebbe il benvenuto.
JMX 2.0 Caratteristiche
Nel commento prima risposta a Giuliano Exenberger 's -DZone sindacato versione di Java 8,0 Lista dei desideri , Jonathan Fisher afferma che vorrebbe, tra le altre cose, "Annotazione basata JMX."Sono stato deluso quando è stato annunciato nella estate del 2009che JMX 2,0 sarebbe stato differito fino Java 8. Purtroppo, la questione Java Specification Request ( JSR 255 ) è in inattivi Stato.Numerose sono le caratteristiche proposte di JMX 2.0 che mi piacerebbe vedere. Come Fisher, avrei apprezzato di annotazione basato su JMX . Altra bella JMX caratteristiche 2,0 incluso interrogazione migliorata e il supporto associate perJMX servizi web .
Migliorata Data / Ora di supporto
In principio, ci fu data . Questa classe aveva più la sua parte di problemi e ora 2 / 3 dei suoi costruttori (quattro su sei) sono obsolete e quasi tutti i suoi metodi sono deprecati (ad eccezione di gran parte Sostituzione di metodi di oggetti o di attuazione del Cloneable e comparabili interfacce).
L' interfaccia di calendario e la sua classe di implementazione primaria ( GregorianCalendar ) sono stati i tentativi di affrontare i problemi associati a data (anche se ci sono argomenti per situazioni in cui Data è preferibile calendario ).
Purtroppo, calendario ha problemi di suo e non è particolarmente piacevole da usare perché sacrifica l'usabilità in nome di generalità e flessibilità (un beneficio che è raramente applicata perché la maggior parte di noi usano GregorianCalendarcomunque). Molti sviluppatori Java hanno trovato il tempo Joda biblioteca di essere un approccio fresco alla gestione di data e ora in Java .
Molti di noi erano eccitati alla prospettiva di Java 7 offrendo un miglioramento del data / ora di approccio attraverso JSR 310("Data e ora API"). Purtroppo, JSR 310 è stata esclusa in Java 7 , ma suona come se ci fosse la possibilità che potrebbe essere parte di Java 8 . L'implementazione di riferimento di JSR 310 è il progetto ThreeTen . E 'riassunta con questo testo: "ThreeTen fornisce una data biblioteca moderna e il tempo per Java ed è l'implementazione di riferimento per le JSR 310Esso include molte delle lezioni del Joda-Time progetto e mira a standardizzare i concetti di data e ora nel mondo dei computer.. " Mi piacerebbe vedere JSR 310 implementato in Java 8.
Java altri '8 Desideri
Il già citato messaggio Java 8,0 Wishlist illustra alcune delle caratteristiche più desiderate Giuliano Exenberger per Java 8.Queste includono le proprietà, l'overloading degli operatori, "autoboxing finitura" (metodi letterali), e "[fare] JavaFX utile."Alcune delle persone commentando questo post con veemenza non vogliamo proprietà o l'overloading degli operatori. Altre persone dichiarato le loro caratteristiche desiderate in commento a questo articolo. Tra queste annotazioni precondizioni per il controllo e la postcondizioni, modularizzazione, "completa JavaFX," JRE su più piattaforme , e ripulito SDK / librerie.
La mia ipotesi è che una delle più ambite caratteristiche per Java 8 è "chiusure". Infatti, uno dei modi migliori per identificare quali caratteristiche sono più probabilità di essere più ambite per Java 8 è di vedere ciò che è "più perdere" dal proposto, ma caduto Java 7 integrazioni . Ho bloggato che funzioni come chiusure, le proprietà, i generics reificato, fagioli vincolante, overloading degli operatori, e la sintassi BigDecimal che furono lanciate da Java 7. Il sondaggio Java.net su queste funzionierano quasi la metà del intervistati dichiara che la chiusura era la loro caratteristica più imperdibile è sceso da Java SE 7.
Charles Nutter piacerebbe vedere Java 8 aggiungere coroutine e ha iniziato questo sforzo .
Cosa c'è rischia di rendere Java 8?
Speriamo di avere una migliore idea di quello che sarà in Java 8 da JavaOne 2011 . Tuttavia, abbiamo alcune informazioni che fornisce suggerimenti su ciò che siamo più probabilità di vedere in Java 8. In primo luogo, di Mark Reinhold 's famosopiano B ci dà una buona idea iniziale di idee sperimentali per Java 8: modularità, "Le espressioni lambda (informalmente, 'chiusure')," tipi Java annotazioni e miglioramenti del linguaggio più piccoli ("Progetto Coin 2 ").
Un'altra buona fonte di ciò che è probabile che sia realmente in Java 8 è l'articolo uno sguardo al futuro di Java SE 7 e 8: Una discussione con l'architetto Lingua Oracle Java, Brian Goetz . In questo articolo, parla di tentativo di Goetz Java 8 presenta come "aggiornamenti alle librerie Java nucleo di esprimere più facilmente i calcoli in parallelo sulle collezioni" e "metodi di estensione virtuale" (permette di aggiungere dei "metodi di interfacce che specificano un riferimento a un valore predefinito attuazione ").
Conclusione
Java è uno dei linguaggi di programmazione più utilizzati nel mondo e la vastità della sua base di sviluppatori significa che ci sarà una grande disparità di opinioni su quali caratteristiche Java sarebbe più beneficiare. Tuttavia, credo che i linguaggi dinamici sulla JVM (come Groovy ) hanno influenzato molti di noi per favorire la chiusura e questa è una caratteristica che sembra destinato a Java 8
Corso Java - Corsi Java - Corsi programmazione Java
Corso programmazione Android - Certificazione Android
Nessun commento:
Posta un commento
Nota. Solo i membri di questo blog possono postare un commento.