Post ses monatoj da evoluo, Oracle platformo (Java Platform, Standard Edition 15), la malfermfonta OpenJDK-projekto estas uzata kiel referenca efektivigo. Java SE 15 konservas malantaŭan kongruon kun antaŭaj eldonoj de la Java-platformo; ĉiuj antaŭe skribitaj Java-projektoj funkcios sen ŝanĝoj kiam lanĉitaj sub la nova versio. Preta instali Java SE 15-konstruaĵoj (JDK, JRE kaj Server JRE) por Linukso (x86_64), Vindozo kaj macOS. Referenca efektivigo evoluigita per la OpenJDK-projekto estas plene malfermita fonto laŭ la permesilo GPLv2, kun GNU ClassPath-esceptoj permesantaj dinamikan ligon kun komercaj produktoj.
Java SE 15 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 11, kiu daŭre ricevos ĝisdatigojn ĝis 2026. La antaŭa LTS-filio de Java 8 estos subtenata ĝis decembro 2020. La venonta LTS-eldono estas planita por septembro 2021. 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.
De :
- subteno por la EdDSA (Edwards-Curve Digital Signature Algorithm) cifereca subskriba kreadalgoritmo ). La proponita EdDSA-efektivigo ne dependas de hardvarplatformoj, estas protektita kontraŭ flankkanalaj atakoj (konstanta tempo de ĉiuj kalkuloj estas certigita) kaj estas pli rapida en efikeco ol la ekzistanta ECDSA-efektivigo skribita en C-lingvo, kun la sama nivelo de protekto. Ekzemple, EdDSA uzanta elipsan kurbon kun 126-bita ŝlosilo elmontras similan efikecon al ECDSA kun secp256r1 elipsa kurbo kaj 128-bita ŝlosilo.
- eksperimenta subteno por sigelitaj klasoj kaj interfacoj, kiuj ne povas esti uzataj de aliaj klasoj kaj interfacoj por heredi, etendi aŭ superregi la efektivigon. Sigelitaj klasoj ankaŭ disponigas pli deklaran manieron limigi la uzon de superklaso ol alirmodifiloj, surbaze de eksplicite listigado de la subklasoj permesitaj por etendaĵo.
pako com.example.geometry;
publika sigelita klaso Formo
permesas com.example.polar.Circle,
com.example.quad.Rektangulo,
com.example.quad.simple.Kvadrato {…} - subteno por kaŝitaj klasoj kiuj ne povas esti uzataj rekte per la bajtokodo de aliaj klasoj. La ŝlosila celo de kaŝitaj klasoj estas uzota en kadroj kiuj dinamike generas klasojn ĉe rultempo kaj uzas ilin nerekte, tra . Tiaj klasoj kutime havas limigitan vivociklon, do konservi ilin por aliro de statike generitaj klasoj ne estas pravigita kaj nur kondukos al pliigita memorkonsumo. Kaŝitaj klasoj ankaŭ forigas la bezonon de la ne-norma API sun.misc.Unsafe::defineAnonymousClass, kiu estas planita por forigo en la estonteco.
- La rubkolektisto ZGC (Z Rubokolektisto) estis stabiligita kaj estas rekonita kiel preta por ĝeneraligita uzo. ZGC funkcias en pasiva reĝimo, minimumigas latentecon pro rubkolekto kiel eble plej multe (halta tempo kiam uzado de ZGC ne superas 10 ms.) kaj povas funkcii kun kaj malgrandaj kaj grandegaj amasoj, intervalante en grandeco de kelkcent megabajtoj ĝis multaj terabajtoj.
- Stabiligita kaj trovita preta por ĝenerala uzo
rubokolektisto , laborante kun minimumaj paŭzoj (Malalta-Paŭzo-Tempo Rubo Kolekto). Shenandoah estis evoluigita fare de Red Hat kaj estas rimarkinda pro ĝia uzo de algoritmo kiu reduktas la bloktempon dum rubkolekto rulante purigadon paralele kun la ekzekuto de Java-aplikoj. La grandeco de la prokrastoj enkondukitaj de la rubkolektanto estas antaŭvidebla kaj ne dependas de la grandeco de la amaso, t.e. por amasoj de 200 MB kaj 200 GB la prokrastoj estos identaj ( preter 50 ms kaj kutime ene de 10 ms); - Subteno estas stabiligita kaj enkondukita en la lingvon - nova formo de ĉenaj literoj, kiu ebligas al vi inkluzivi plurliniajn tekstajn datumojn en la fontkodo sen uzi signan eskapon kaj konservi la originalan tekstformaton en la bloko. La bloko estas enkadrigita per tri citiloj.
Ekzemple, anstataŭ kodo
Ŝnuro html = " » +
"\n\t" + " » +
"\n\t\t" + " \"Java 1 estas ĉi tie!\" » +
"\n\t" + " » +
"\n" + " ";vi povas specifi:
String html = """
»Java 1\
estas ĉi tie!
"""; - Heredaĵo DatagramSocket API. La malnovaj efektivigoj de java.net.DatagramSocket kaj java.net.MulticastSocket estis anstataŭigitaj per moderna efektivigo kiu estas pli facile sencimigi kaj konservi, kaj ankaŭ estas kongrua kun virtualaj fluoj evoluigitaj ene de la projekto. . En kazo de ebla nekongruo kun ekzistanta kodo, la malnova efektivigo ne estis forigita kaj povas esti ebligita per la opcio jdk.net.usePlainDatagramSocketImpl.
- Dua eksperimenta efektivigo proponita en la "instanceof" operatoro, kiu permesas vin tuj difini lokan variablon por aliri la kontrolitan valoron. Ekzemple, vi povas tuj skribi "se (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}" sen eksplicite difini "String s = (String) obj".
Estis:
if (obj instanceof Group) {
Grupo grupo = (Group)obj;
var enskriboj = group.getEntries ();
}Nun vi povas malhavi la difinon "Grupo = (Grupo) obj":
if (obj instanceof Grupo grupo) {
var enskriboj = group.getEntries ();
} - dua eksperimenta efektivigo de la ŝlosilvorto "", kiu provizas kompaktan formon por difini klasojn, ebligante al vi eviti eksplicite difini diversajn malaltnivelajn metodojn kiel equals(), hashCode() kaj toString() en kazoj kie datumoj estas stokitaj nur en kampoj kies konduto ne ŝanĝiĝas. Kiam klaso uzas normajn efektivigojn de la metodoj equals(), hashCode() kaj toString(), ĝi povas fari sen ilia eksplicita difino:
publika rekordo BankTransaction (LocalDate dato,
duobla kvanto
Ĉenpriskribo) {}Ĉi tiu deklaro aŭtomate aldonos efektivigojn de la metodoj equals(), hashCode() kaj toString() krom la metodoj konstruktilo kaj getter.
- dua antaŭprezento de la Foreign-Memory Access API, permesante al Java aplikoj sekure kaj efike aliri memorregionojn ekster la Java amaso manipulante la novajn abstraktaĵojn MemorySegment, MemoryAddress kaj MemoryLayout.
- kaj malrekomendis la Biased Locking-optimumigan teknikon uzitan en la HotSpot JVM por redukti ŝlosadon supre. Ĉi tiu tekniko perdis sian signifon en sistemoj kun atomaj instrukcioj disponigitaj de modernaj CPUoj, kaj estas tro labor-intensa por konservi pro sia komplekseco.
- malmoderna mekanismo , kiu estos forigita en estonta eldono. Oni rimarkas, ke RMI-Aktivigo estas malmoderna, forigita al la kategorio de opcio en Java 8 kaj preskaŭ neniam estas uzata en moderna praktiko.
- JavaScript-motoro , kiu estis malrekomendita en Java SE 11.
- havenoj por Solaris OS kaj SPARC-procesoroj (Solaris/SPARC, Solaris/x64 kaj Linukso/SPARC). Forigi ĉi tiujn havenojn permesos al la komunumo akceli la disvolviĝon de novaj funkcioj de OpenJDK sen perdi tempon konservante specifajn funkciojn de Solaris kaj SPARC.
fonto: opennet.ru