JDK 18: de nieuwe functies in Java 18

About

In maart 2022 zal Java 18 een vector-API uitbroeden, patroonovereenkomsten voor switch-statements bekijken, UTF-8 gebruiken als de standaardtekenset en een eenvoudige webserver bevatten.

Java Development Kit (JDK) 18 staat gepland voor release op 22 maart 2022. De nieuwe versie van standaard Java zal negen nieuwe functies hebben, en de functieset is vanaf 9 december bevroren.

De release is in een eerste rampdown-fase terechtgekomen. Upgrades naar standaard Java worden elke zes maanden uitgebracht, met de meest recente, JDK 17, die in september arriveerde.

De OpenJDK-pagina vermeldt de volgende functies als officieel gericht op JDK 18: een serviceproviderinterface, een eenvoudige webserver, een vector-API, codefragmenten, een herimplementatie van kernreflectie, een UTF-8-tekenset, een tweede incubator van een vreemde functie en geheugen-API, een tweede voorbeeld van patroonovereenkomst voor switch-statements en de afschaffing van finalisatie, de laatste toevoeging.

Voorafgaand aan de algemene beschikbaarheid, is een tweede rampdown-fase gepland voor 20 januari 2022. Release-kandidaten worden verwacht op 10 februari en 24 februari van volgend jaar.

Terwijl JDK 17 een release voor lange termijn ondersteuning (LTS) was die ten minste acht jaar ondersteuning van Oracle zal krijgen, zal JDK 18 een release voor korte termijn functies zijn die zes maanden wordt ondersteund. Early-access builds van JDK 18 zijn te vinden voor Linux, Windows en MacOS op java.net.

Bijzonderheden van de JDK 18-proposals zijn onder meer:

Finalisatie voor verwijdering afschaffen: in een toekomstige uitgave. Finalizer heeft gebreken die in de praktijk aanzienlijke problemen veroorzaken op het gebied van beveiliging, prestaties, betrouwbaarheid en onderhoudbaarheid. Het heeft ook een moeilijk programmeermodel. Finalisatie is momenteel standaard ingeschakeld, maar kan worden uitgeschakeld om vroegtijdig testen te vergemakkelijken. Het wordt standaard uitgeschakeld in een functie-release en helemaal verwijderd in een latere release. Het voorstel vraagt om een opdrachtregeloptie om afronding en afschrijving van alle finalizers en afrondingsmethoden in de standaard Java API uit te schakelen. Doelen van het voorstel zijn onder meer ontwikkelaars te helpen de gevaren van afronding te begrijpen, ontwikkelaars voor te bereiden op de uiteindelijke verwijdering en eenvoudige hulpmiddelen te bieden om de afhankelijkheid van afronding te detecteren. Geïntroduceerd in Java 1.0, was finalisatie bedoeld om lekken van bronnen te voorkomen. Een klasse kan een finalizer declareren — de methodeprotected void finalize()- wiens lichaam een onderliggende bron vrijgeeft. De vuilnisman zal de finalizer van een onbereikbaar object plannen om te worden aangeroepen voordat het objectgeheugen terugwint; op zijn beurt kan de finalizemethode acties ondernemen, zoals het aanroepen van het objectclose. (Zie JDK-uitbreidingsvoorstel 421 voor details.)
Voor de internetadresresolutie SPI wordt voorgesteld een SPI te definiëren voor host- en Inet.Addressnaamadresresolutie, zodat gebruik kan worden gemaakt van andere resolvers dan de ingebouwde resolver van het platform. Motivaties voor deze inspanning zijn onder meer een betere ondersteuning van Project Loom , voor gelijktijdigheid en nieuwe programmeermodellen in Java, samen met de integratie van nieuwe netwerkprotocollen, maatwerk en het mogelijk maken van testen. Het voorstel omvat niet het ontwikkelen van een alternatieve resolver voor de JDK.
Een tweede voorbeeld van patroonherkenning voor switch , waarin de Java-taal zou worden uitgebreid met patroonherkenning voor switch uitdrukkingen en statements, samen met uitbreidingen op de taal van patronen. Dit werd bekeken in JDK 17 . Door patroonovereenkomsten uit te breiden, switch kan een expressie worden getest aan de hand van een aantal patronen, elk met een specifieke actie, zodat complexe gegevensgerichte zoekopdrachten beknopt en veilig kunnen worden uitgedrukt.
De herimplementatie van kernreflectie met methodehandles zou lang.reflect.Method, Constructor, en Field bovenop methodehandvatten opnieuw implementeren java.lang.invoke. Na methode handvatten dienen als het onderliggende mechanisme voor reflectie zal het onderhoud en de ontwikkeling van de kosten van zowel de te verminderen java.lang.reflect en de java.lang.invoke API’s.
Met het eenvoudige webservervoorstel zou een opdrachtregelprogramma worden geleverd om een minimale webserver te starten die alleen statische bestanden bedient. Er is geen CGI of servlet-achtige functionaliteit beschikbaar. De tool zal nuttig zijn voor prototyping, ad-hoccodering en testen, met name in educatieve contexten. Doelen van het plan zijn onder meer het aanbieden van een kant-en-klare statische HTTP-bestandsserver met eenvoudige installatie en minimale functionaliteit, het verminderen van activeringsenergie voor ontwikkelaars en het toegankelijker maken van de JDK, en het bieden van een standaardimplementatie via de opdrachtregel samen met een kleine API voor programmatische creatie en maatwerk. Het bieden van een server met veel functies of commerciële kwaliteit is geen doel van het voorstel.
Een tweede incubatie van een foreign functie en geheugen-API, waarin een API wordt geïntroduceerd waarmee Java-programma’s kunnen samenwerken met code en gegevens buiten de Java-runtime. Door buitenlandse functies aan te roepen – code buiten de JVM – en door veilig toegang te krijgen tot extern geheugen – geheugen dat niet door de JVM wordt beheerd – laat de API Java-programma’s native bibliotheken aanroepen en native data verwerken zonder de broosheid en het gevaar van JNI (Java Native Interface). De bedoeling is om JNI te vervangen door een superieur, puur Java-ontwikkelmodel. Deze API is geïncubeerd in JDK 17. Voor JDK 18 zouden verfijningen worden opgenomen op basis van feedback, zoals ondersteuning voor meer carriers zoals Boolean en MemoryAddress in var-handles voor geheugentoegang, en een nieuwe API om Java-arrays van en naar het geheugen te kopiëren segmenten.
De vector-API zou voor de derde keer worden geïncubeerd in JDK 18, nadat het eerder was geïncubeerd in JDK 16 en JDK 17 . Dit voorstel zou vectorberekeningen uitdrukken die tijdens runtime compileren tot optimale vectorinstructies op ondersteunde CPU-architecturen, waardoor prestaties worden bereikt die superieur zijn aan equivalente scalaire berekeningen. Vectorbewerkingen drukken een zekere mate van parallellisatie uit, waardoor er meer werk kan worden gedaan op een enkele CPU-cyclus, wat aanzienlijke prestatieverbeteringen oplevert. De platformonafhankelijke vector-API is bedoeld om een manier te bieden om complexe algoritmen in Java te schrijven, met behulp van de bestaande HotSpot auto-vectorizer, maar met een gebruikersmodel dat vectorisatie voorspelbaarder maakt. JDK 18 zou ook ondersteuning toevoegen voor de ARM Scalar Vector Extension platform en verbeteren de prestaties van vectorbewerkingen die maskers accepteren op architecturen die maskering in hardware ondersteunen.
UTF-8 specificeren als de standaardtekenset van de standaard Java API’s. UTF-8 is een variabele-brede tekencodering voor elektronische communicatie en wordt beschouwd als de standaardtekenset van het web. Charset is tekencodering die alle tekens op internet kan coderen. Door deze wijziging gedragen API’s die afhankelijk zijn van de standaardtekenset zich consistent in alle implementaties, besturingssystemen, landinstellingen en configuraties. Het voorstel is niet bedoeld om nieuwe Java-standaard of JDK-specifieke API’s te definiëren. Voorstanders van het voorstel verwachten dat applicaties in veel omgevingen geen impact zullen ondervinden van Java’s keuze voor UTF-8, aangezien MacOS, veel Linux-distributies en veel serverapplicaties al UTF-8 ondersteunen. Er is echter een risico in andere omgevingen, het meest voor de hand liggende is dat toepassingen die afhankelijk zijn van de standaardtekenset, zich onjuist zullen gedragen bij het verwerken van gegevens die zijn geproduceerd terwijl de standaardtekenset niet gespecificeerd was. Gegevenscorruptie kan stilletjes optreden. De grootste impact zal naar verwachting vallen voor gebruikers van Windows-systemen in Aziatische landen en mogelijk sommige serveromgevingen in Aziatische en andere landen.
Codefragmenten in Java API-documentatie , waaronder de introductie van een @snippettag voor JavaDoc’s Standard Doclet, om het opnemen van voorbeeldbroncode in API-documentatie te vereenvoudigen. Een van de doelen van het plan is het faciliteren van de validatie van broncodefragmenten door API-toegang tot die fragmenten te bieden. Hoewel correctheid de verantwoordelijkheid is van de auteur, kan verbeterde ondersteuning in JavaDoc en gerelateerde tools het gemakkelijker maken om dit te bereiken. Andere doelen zijn onder meer het mogelijk maken van moderne styling, zoals syntaxisaccentuering, evenals het automatisch koppelen van namen aan declaraties, en het mogelijk maken van betere IDE-ondersteuning voor het maken en bewerken van fragmenten. In het voorstel wordt opgemerkt dat auteurs van API-documentatie vaak fragmenten van broncode opnemen in documentatie-opmerkingen.