{"id":165062,"date":"2026-03-17T23:11:55","date_gmt":"2026-03-17T21:11:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-java-se-26-i-openjdk-26-proekt-po-integraczii-podderzhki-javascript-i-python-v-jvm"},"modified":"2026-03-17T23:11:55","modified_gmt":"2026-03-17T21:11:55","slug":"vypusk-java-se-26-i-openjdk-26-proekt-po-integraczii-podderzhki-javascript-i-python-v-jvm","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/news\/vypusk-java-se-26-i-openjdk-26-proekt-po-integraczii-podderzhki-javascript-i-python-v-jvm","title":{"rendered":"Utgivelse av Java SE 26 og OpenJDK 26. Prosjektet for integrering av JavaScript- og Python-st\u00f8tte i JVM.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Etter seks m\u00e5neder med utvikling har Oracle publisert Java SE 26 (Java Platform, Standard Edition 26), hvor den referanseimplementasjonen benytter det \u00e5pne prosjektet OpenJDK. Bortsett fra fjerning av noen utdaterte funksjoner, bevarer Java SE 26 bakoverkompatibilitet med tidligere utgivelser av Java-plattformen \u2014 de fleste tidligere Java-prosjekter vil kunne kj\u00f8res uten endringer p\u00e5 den nye versjonen. Klargjorte installasjonsbygg for Java SE 26 (JDK, JRE og Server JRE) er tilgjengelige for Linux (x86_64, AArch64), Windows (x86_64) og macOS (x86_64, AArch64). Referanseimplementasjonen av Java SE 26, utviklet gjennom OpenJDK-prosjektet, er helt \u00e5pen under GPLv2-lisensen med unntak for GNU ClassPath, som tillater dynamisk lenking med kommersielle produkter. <\/p>\n
Java SE 26 er klassifisert som en utgivelse med vanlig st\u00f8tte, der oppdateringer vil bli utgitt frem til neste utgivelse. For langvarig st\u00f8tte (LTS) b\u00f8r Java SE 25, Java SE 21 eller Java SE 17 brukes, med oppdateringer som vil bli utgitt fram til henholdsvis 2033, 2031 og 2029 (offentlige oppdateringer \u2013 frem til september 2030, 2028 og 2026). Den utvidede st\u00f8tten for LTS-grenen av Java SE 8 vil vare til 2030, mens Java SE 11 vil vare til 2032. <\/p>\n
Blant endringene i Java SE 26 (1, 2, 3, 4): <\/p>\n
\n
Det er implementert varsler ved bruk av dyp refleksjon for \u00e5 endre felt merket med n\u00f8kkelordet \u00abfinal\u00bb. I fremtiden planlegges det \u00e5 deaktivere usikre spr\u00e5kfunksjoner som standard, og blant annet gj\u00f8re felt merket som final helt uforanderlige ved \u00e5 fjerne omg\u00e5else for \u00e5 endre dem gjennom dyp refleksjon (API Reflection).\n
API Applet (java.applet.Applet*, javax.swing.JApplet) er fjernet, som ble brukt til \u00e5 kj\u00f8re Java-applikasjoner i nettleseren. Dette API-et mistet relevans etter at Java-plugin-st\u00f8tten for nettlesere ble avsluttet og ble erkl\u00e6rt utdaterte i 2021.\n
En mulighet til \u00e5 bruke forh\u00e5ndsbygget cache (AOT \u2013 ahead-of-time) med alle s\u00f8ppelinnsamlere er implementert, inkludert ZGC (Z Garbage Collector). Endringen inneb\u00e6rer st\u00f8tte for sekvensiell lasting av forh\u00e5ndslagrerede Java-objekter i minne, ved bruk av et universelt og uavhengig format for s\u00f8ppelinnsamlere i stedet for direkte kartlegging til minnet av spesifikke cache-representasjoner. Bruken av AOT-cache reduserer oppstartstiden og akselererer oppvarmingen (warmup) av HotSpot-maskinvarevirtuell maskin.\n
I HTTP Client API er det lagt til st\u00f8tte for HTTP\/3-protokollen, noe som lar applikasjoner og biblioteker kontakte servere via HTTP\/3 etter minimale endringer i koden.\n
Ytelsen til G1-s\u00f8ppeloppsamleren er forbedret ved \u00e5 redusere blokkeringer for synkronisering av applikasjonstr\u00e5der med s\u00f8ppeloppsamlertr\u00e5der.\n
Det er foresl\u00e5tt en annen forh\u00e5ndsversjon av API for koding og avkoding av objekter med kryptografiske n\u00f8kler, sertifikater og lister over tilbakekalte sertifikater, ved \u00e5 bruke PEM-formatet (Pivacy-Enhanced Mail).\n
Det er foresl\u00e5tt for testing en sjette forh\u00e5ndsversjon av API for strukturert parallellitet (Structured Concurrency), som forenkler utviklingen av flertr\u00e5dede applikasjoner ved \u00e5 behandle flere oppgaver som utf\u00f8res i forskjellige tr\u00e5der som en enkelt blokk.\n
Den andre forel\u00f8pige utgaven av API Lazy Constants er lagt til for arbeid med objekter som inneholder uforanderlige data og behandles i JVM som konstanter. Slike objekter f\u00e5r ytelsesoptimaliseringer som ligner p\u00e5 felt med n\u00f8kkelordet \u00abfinal\u00bb. I motsetning til \u00abfinal\u00bb skiller det nye API-et mellom oppretting av permanente verdier og deres initialisering, garanterer at verdien kan initialiseres bare \u00e9n gang, reduserer oppstartstiden for programmer og gj\u00f8r det mulig \u00e5 bruke optimaliseringer for konstantfolding i brukerens kode, som tidligere bare ble brukt i JDKs interne kode. class Application { \/\/ F\u00f8r: \/\/ static final UserService USERS = new UserService(); \/\/ N\u00e5 kan man: static final StableValue USERS = StableValue.of(); public static UserService users() { return USERS.orElseSet(UserService::new); } }\n
I m\u00f8nster-matching-mekanismen foresl\u00e5s det en fjerde forel\u00f8pig versjon av muligheten til \u00e5 bruke primitive typer (int, byte, char og andre grunnleggende typer som ikke er objekter) i alle typer m\u00f8nstre, i operatoren \u00abinstanceof\u00bb og i \u00abswitch\u00bb-blokker. switch (x.getStatus()) { case 0 -> \u00abokay\u00bb; case 1 -> \u00abwarning\u00bb; case 2 -> \u00aberror\u00bb; case int i -> \u00abunknown status: \u00bb + i; } if (i instanceof byte b) { \u2026 b \u2026 }\n
Den ellevte testimplementeringen av API Vector er foresl\u00e5tt, som gir funksjoner for vektorberegninger som utf\u00f8res ved hjelp av vektorinstruksjoner for prosessorer x86_64 og AArch64, og som gj\u00f8r det mulig \u00e5 bruke operasjoner samtidig p\u00e5 flere verdier (SIMD). I motsetning til funksjonaliteten for autovektorisering av skalaroperasjoner som tilbys i JIT-kompilatoren HotSpot, gir det nye API-et mulighet for eksplisitt kontroll over vektoriseringen for parallell databehandling. <\/ul>\n
I tillegg har Oracle annonsert prosjektet Detroit, som vil utvikles innenfor OpenJDK og har som m\u00e5l \u00e5 forbedre portabilitet mellom Java, JavaScript og Python. I rammen av prosjektet planlegger de \u00e5 tilby muligheten for \u00e5 integrere med JVM-runtime-prosessen med JavaScript-motoren V8 og CPython-tolkeren. Tidligere utviklet Oracle JavaScript-motoren Nashorn, som fungerte p\u00e5 toppen av JVM, men la ned prosjektet p\u00e5 grunn av vanskeligheter med \u00e5 utvikle en separat implementering av JavaScript i en situasjon der hoved\u00f8kosystemet er basert p\u00e5 V8-motoren. <\/p>\n
Det er ogs\u00e5 verdt \u00e5 merke seg utgivelsen av oppdateringen for plattformen for \u00e5 lage JavaFX-applikasjoner 26. I l\u00f8pet av de n\u00e6rmeste timene forventes ogs\u00e5 utgivelsen av den universelle virtuelle maskinen GraalVM 26, som st\u00f8tter kj\u00f8ring av applikasjoner p\u00e5 JavaScript (Node.js), Python, Ruby, R, nevn alle spr\u00e5k for JVM (Java, Scala, Clojure, Kotlin), samt spr\u00e5k som kan generere LLVM-byttekode (C, C++, Rust). \n Kilde: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"