Java Development Kit (JDK) 11 er nu generelt tilgængeligt og klar til produktion, hvilket giver produktivitetsforbedringer og en HTTP-klient-API, der implementerer HTTP / 2.
Version 11 af Java Standard Edition (SE) har 16 store funktionsændringer. Java 11 mister også nogle funktioner gennem fjernelse af CORBA- og Java EE-moduler (for nylig omdøbt til Jakarta EE) samt fjernelse af JavaFX, som nu er tilgængelig som en enkeltstående teknologi.
I Java 11 har Oracle forked hovedlinjelageret, jdk / jdk, til jdk / jdk11 stabiliseringsregisteret. Ændringer skubbet til jdk / jdk eller jdk / client er nu markeret for JDK 12. Stabiliseringsregistret kan acceptere udvalgte fejlrettelser og, hvis de er godkendt, sene forbedringer i henhold til JDK-frigørelsesprocessen.
Den seneste version af Oracles implementering af standard Java er en Long Term Support (LTS) -udgivelse, som vil have kommerciel support fra Oracle i mindst otte år. Fejlrettelser og sikkerhedsopdateringer vil blive tilbudt gennem 2026. Nye LTS-udgivelser forventes hvert tredje år, hvor JDK 17, der forventes i 2021, er den næste LTS-udgivelse. Midlertidige udgivelser kommer hver sjette måned.
Hvor downloades JDK 11
Du kan downloade JDK 11 fra Oracle Technology Network.
Nye funktioner i Java 11 JDK
JDK 11 har 16 nye funktioner:
- Forbedring af Aarch64-iboende egenskaber med implementeringen af nye iboende egenskaber til
lang.Mathsin-, cos- og logfunktioner på Aarch64-processorer. Dette forslag understreger specialiserede CPU-arkitektur-specifikke kodemønstre, der forbedrer applikations- og benchmark-ydeevne. - Nestbaseret adgangskontrol introducerer reder, en adgangskontrolkontekst, der stemmer overens med begrebet indlejrede typer på Java-sproget. Reder tillader klasser, der logisk er en del af den samme kodeenhed, men er kompileret til forskellige klassefiler for at få adgang til hinandens private medlemmer uden at have behov for kompilatorer for at indsætte tilgængelighedsudvidende brometoder.
- Transport Layer Security (TLS) 1.3, hvor denne revision af TLS-protokollen vil blive monteret i JDK 11, hvilket giver betydelige fordele ved sikkerhed og ydeevne. Der er dog ikke noget mål at understøtte alle funktioner i TLS 1.3. For at minimere risikoen for inkompatibilitet implementerer TLS 1.3 som standard bagudkompatibilitetstilstand. Applikationer kan slå denne tilstand til eller fra som ønsket.
- Forældelse af Nashorn JavaScript-motoren sammen med JJS-værktøjet med det formål at fjerne dem i fremtiden. Oracle har fundet Nashorn udfordrende at vedligeholde i betragtning af det hurtige tempo, hvormed ECMAScript-sprogkonstruktioner og API'er er blevet tilpasset og ændret.
- HTTP-klient (Standard), som standardiserer den inkuberede HTTP API-klient, der blev introduceret i JDK 9 og opdateret i JDK 10. API'en tilbyder ikke-blokering af anmodnings- og svarsemantik gennem
Fuldførte fremtider, som kan linkes til at udløse afhængige handlinger. Implementeringen, nu asynkron, er næsten fuldstændig omskrevet efter inkubering i JDKs 9 og 10. RX Flow-konceptet er skubbet ind i implementeringen, hvilket eliminerer mange brugerdefinerede koncepter, der er nødvendige for at understøtte HTTP / 2. Datastrømmen kan nu nemmere spores fra forespørgselsudgivere på brugerniveau og udgivere til svar til den underliggende sokkel. Dette reducerer kompleksiteten og maksimerer muligheden for genbrug mellem HTTP / 1 og HTTP / 2. - Epsilon-affaldssamleren, faktureret som en "no-op" -opsamler, vil håndtere hukommelsestildeling uden at implementere nogen faktisk hukommelsesgenvindingsmekanismer. Epsilons brugstilfælde inkluderer test for ydeevne, hukommelsestryk og grænsefladen til den virtuelle maskine. Det kunne også bruges til kortvarige job.
- En lokal-variabel syntaks for lambda-parametre skal tilpasse syntaxen for en formel parameterdeklaration i et implicit skrevet udtryk med syntaxen for en lokal variabel-deklaration. Dette ville tillade
varskal bruges ved erklæring af formelle parametre for implicit typede lambda-udtryk. - Java-klassefilformatet udvides til at understøtte en ny konstant poolform,
CONSTANT_Dynamic. Målet er at reducere omkostningerne og forstyrrelsen ved at udvikle nye former for materialiserbare klassefilbegrænsninger. - Nøgleaftale med Curve25519 og Curve448-kryptografi skal være mere effektiv og sikker end den eksisterende elliptiske kurve Diffie-Hellman-ordning. De to elliptiske kurver, Curve25510 og Curve448, egner sig til en konstant tidsimplementering og en undtagelsesfri skalar multiplikation, der er mere modstandsdygtig over for en række sidekanalangreb, herunder timing og cache-angreb, ifølge IETF. Forslagets mål inkluderer en API og implementering af nøgleaftaleordningen samt udvikling af en platformuafhængig, all-Java-implementering. Der er dog en risiko for kompleksiteten og subtiliteten i den modulære aritmetiske implementering, der fremgår af forslaget.
- Flight Recorder ville give en ramme for dataindsamling med lave omkostninger til fejlfinding af både Java-applikationer og HotSpot JVM. Flight Recorder har været et træk ved Oracle's kommercielle JDK, men ville få sin kildekode til at flytte til et åbent lager for at gøre funktionen generelt tilgængelig. Iclouded ville være API'erne til at producere og forbruge data som begivenheder, der giver en buffermekanisme og binært dataformat og muliggør konfiguration og filtrering af begivenheder. Forslaget opfordrer også til at levere begivenheder til OS-, HotSpot- og JDK-bibliotekerne.
- Opgradering af platformens API'er til understøttelse af Unicode version 10.0 og dermed Java opdateret. Support forventes i følgende klasser:
KarakterogSnorilangpakkeNumericShaperiawt.fontpakkeBidi,BreakIteratorogNormaliseringitekstpakke- Implementering af de kryptografiske algoritmer fra ChaCha20 og Poly1305. ChaCha2020 er en relativt ny stream-chiffer, der kan erstatte den ældre, usikre R4-stream-chiffer. ChaCha20 vil blive parret med Poly1305-godkenderen. ChaCha20- og ChaCha20-Poly1305-chifferimplementeringer vil blive leveret med algoritmerne implementeret i SunJCE (Java Cryptography Extension) -udbyderen ved hjælp af
crypto.CipherSpiAPI. - Forbedring af Java-launcheren til at køre et program leveret som en enkelt fil med Java-kildekode, så disse programmer kan køre direkte fra kilden. Programmer med en fil er almindelige, når man skriver små hjælpeprogrammer eller for udviklere i de tidlige stadier af Java-læring. En enkelt kildefil kan også kompileres til flere klassefiler, hvilket tilføjer emballageomkostninger. I disse sammenhænge er det bare et unødvendigt trin, der er baseret på tradition, at skulle kompilere et program, før det køres.
- Profilering med lav overhead-bunke, der giver en måde at prøve Java-bunkeallokeringer på, der er tilgængelig via JVM Tool Interface. Målet med denne indsats er at få information om disse tildelinger på en måde, der er lavt overhead, kan fås via en programmatisk grænseflade og kan prøve alle tildelinger. Implementeringsuafhængighed og levering af data om levende og døde dynger er også mål. Dårlig bunkehåndtering kan føre til bunkeudmattelse og affaldsindsamling. De fleste værktøjer, der løser dette, mangler opkaldswebstedet til bestemte tildelinger, oplysninger, der kan være kritiske for fejlretning af hukommelsesproblemer.
- Afvikling af Pack200- og Unpack200-værktøjer og Pack200 API i
util.jar. Pack200 er et komprimeringsskema for .jar-filer, der er beregnet til at mindske krav til disk og båndbredde til applikationsemballage, transmission og levering. Vedligeholdelsesomkostningerne og den lave forbrug berettiger ikke deres tilbageholdelse, siger projektledere. - Z Garbage Collector (ZGC), en eksperimentel affaldssamler med lav latens, til at håndtere dynger, der spænder fra relativt små til meget store dynger, der er mange terabyte i størrelse. Ved at bruge ZGC bør pausetider ikke overstige 10 ms, og der bør ikke være mere end 15 procent reduktion af applikationsgennemstrømning sammenlignet med brug af G1-samleren. ZGC lægger også et fundament for fremtidige funktioner og optimeringer. Linux / x64 vil være den første platform, der får ZGC-support.
Hvad er fjernet fra Java JDK 11
Java EE EE- og CORBA-modulerne blev udfaset i Java SE 9 med den hensigt at fjerne dem i en senere udgivelse - som er JDK 11.
Java SE 6, der blev udgivet i december 2006, havde inkluderet en komplet webtjenestestak til fordel for udviklere - inklusive fire teknologier bygget til Java EE-platformen: JAX-WS (Java API til XML-baserede webservices, JAXB (Java Architecture XML Binding), JAF (JavaBeans Activation Framework) og Common Annotations for Java. Java EE-versionerne udviklede sig over tid, hvilket førte til vanskeligheder i Java SE, såsom at inkludere teknologier, der er irrelevante for Java SE og vanskeligere vedligeholdelse på tværs af de to Java Med selvstændige versioner af Java EE-teknologier, der er tilgængelige fra tredjepartswebsteder, siger Oracle, at der ikke længere er behov for at have dem i Java SE eller i JDK.
Stadig vil nogle applikationer ikke kompilere eller køre, hvis de er afhængige af out-of-the-box support i JDK til Java EE API'er og værktøjer. Binær og kilde uforenelighed ville opstå, når JDK 6, 7 eller 8 overføres til en senere udgivelse. Oracle siger, at udviklere, der er ramt af disse risici, i stedet kan implementere alternative versioner af Java EE-teknologier.
CORBA dateres tilbage til 1990'erne, og Oracle siger, at der i dag ikke er nogen væsentlig interesse i at udvikle moderne Java-applikationer med CORBA. Og omkostningerne ved at opretholde CORBA-support opvejer de resterende fordele.
Men fjernelsen af CORBA risikerer at have CORBA-implementeringer, der ikke kører, hvis de kun inkluderer en delmængde af CORBA API'er og forventer, at JDK leverer resten. Der er ingen CORBA-version fra tredjepart, og det er usikkert, om en tredjepart kan overtage CORBA API-vedligeholdelse.
JavaFX fjernes, så det ikke er bundet til Java JDKs opdateringsplan to gange årligt.
