Java Development Kit (JDK) 11 er nå generelt tilgjengelig og klar til bruk i produksjonen, og gir produktivitetsforbedringer og en HTTP-klient-API som implementerer HTTP / 2.
Versjon 11 av Java Standard Edition (SE) har 16 store funksjonsendringer. Java 11 mister også noen muligheter gjennom fjerning av CORBA og Java EE (nylig omdøpt Jakarta EE) moduler, samt fjerning av JavaFX, som nå er tilgjengelig som en frittstående teknologi.
I Java 11 har Oracle gaffelt hovedlinjelageret, jdk / jdk, til stabiliseringsregisteret jdk / jdk11. Endringer presset til jdk / jdk eller jdk / client er nå merket for JDK 12. Stabiliseringsregisteret kan godta utvalgte feilrettinger og, hvis godkjent, sene forbedringer i henhold til JDK-utgivelsesprosessen.
Den siste versjonen av Oracles implementering av standard Java er en Long Term Support (LTS) -utgivelse, som vil ha kommersiell støtte fra Oracle i minst åtte år. Feilrettinger og sikkerhetsoppdateringer vil bli tilbudt gjennom 2026. Nye LTS-utgivelser forfaller hvert tredje år, med JDK 17, som forfaller i 2021, som den neste LTS-utgivelsen. Midlertidige utgivelser kommer hver sjette måned.
Hvor laster du ned JDK 11
Du kan laste ned JDK 11 fra Oracle Technology Network.
Nye funksjoner i Java 11 JDK
JDK 11 har 16 nye funksjoner:
- Forbedring av Aarch64-egenskapen, med implementering av ny egenart for
lang.Mathsin-, cos- og log-funksjoner, på Aarch64-prosessorer. Dette forslaget legger vekt på spesialiserte CPU-arkitektur-spesifikke kodemønstre som forbedrer applikasjons- og referanseytelsen. - Nest-basert tilgangskontroll introduserer reir, en tilgangskontrollkontekst som samsvarer med forestillingen om nestede typer på Java-språket. Reir tillater klasser som logisk sett er en del av samme kodeenhet, men som er kompilert til forskjellige klassefiler for å få tilgang til hverandres private medlemmer uten at kompilatorer trenger å sette inn tilgjengelighetsutvidende brometoder.
- Transport Layer Security (TLS) 1.3, hvor denne overhalingen av TLS-protokollen blir montert i JDK 11, og gir betydelige fordeler med sikkerhet og ytelse. Det er imidlertid ikke noe mål å støtte alle funksjonene i TLS 1.3. For å minimere risikoen for inkompatibilitet vil TLS 1.3 implementere bakoverkompatibilitetsmodus som standard. Programmer kan slå denne modusen av eller på etter ønske.
- Avvikling av Nashorn JavaScript-motoren, sammen med JJS-verktøyet, med den hensikt å fjerne dem i fremtiden. Oracle har funnet Nashorn utfordrende å opprettholde, gitt det raske tempoet som ECMAScript-språkkonstruksjoner og API-er har blitt tilpasset og modifisert.
- HTTP Client (Standard), som standardiserer den inkuberte HTTP API-klienten introdusert i JDK 9 og oppdatert i JDK 10. API tilbyr non-blocking forespørsel og respons semantikk gjennom
Fullførbare fremtider, som kan knyttes til utløsende avhengige handlinger. Implementeringen, nå asynkron, har blitt nesten fullstendig omskrevet etter inkubering i JDK 9 og 10. RX Flow-konseptet er blitt presset inn i implementeringen, og eliminerer mange tilpassede konsepter som trengs for å støtte HTTP / 2. Datastrømmen kan nå lettere spores, fra forespørgselsutgivere på brukernivå og responsutgivere til den underliggende kontakten. Dette reduserer kompleksiteten og maksimerer muligheten for gjenbruk mellom HTTP / 1 og HTTP / 2. - Epsilon-søppeloppsamleren, fakturert som en "no-op" -samler, vil håndtere minnetildeling uten å implementere noen faktiske minnegjenvinningsmekanismer. Epsilons brukstilfeller inkluderer testing for ytelse, minnetrykk og det virtuelle maskingrensesnittet. Det kan også brukes til kortvarige jobber.
- En lokal-variabel syntaks for lambda-parametere bør justere syntaksen til en formell parametererklæring i et implisitt skrevet uttrykk med syntaksen til en lokal variabelerklæring. Dette ville tillate
varsom skal brukes når deklarerer formelle parametere for et implisitt skrevet lambdauttrykk. - Java-klassefilformatet utvides til å støtte en ny konstant bassengform,
CONSTANT_Dynamic. Målet er å redusere kostnadene og forstyrrelsene ved å utvikle nye former for materialiserbare klassefilbegrensninger. - Nøkkelavtale med Curve25519 og Curve448 kryptografi bør være mer effektiv og sikker enn den eksisterende elliptiske kurven Diffie-Hellman-ordningen. De to elliptiske kurvene, Curve25510 og Curve448, gir seg en konstant implementering og en unntaksfri skalar multiplikasjon som er mer motstandsdyktig mot en rekke sidekanalangrep, inkludert timing og cacheangrep, ifølge IETF. Målet med forslaget inkluderer en API og implementering av ordningen med nøkkelavtaler, samt utvikling av en plattformuavhengig, all-Java-implementering. Det er imidlertid en risiko i kompleksiteten og subtiliteten i den modulære aritmetiske implementeringen som er omtalt som en del av forslaget.
- Flight Recorder vil gi et rammeverk for datainnsamling med lav overhead for feilsøking av både Java-applikasjoner og HotSpot JVM. Flight Recorder har vært en funksjon i Oracles kommersielle JDK, men vil ha kildekoden flyttet til et åpent depot for å gjøre funksjonen generelt tilgjengelig. Iclouded vil være APIene for å produsere og konsumere data som hendelser, og gir en buffermekanisme og binært dataformat og muliggjør konfigurering og filtrering av hendelser. Forslaget krever også arrangementer for OS-, HotSpot- og JDK-bibliotekene.
- Oppgradering av plattformens APIer for å støtte Unicode versjon 10.0, og dermed holde Java oppdatert. Det forventes støtte i følgende klasser:
KarakterogStringilangpakkeNumericShaperiawt.fontpakkeBidi,BreakIterator, ogNormaliseringitekstpakke- Implementering av de kryptografiske algoritmene ChaCha20 og Poly1305. ChaCha2020 er en relativt ny strømkryptering som kan erstatte den eldre, usikre R4-strømkrypteringen. ChaCha20 vil være sammenkoblet med Poly1305-autentisatoren. ChaCha20- og ChaCha20-Poly1305-krypteringsimplementeringer vil bli gitt, med algoritmene implementert i SunJCE (Java Cryptography Extension) -leverandøren, ved hjelp av
crypto.CipherSpiAPI. - Forbedre Java-lanseringen for å kjøre et program som leveres som en enkelt fil med Java-kildekode, slik at disse programmene kan kjøres direkte fra kilden. Programmer med en fil er vanlige når du skriver små verktøy eller for utviklere i de tidlige stadiene av å lære Java. En enkelt kildefil kan også kompileres til flere klassefiler, som legger til emballasjekostnader. I disse sammenhengene er det bare et unødvendig trinn basert på tradisjon å måtte kompilere et program før det kjøres.
- Profesjonell dybde med lav overhead, som gir en måte å prøve Java-haugetildelinger, tilgjengelig via JVM Tool Interface. Målet med denne innsatsen er å få informasjon om disse tildelingene på en måte som er lavt overhead, kan nås via et programmatisk grensesnitt og kan prøve alle tildelinger. Implementeringsuavhengighet og levering av data om levende og døde dynger er også mål. Dårlig haugestyring kan føre til haugutmattelse og søppeloppsamling. De fleste verktøy som løser dette, mangler anropssiden for bestemte tildelinger, informasjon som kan være avgjørende for feilsøking av minneproblemer.
- Avvikling av Pack200 og Unpack200 verktøy og Pack200 API i
util.jar. Pack200 er et komprimeringsskjema for .jar-filer, beregnet på å redusere krav til disk og båndbredde for applikasjonsemballasje, overføring og levering. Vedlikeholdskostnadene og lav bruk rettferdiggjør ikke oppbevaring, sier prosjektledere. - Z Garbage Collector (ZGC), en eksperimentell søppeloppsamler med lav latens, for å håndtere dynger fra relativt små til veldig store dynger som er mange terabyte i størrelse. Ved å bruke ZGC, bør pausetider ikke overstige 10 ms, og det bør ikke være mer enn 15 prosent reduksjon i applikasjonsgjennomstrømning sammenlignet med bruk av G1-samleren. ZGC legger også grunnlag for fremtidige funksjoner og optimaliseringer. Linux / x64 vil være den første plattformen som får ZGC-støtte.
Hva er fjernet fra Java JDK 11
Java EE EE og CORBA-modulene ble avviklet i Java SE 9, med den hensikt å fjerne dem i en senere utgivelse — som er JDK 11.
Java SE 6, utgitt i desember 2006, hadde tatt med en full webtjenestestabel for utviklernes bekvemmelighet - inkludert fire teknologier bygget for Java EE-plattformen: JAX-WS (Java API for XML-baserte Web Services, JAXB (Java Architecture for XML Binding), JAF (JavaBeans Activation Framework) og Common Annotations for Java. Over tid utviklet Java EE-versjonene seg, noe som førte til vanskeligheter i Java SE, som å inkludere teknologier som er irrelevante for Java SE og vanskeligere vedlikehold over de to Java Med frittstående versjoner av Java EE-teknologiene tilgjengelig fra tredjepartssider, sier Oracle at det ikke lenger er behov for å ha dem i Java SE eller i JDK.
Noen applikasjoner vil likevel ikke kompileres eller kjøres hvis de er avhengige av støtte utenom boksen i JDK for Java EE APIer og verktøy. Binær og kilde inkompatibilitet ville oppstå når du migrerer JDK 6, 7 eller 8 til en senere utgivelse. Oracle sier at utviklere som er berørt av disse risikoene, kan distribuere alternative versjoner av Java EE-teknologier i stedet.
CORBA dateres tilbake til 1990-tallet, og Oracle sier at det i dag ikke er noen betydelig interesse for å utvikle moderne Java-applikasjoner med CORBA. Og kostnadene ved å opprettholde CORBA-støtte oppveier de gjenværende fordelene.
Men fjerning av CORBA risikerer å ha CORBA-implementeringer som ikke vil kjøre hvis de bare inkluderer en delmengde av CORBA APIer og forventer at JDK vil gi resten. Det er ingen CORBA-versjon fra tredjepart, og det er usikkert om en tredjepart kan overta vedlikehold av CORBA API.
JavaFX fjernes, slik at det ikke er knyttet til Java JDKs oppdateringsplan to ganger årlig.
