{"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\/da\/blog\/news\/vypusk-java-se-26-i-openjdk-26-proekt-po-integraczii-podderzhki-javascript-i-python-v-jvm","title":{"rendered":"Udgivelsen af Java SE 26 og OpenJDK 26. Projektet til integration af st\u00f8tte til JavaScript og Python i JVM.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Efter seks m\u00e5neders udvikling har Oracle offentliggjort platformen Java SE 26 (Java Platform, Standard Edition 26), hvor den \u00e5bne projekt OpenJDK anvendes som referenceimplementering. Bortset fra fjernelse af nogle for\u00e6ldede funktioner i Java SE 26 er bagudkompatibilitet med tidligere udgivelser af Java-platformen bevaret - de fleste tidligere skrevne Java-projekter vil fungere u\u00e6ndret, n\u00e5r de k\u00f8rer p\u00e5 den nye version. Installationsklare builds af Java SE 26 (JDK, JRE og Server JRE) er klar til Linux (x86_64, AArch64), Windows (x86_64) og macOS (x86_64, AArch64). Den referenceimplementering af Java SE 26, der er udviklet inden for OpenJDK-projektet, er helt \u00e5bent under GPLv2, med undtagelser fra GNU ClassPath, der tillader dynamisk linking med kommercielle produkter. <\/p>\n
Java SE 26 er klassificeret som en udgave med almindelig support, opdateringer vil blive udgivet indtil n\u00e6ste udgivelse. For en langtidssupport (LTS) version b\u00f8r Java SE 25, Java SE 21 eller Java SE 17 anvendes, hvor opdateringer vil blive lanceret indtil henholdsvis 2033, 2031 og 2029 (offentlige - indtil september 2030, 2028 og 2026). Den forl\u00e6ngede support af LTS-grenen Java SE 8 vil vedvare indtil 2030, mens Java SE 11 vil g\u00e5 ind til 2032. <\/p>\n
Blandt \u00e6ndringerne i Java SE 26 (1, 2, 3, 4): <\/p>\n
\n
Adgangen til advarsler ved brug af dyb refleksion til at \u00e6ndre felter, der er markeret med n\u00f8gleordet \u201efinal\u201c, er blevet implementeret. I fremtiden planl\u00e6gges det at deaktivere usikre sprogfunktioner som standard og blandt andet g\u00f8re felter, der er markeret som final, helt uforanderlige ved at fjerne omg\u00e5else for deres \u00e6ndring gennem dyb refleksion (API Reflection).\n
API Applet (java.applet.Applet*, javax.swing.JApplet) er blevet fjernet, da det blev anvendt til at k\u00f8re Java-programmer i browsere. Dette API mistede relevans efter oph\u00f8ret af st\u00f8tte til Java-plugin til browsere og blev erkl\u00e6ret for\u00e6ldet i 2021.\n
Muligheden for at anvende forudformateret cache (AOT - ahead-of-time) med enhver affaldssamler, inklusive ZGC (Z Garbage Collector), er blevet implementeret. \u00c6ndringen indeb\u00e6rer st\u00f8tte til sekventiel indl\u00e6sning af cachede Java-objekter til hukommelsen ved hj\u00e6lp af et generisk og uafh\u00e6ngigt af affaldssamlere format fremfor direkte mapping til hukommelsen af specifikke cache-repr\u00e6sentationer. Brug af AOT-cache reducerer opstartstiden og fremskynder opvarmningsprocessen (warmup) af HotSpot-maskinen.\n
Der er tilf\u00f8jet st\u00f8tte til HTTP\/3-protokollen i HTTP Client API, hvilket giver applikationer og biblioteker mulighed for at kommunikere med servere via HTTP\/3 efter minimale \u00e6ndringer i koden.\n
Ydelsen af G1 affaldsopsamleren er blevet forbedret ved at reducere blokeringerne for synkronisering af applikationstr\u00e5de med affaldsopsamlingsstr\u00e5de.\n
Et andet forh\u00e5ndsudgave API til kodning og dekodering af objekter med kryptografiske n\u00f8gler, certifikater og lister over tilbagekaldte certifikater er blevet foresl\u00e5et, ved hj\u00e6lp af PEM-formatet (Pivacy-Enhanced Mail).\n
Den sjette forh\u00e5ndsudgave API til struktureret parallelisme (Structured Concurrency) er blevet foresl\u00e5et til test, hvilket forenkler udviklingen af multitr\u00e5dede applikationer ved at behandle flere opgaver udf\u00f8rt i forskellige tr\u00e5de som en enkelt blok.\n
Den anden forel\u00f8bige udgave af API Lazy Constants er blevet tilf\u00f8jet til arbejdet med objekter, der indeholder uforanderlige data og behandles i JVM som konstanter. S\u00e5danne objekter underkastes ydeevneoptimeringer, der ligner de, der g\u00e6lder for felter med n\u00f8gleordet \u00abfinal\u00bb. I mods\u00e6tning til \u00abfinal\u00bb adskiller det nye API oprettelse af permanente v\u00e6rdier og deres initialisering, sikrer at v\u00e6rdien kun kan initialiseres \u00e9n gang, reducerer opstartstiden for programmer, og tillader anvendelse af konstantfoldning i brugerdefineret kode, som tidligere kun blev anvendt i den interne JDK-kode. class Application { \/\/ F\u00f8r: \/\/ static final UserService USERS = new UserService(); \/\/ Nu kan man: static final StableValue USERS = StableValue.of(); public static UserService users() { return USERS.orElseSet(UserService::new); } }\n
I m\u00f8nstermatchingsmekanismen er et fjerde forel\u00f8bigt forslag til muligheden for at bruge primitive typer (int, byte, char og andre grundl\u00e6ggende typer, der ikke er objekter) i alle slags skabeloner, i \u00abinstanceof\u00bb-operatoren og i \u00abswitch\u00bb-blokke. switch (x.getStatus()) { case 0 -> \u00abokay\u00bb; case 1 -> \u00abwarning\u00bb; case 2 -> \u00aberror\u00bb; case int i -> \u00abukendt status: \u00bb + i; } if (i instanceof byte b) { \u2026 b \u2026 }\n
Der er foresl\u00e5et en ellevte testimplementering af API Vector, der leverer funktioner til vektorberegninger, der udf\u00f8res ved hj\u00e6lp af vektorinstruktioner fra x86_64- og AArch64-processorer og muligg\u00f8r anvendelse af operationer p\u00e5 flere v\u00e6rdier samtidigt (SIMD). I mods\u00e6tning til de muligheder for automatiseret vektorisering af skalaroperationer, der tilbydes i JIT-kompilatoren HotSpot, giver det nye API mulighed for eksplicit styring af vektoriseringen til parallel databehandling. <\/ul>\n
Derudover har Oracle annonceret projekt Detroit, som vil blive udviklet som en del af OpenJDK og har til form\u00e5l at forbedre portabiliteten mellem Java, JavaScript og Python. Under projektet planl\u00e6gger man at give mulighed for indlejring i JVM-runtimeprocessen med JavaScript-motoren V8 og CPython-fortolkeren. Tidligere har Oracle allerede arbejdet p\u00e5 JavaScript-motoren Nashorn, der k\u00f8rer oven p\u00e5 JVM, men stoppede projektet p\u00e5 grund af vanskelighederne ved at udvikle en separat implementering af JavaScript i en situation, hvor hoved\u00f8kosystemet er bundet til V8-motoren. <\/p>\n
Det kan ogs\u00e5 n\u00e6vnes, at opdateringen af platformen til oprettelse af grafiske brugergr\u00e6nseflader JavaFX 26 er blevet offentliggjort. I l\u00f8bet af de n\u00e6ste timer forventes ogs\u00e5 udgivelsen af den universelle virtuelle maskine GraalVM 26, der underst\u00f8tter k\u00f8rsel af applikationer i JavaScript (Node.js), Python, Ruby, R, alle sprog til JVM (Java, Scala, Clojure, Kotlin) og sprog, for hvilke der kan genereres LLVM bitcode (C, C++, Rust). \n Kilde: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"