Post ses monatoj da evoluo, Oracle publikigis Java SE 18 (Java Platform, Standard Edition 18), kiu uzas la OpenJDK malfermfontecan projekton kiel sian referencan efektivigon. Escepte de la forigo de kelkaj malnoviĝintaj funkcioj, Java SE 18 konservas malantaŭan kongruon kun antaŭaj eldonoj de la Java platformo - la plej multaj antaŭe verkitaj Java-projektoj funkcios sen ŝanĝoj kiam ili funkcias sub la nova versio. Pretaj instalaĵoj de Java SE 18 (JDK, JRE kaj Server JRE) estas pretaj por Linukso (x86_64, AArch64), Vindozo (x86_64) kaj macOS (x86_64, AArch64). Disvolvita de la OpenJDK-projekto, la referenca efektivigo de Java 18 estas plene malfermfonta laŭ la permesilo GPLv2, kun GNU ClassPath-esceptoj permesantaj dinamikan ligon kun komercaj produktoj.
Java SE 18 estas klasifikita kiel ĝenerala subtena eldono kaj daŭre ricevos ĝisdatigojn ĝis la venonta eldono. La branĉo Long Term Support (LTS) devus esti Java SE 17, kiu daŭre ricevos ĝisdatigojn ĝis 2029. Ni memorigu vin, ke ekde la liberigo de Java 10, la projekto ŝanĝis al nova evoluprocezo, kio implicas pli mallongan ciklon por la formado de novaj eldonoj. Nova funkcieco nun estas evoluigita en unu konstante ĝisdatigita majstra branĉo, kiu inkluzivas pretajn ŝanĝojn kaj de kiuj branĉoj estas disbranĉigitaj ĉiujn ses monatojn por stabiligi novajn eldonojn.
Novaj funkcioj en Java 18 inkluzivas:
- La defaŭlta kodado estas UTF-8. Ĝavaj API, kiuj prilaboras tekstajn datumojn surbaze de signokodigado, nun uzos UTF-8 defaŭlte en ĉiuj platformoj, sendepende de sistemaj agordoj kaj lokaj agordoj. Por reveni al la malnova konduto, kie la kodado estas elektita surbaze de la sistemloko, vi povas uzi la opcion "-Dfile.encoding=COMPAT".
- La pakaĵo inkluzivas la pakaĵon com.sun.net.httpserver, kiu inkluzivas la jwebserver-servaĵon kaj bibliotekan API kun la efektivigo de simpla http-servilo por servi statikan enhavon (CGI kaj servlet-similaj pritraktiloj ne estas subtenataj). La enkonstruita HTTP-servilo ne estas optimumigita por laborŝarĝoj kaj ne subtenas alirkontrolon kaj aŭtentikigon, ĉar ĝi celas ĉefe al uzo en la evoluprocezo por prototipado, sencimigado kaj testado de projektoj.
- JavaDoc provizas subtenon por la etikedo "@snippet" por enigi funkciajn ekzemplojn kaj kodajn fragmentojn en API-dokumentadon, kie vi povas uzi validigajn ilojn, sintaksajn reliefigon kaj IDE-integriĝon.
- La efektivigo de la java.lang.reflect API (Core Reflection), desegnita por akiri informojn pri metodoj, kampoj kaj klaskonstruistoj, same kiel aliron al la interna strukturo de klasoj, estis restrukturita. La java.lang.reflect API mem restas senŝanĝa, sed nun estas efektivigita uzante metodotenilojn disponigitajn per la java.lang.invoke-modulo, anstataŭ uzi bajtokodgeneratorojn. La ŝanĝo permesis al ni unuigi la efektivigojn de java.lang.reflect kaj java.lang.invoke, kaj simpligi ilian prizorgadon.
- Tria antaŭprezento de la Vektora API estis proponita, provizante funkciojn por vektoraj kalkuloj, kiuj estas ekzekutitaj per vektoraj instrukcioj sur x86_64 kaj AArch64-procesoroj kaj permesas operaciojn esti aplikataj samtempe al multoblaj valoroj (SIMD). Male al la kapabloj disponigitaj en la HotSpot JIT-kompililo por aŭto-vektorizado de skalaraj operacioj, la nova API ebligas eksplicite kontroli vektorigon por paralela datumtraktado.
- Aldonita SPI-interfaco (servo-provizanta interfaco) por solvi gastigajn nomojn kaj IP-adresojn, permesante al vi uzi alternativajn solvilojn en java.net.InetAddress, kiuj ne estas ligitaj al pritraktiloj ofertitaj de la operaciumo.
- Dua antaŭprezento de la Foreign Function & Memory API estas disponigita, permesante al aplikoj interagi kun kodo kaj datumoj ekster la Java rultempo. La nova API permesas vin efike voki ne-JVM-funkciojn kaj aliri ne-JVM-administritan memoron. Ekzemple, vi povas voki funkciojn de eksteraj komunaj bibliotekoj kaj aliri procezajn datumojn sen uzi JNI.
- Dua eksperimenta efektivigo de ŝablona kongruo en "ŝanĝaj" esprimoj estis aldonita, permesante la uzon de flekseblaj ŝablonoj en "kazaj" etikedoj prefere ol precizaj valoroj, kovrante serion da valoroj samtempe, por kiuj antaŭe estis necese uzi maloportunaj ĉenoj de "se... alie" esprimoj. Objekto o = 123L; Ŝnuro formatita = switch (o) { case Entjero i -> String.format("int %d", i); case Long l -> String.format("longa %d", l); case Double d -> String.format("duobla %f", d); case String s -> String.format("String %s", s); defaŭlta -> o.toString(); };
- La finmekanismo kaj ĝiaj rilataj metodoj kiel ekzemple Object.finalize(), Enum.finalize(), Runtime.runFinalization() kaj System.runFinalization() estis malrekomenditaj kaj estos malŝaltitaj en estonta eldono.
- La ZGC (Z Garbage Collector), SerialGC, kaj ParallelGC rubokolektistoj subtenas vicmalplikopigon.
fonto: opennet.ru