Caratteristiche dubbie di Java 8

Le prime reazioni pesano rovescio della medaglia del cambiamento, in quanto gli sviluppatori di ottenere reale sulle nuove funzionalità di Java 8

La maggior parte di noi che sviluppano in Java sono generalmente entusiasti per le caratteristiche e miglioramenti che vengono con JDK 8 . Tuttavia, ci sono stati diversi post recenti che hanno sottolineato alcune caratteristiche che possono essere impropriamente utilizzate e abusate e potrebbe portare ad alcuni problemi aggiuntivi nel futuro.Queste caratteristiche, che mi ricordano l'introduzione di autoboxing  in  J2SE 5 , hanno le loro situazioni utili, ma può anche portare a problemi quando non correttamente intesa e applicata. In questo post, io uso i riferimenti a messaggi di altri popoli 'scritto su queste caratteristiche dubbie. Si noti che questo post non si tratta di "normali"  problemi noti  che sono associati con qualsiasi release.

Le espressioni lambda sembrano essere la più grande  novità del JDK 8 , ma  Tal Weiss  ha scritto un post chiamato  The Dark Side Of espressioni lambda in Java 8 . In quel post, Weiss scrive di un "lato oscuro" per le espressioni lambda e  Nashorn JavaScript motore  (che egli sostiene è la caratteristica secondo più grande del JDK 8). Parla della "distanza tra il codice e il runtime" e sottolinea che "stiamo pagando il prezzo per brevi, codice più conciso con il debugging più complesso, e più a lungo gli stack di chiamate sintetico."

In  Amore e odio per Java 8 ,  Andrew C. Oliver  e  Michael Brush  forniscono una bella introduzione ad alcune delle principali nuove funzionalità di JDK 8. Sono sostengono che i  metodi predefiniti sulle interfacce  "consentire una forma di ereditarietà multipla" e sarà "probabilmente [essere] dettaglio che riguarderà maggior parte delle persone in Java 8. " Essi concludono con la valutazione, "La caratteristica che sta per essere pericoloso è interfacce funzionali. Se non vengono utilizzati correttamente, potrebbero causare un sacco di mal di testa."

Peter Verhas  ha scritto una dettagliata analisi dei potenziali problemi con metodi predefiniti sulle interfacce in posti  Java 8 metodi predefiniti: cosa può e non può fare?  e  Come non usare metodi Java 8 di default . In un post, egli afferma, "Aggiunta di un metodo predefinito a un'interfaccia può rendere una classe inutilizzabile." In altro post, aggiunge, "Il metodo predefinito è un errore tecnologico" e fa riferimento al fatto che i metodi predefiniti sono stati aggiunti a interfacce Java per supportare la compatibilità delle implementazioni esistenti, con i metodi che devono essere aggiunti alle interfacce per supportare nuove JDK 8 caratteristiche.

Lukas Eder s '  Il lato oscuro di Java 8  postale esprime diverse preoccupazioni circa i metodi di default: l'incapacità di fare un metodo predefinito  finale  o  sincronizzato e l'introduzione della parola chiave "default". Un altro interessante "caveat", ha sottolineato in questo post sono le espressioni lambda effetto hanno sul sovraccarico.

Un altro post Tal Weiss,  Nuove parallelismo API in Java 8: Behind The Glitz e Glamour , esamina alcune questioni Weiss osservare quando si misurano le prestazioni dei "nuovi Java 8 API funzionamento in parallelo" sotto carico. Weiss osserva ", aggiungendo thread in quello che già è un ambiente multi-threaded non ti aiuta" e ci ricorda: "Mentre questi sono molto forti e le API di facile utilizzo, non sono una  pallottola d'argento . Abbiamo ancora bisogno di applicare il giudizio da quando impiegarli. "

Lukas Krecan  avverte  Pensaci due volte prima di usare Java 8 flussi paralleli  e scrive: "Il problema è che tutti i flussi paralleli utilizzano  la piscina comune filo fork-join  e se si invia un lavoro di lunga durata, si bloccano in modo efficace tutti i thread in piscina. " Per far fronte a questo, Krecan consiglia sia "[garantire] che tutte le attività presentate al comune piscina fork-join non si blocca e si concluderà in un tempo ragionevole" o "non utilizzare flussi paralleli e attendere che Oracle ci permette di specificare l' pool di thread da utilizzare per flussi paralleli ".

Edwin Dalorzo posto s '  Perché c'è Interface Inquinamento in Java 8  esamina come tipo di cancellazione ,  controllato eccezioni , e la mancanza di  tipi di valore  ( PEC 169 ) ha portato a progettare le decisioni in JDK 8 che dispongono di interfacce Java "inquinati". Il post mescola citazioni da Brian Goetz riguardanti JDK 8 decisioni di progettazione con il proprio commento dell'autore di fare il punto che "ci sono buone spiegazioni per il lato oscuro di esistere."

Ci sono, naturalmente, le questioni tra JDK appena rilasciata 8 e gli strumenti costruiti su Java. Ad esempio, nel post Ciao Java 8 (e come fa GlassFish senza parole ...) ,  Cay Horstmann  documenti GlassFish 4 non scrivere alcuna traccia dello stack di sorta quando aveva "[redatto] La guerra con la versione sbagliata di Java."

Anche se i posti di riferimento sottolineano questioni legittime di preoccupazione legati ad alcune delle caratteristiche più attesi del JDK 8 come espressioni lambda, ruscelli, metodi predefiniti interfaccia, e il motore di Nashorn JavaScript, io sono ancora entusiasta del  nuovo mondo di sviluppo Java con JDK 8 . I messaggi evidenziati in questo post sono promemoria per utilizzare queste nuove funzionalità attentamente e giudiziosamente modo che godiamo i vantaggi che ne derivano, mentre mitigare il più possibile i nuovi pericoli ed i costi che essi presentano quando viene utilizzato meno saggiamente.

Corso Java - Corsi programmazione Java -  Corso programmazione Android - Certificazione Java - Corsi Java - Corso Java Avanzato