Big del Cloud

Disponibile Java 18: migliorate le performance e la stabilità e introdotte funzioni per incrementare la produttività

di pubblicata il , alle 15:41 nel canale Innovazione Disponibile Java 18: migliorate le performance e la stabilità e introdotte funzioni per incrementare la produttività

Oltre a migliaia di piccole novità per migliorare le prestazioni, Oracle ha introdotto nove JDK Enhancement Proposal. Java Management Service consente di gestire runtime e applicazioni Java in modalità on-premise e in qualsiasi cloud

 

Oracle ha aggiornato il linguaggio di programmazione Java, rendendo disponibile l'ultima versione, Java 18. Java, per chi non lo sapesse, è uno dei linguaggi di programmazione più utilizzati al mondo e, rispetto ad altre alternative, ha il vantaggio di essere un linguaggio sia interpretato sia compilato, fatto che rende possibile eseguire il codice su qualsiasi dispositivo dotato di un interprete Java che, semplificando molto, "compila" al volo un codice intermedio (bytecode). 

La versione 18 introduce numerosi miglioramenti che lo rendono più veloce, stabile e sicuro, ma il focus dell'ultima incarnazione è su 9 funzionalità pensate per migliorare la produttività degli sviluppatori

Java 18 oracle

Java 18: introdotti 9 JDK Enhancement Proposal e potenziato il supporto cloud

L'utima release di Java include migliaia di piccoli aggiornamenti che migliorano le performance e la stabilità della piattaforma, ma la novità principale è relativa a nove JEP (JDK Enhancement Proposal), fra cui la possibilità di inserire aggiungere Code Snippets nella Java API Documentation: questo permette di semplificare  l'aggiunta di codice sorgente di esempio nella documentazione delle API e Simple Web Server. Introdotti anche due moduli di incubazione, Vector API (JEP 417) e Foreign Function and Memory API (JEP 419), oltre alla funzionalità di anteprima, Pattern Matching for Switch (JEP 420).

 

JMS

JMS (Java Management Service) è invece un servizio OCI (Oracle Cloud Infrastructure) recentemente introdotto per consentire l'esecuzione delle applicazioni sia on-premise sia su qualsivoglia servizio cloud ed è è incluso per i carichi di lavoro OCI e per coloro che hanno sottoscritto Java SE.

"La release di Java 18 dimostra il costante impegno di Oracle nel fornire ad aziende e sviluppatori un accesso più rapido ai miglioramenti con una cadenza del rilascio delle funzionalità semestrale", ha dichiarato Georges Saab, Vice President of Development, Java Platform Group di Oracle. "Continuiamo a fare investimenti tecnici che migliorano le performance, la stabilità e la sicurezza delle implementazioni della piattaforma Java SE e di Java Development Kit".

Le novità in sintesi

Aggiornamenti e miglioramenti alle librerie

  • JEP 400: UTF-8 by Default imposta UTF-8 come set di caratteri predefinito delle API Java standard. Grazie a questa modifica, le API che dipendono dal set di caratteri predefinito avranno un funzionamento coerente su tutte le implementazioni, i sistemi operativi, le versioni locali e le configurazioni.
  • JEP 408: Simple Web Server, uno strumento della riga di comando e un'API per l'avvio di un server Web minimale che distribuisce solo file statici. Questo strumento è utile per la creazione di prototipi, la scrittura di codice ad hoc e i test, in particolare nei contesti didattici.
  • JEP 416: Reimplement Core Reflection with Method Handles reimplementa java.lang.reflect.Method, costruttore e campo sugli handle di metodo java.lang.invoke. Rendendo gli handle di metodo il meccanismo di riflessione di base, si riducono i costi di manutenzione e sviluppo delle API java.lang.reflect e java.lang.invoke.
  • JEP 418: Internet-Address Resolution SPI definisce un'interfaccia SPI (Service-Provider Interface) per la risoluzione del nome host e dell'indirizzo, in modo che java.net.InetAddress possa utilizzare resolver diversi da quello integrato nella piattaforma.

 Strumenti

  • JEP 413: JEP Code Snippets in Java API Documentation introduce il tag @snippet per il Doclet standard di JavaDoc in modo da semplificare l'inclusione del codice sorgente di esempio nella documentazione delle API.

Anteprima e incubatori per le prossime release JDK

  • JEP 417: Vector API (Third Incubator) fornisce agli sviluppatori un'API per sfruttare in modo affidabile le architetture CPU che offrono estensioni vettoriali scalabili. In questo modo si otterranno prestazioni superiori rispetto ai calcoli equivalenti nei processori non estesi.
  • JEP 419: Foreign Function and Memory API (Second Incubator) permette ai programmi Java di interagire con codice e dati al di fuori del runtime Java. Richiamando in modo efficiente funzioni estranee (ossia codice al di fuori diJVM) e accedendo in tutta sicurezza alla memoria estranea (ad esempio, memoria non gestita da JVM), l'API permette ai programmi Java di chiamare librerie native ed elaborare dati nativi senza la fragilità e le insidie di JNI.
  • JEP 420: Pattern Matching for Switch (Second Preview) migliora il linguaggio di programmazione Java con la corrispondenza di pattern per le espressioni e le istruzioni dello switch e le estensioni del linguaggio di pattern. L'estensione della corrispondenza di pattern allo switch, consente di testare un'espressione su vari pattern, ciascuno con un'azione specifica, in modo che le query complesse basate sui dati possano essere espresse brevemente e in modo sicuro.

Programmi Java per le esigenze future

  • JEP 421: Deprecate Finalization for Removal; la finalizzazione rimane abilitata di default per il momento, ma può essere disabilitata per facilitare i test. In una release futura, questa opzione verrà disabilitata di default e in una release successiva verrà rimossa. È consigliabile che i gestori delle librerie e delle applicazioni che si basano sulla finalizzazione, considerino altre tecniche di gestione delle risorse, come l'istruzione try-with-resources e cleaners.
5 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
sidewinder23 Marzo 2022, 15:44 #1
Qui a lavoro stiamo già iniziando a lavorare con JDK 11..... mentre il mainstream viaggia ancora su JDK 8 /OpenJDK8

Per arrivare al JDK17 ne passera tanta di quell'acqua..
ivanohw23 Marzo 2022, 15:52 #2
Anche noi appena passati da 8 a 11, ma non Oracle bensì OpenJDK
lollo923 Marzo 2022, 16:49 #3
Sul come e perché non sia né sia mai stato un linguaggio interpretato è stato scritto qualche centinaio di libri, ma ok.

Anzi, non è ok, capisco il dover semplificare per questioni giornalistiche, ma questa distinzione compilato vs interpretato è una cosa di un anacronismo unico.
Come se negli ultimi 40 anni non ci fosse stato niente in informatica.
ciacki24 Marzo 2022, 15:13 #4
Maaa, non era la compilazione tramite javac a produrre il bytecode, che poi viene eseguito su Virtual Machine che traduce in linguaggio macchina? E poi, quelle teste di fava di Oracle hanno veramente messo un altro acronimo JMS quando per tutto il mondo è il Java Message Service?
k0nt325 Marzo 2022, 00:50 #5
Originariamente inviato da: sidewinder
Qui a lavoro stiamo già iniziando a lavorare con JDK 11..... mentre il mainstream viaggia ancora su JDK 8 /OpenJDK8

Per arrivare al JDK17 ne passera tanta di quell'acqua..


Originariamente inviato da: ivanohw
Anche noi appena passati da 8 a 11, ma non Oracle bensì OpenJDK

La differenza tra 11 e 17 non è così grossa come da 8 a 11. Passare da openjdk 8 a 11 tecnicamente non ha molto senso perché il supporto per la 8 dura 2 anni in più. A questo punto è meglio passare direttamente alla 17.
https://access.redhat.com/articles/1299013
Originariamente inviato da: lollo9
Sul come e perché non sia né sia mai stato un linguaggio interpretato è stato scritto qualche centinaio di libri, ma ok.

Anzi, non è ok, capisco il dover semplificare per questioni giornalistiche, ma questa distinzione compilato vs interpretato è una cosa di un anacronismo unico.
Come se negli ultimi 40 anni non ci fosse stato niente in informatica.

L'articolo dice che è sia compilato che interpretato, non ci vedo niente di sbagliato.
https://www.baeldung.com/java-compiled-interpreted
The source code we write in Java is first compiled into bytecode during the build process. The JVM then interprets the generated bytecode for execution. However, the JVM also makes use of a JIT compiler during runtime to improve performances.

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
^