Long-Term-Support-versionen (LTS) af Java-sprog- og runtime-platformen Java 17 blev lanceret den 14. september 2021. Lad os lære, hvad der er nyt i Java 17, og om du bør opgradere.
Mange applikationer bruger ældre versioner af Java, inklusive de tidligere LTS-versioner af Java: Java 11 og Java 8.
Hvorfor skal virksomheder opgradere til den nyeste Java-version? Opgraderingen til Java 17 kræver indsats, primært for at få mest muligt ud af de nye funktioner og funktioner i JVM.
Mange virksomheder bruger Docker- og Docker-billeder til nemt at skifte til Java 17 med minimal indsats og tid. Udviklere kan definere deres kontinuerlige integration/implementering (CI/CD) pipelines og køre alt i Docker-images. Dette vil ikke påvirke andre teams, der bruger ældre Java-versioner, da de kan bruge gamle Docker-billeder.
Indholdsfortegnelse
JAVA 17 funktioner
macOS og AArch64-understøttelse
En af de kritiske JVM-funktioner, der er føjet til denne version, er at forbedre understøttelsen af macOS på AArch64-arkitekturen ved hjælp af JEP 391. Den vil understøtte den seneste serie af processorer (M1), som Apple har udgivet med deres computere i det sidste år.
Det er ikke nødvendigvis en stor sag for brugere på disse platforme, da nogle leverandører har lanceret versioner af JDK, der understøtter denne arkitektur og endda returnerer support op fra Java 8. Det officielle godkendelsesstempel er dog afgørende for at sikre fremtidig vedligeholdelse og support af platformen. Til sammenligning er understøttelse af Linux/AArch64-platformen tilføjet til Java 9 og Windows/AArch64 i Java 16.
Forseglede klasser
Forseglede klasser er en funktion, der blev introduceret i Java 17. Funktionen forseglede klasser har afsluttet sin prøvefase og er blevet en officiel platform og sprog i Java 17. Den tillader en udvikler at specificere de tilladte undertyper, som en type kan have og forhindre andre i at udvide eller implementere det på en måde, der ikke er tilsigtet.
Forseglede klasser giver også compileren mulighed for at generere fejl på kompileringstidspunktet, når du forsøger at konvertere en ikke-forseglet type til en ikke-tilladt undertype. Java 17 bringer også en ny gengivelsespipeline til AWT/Swing-apps, der kører på macOS ved hjælp af Apple Metal API i stedet for OpenGL. Det har en forbedret API og forbedrede funktioner til at generere tilfældige tal.
Ændringer, sletninger og begrænsninger i Java 17
Java 17 bringer også flere ændringer, sletninger og nye begrænsninger.
Indkapsling af JDK Internals
En ændring er konklusionen på indkapslingsprocessen for JDK Internals. Første gang dette blev introduceret var i Java 9 og ville give advarsler under kørsel, når en bruger forsøgte at bruge refleksion eller lignende for at omgå de sædvanlige begrænsninger for brug af interne API’er. Kommandolinjeargumenter blev også tilføjet for at regulere denne adfærd.
Fra Java 9 er der lavet forskellige API’er for at tilbyde en ensartet måde at udføre de mest almindeligt anvendte opgaver på; brugere ville bruge disse API’er internt. Med Java 16 blev standarden ændret fra en advarsel til at deaktivere adgang til at kaste en undtagelse. Den bruger dog kommandolinjeargumentet til at ændre adfærden.
Med Java 17 er kommandolinjeargumentet elimineret, og det er muligt at deaktivere denne begrænsning. Det betyder, at al ikke-autoriseret adgang til disse interne API’er nu er beskyttet.
Altid-streng svævende semantik
En yderligere “fjernelse” kan beskrives som genindførelsen af Always-Strict Floating Point semantik. Java 1.2 introducerede ændringer til flydende komma semantik standard i Java, der gør det muligt for JVM at handle med en lille mængde præcision i flydende komma beregninger for at forbedre ydeevnen. I klasser og metoder, hvor der skulle bruges streng semantik, blev der tilføjet et strictfp nøgleord. Siden da er forskellige instruktionssættyper blevet introduceret til CPU’erne, hvilket gør, at streng floating-point semantik kan bruges uden unødvendige omkostninger. Behovet for at implementere en standard eller streng semantik er blevet elimineret.
Java 17 fjerner den tidligere standardsemantik, og alle flydende kommaoperationer udføres strengt. Udtrykket strictfpis er stadig til stede. Det har dog ingen effekt og forårsager en advarsel på kompileringstidspunktet.
Forud for tid (AOT) kompilering
Java 9 introducerede ahead-of-time (AOT) kompilering som en eksperimentel funktion, der bruger Graal-kompileren, og en JIT-kode blev skrevet ved hjælp af Java. Java 10 gjorde Graal-kompileren anvendelig som en JIT-kompiler i OpenJDK ved at inkorporere JVMCI-grænsefladen. Siden den blev udgivet, har den været en stor forbedring. Graal compiler har set enorme fremskridt og har sin JVM under navnet GraalVM.
RMI aktivering
RMI-aktivering blev elimineret i JEP 407 efter dets fjernelse fra Java 8 og til sidst forældet og markeret som et krav for fjernelse i Java 15. RMI-aktivering gav en metode til at aktivere distribuerede objekter efter behov ved hjælp af RMI. Det blev dog brugt minimalt, og et bedre alternativ er tilgængeligt i dag. Resten af RMI er upåvirket af elimineringen af aktiveringsdelen.
Applet API fjernelse
Applet API er endelig blevet udpeget til fjernelse af JEP 398, oprindeligt fjernet i Java 9. Applet API’en gav en måde at integrere Java AWT/Swing-kontroller på en webside i en browser. Ingen moderne browser kan dog understøtte dette, hvilket betyder, at Applets i det væsentlige har været utilgængelige i løbet af det sidste årti eller deromkring.
Sikkerhedschef
Den mest afgørende afskrivning er, at det er sikkerhedschefen ( JEP 411). Security Manager har været i brug i et stykke tid siden Java 1.0. Det var designet til at begrænse, hvad Java kunne gøre lokalt på maskinen, såsom at begrænse adgangen til netværk, filer og andre netværksressourcer. Den forsøger også at sandboxe kode, der ikke er tillid til, ved at blokere refleksionen og specifikke API’er.
Slutningen af Security Manager startede i Java 12. Et kommandolinjeargument blev tilføjet for at blokere brugen af sikkerhedsmanageren under kørsel. Ændringen foretaget i Java 17 betyder, at en runtime-advarsel vil blive genereret i JVM’en, når du forsøger at indstille en Security Manager, enten fra kommandolinjen eller dynamisk under runtime.
Inkubator og forhåndsvisningsfunktioner
Mange spekulerede på, om Java 17 ville have nogen preview- og inkubatorfunktioner, i betragtning af at Java 17 blev forfremmet til at være en langsigtet understøttet version. Java 17 har to inkubatormoduler og en preview-funktion!
Vektor API
Vector API ( JEP 414) er i øjeblikket i sin anden fase af inkubatoren. API’et giver udviklere mulighed for at definere vektorberegning, som JIT-kompileren derefter vil konvertere til den passende vektorinstruktion, der understøttes af den CPU-arkitektur, som JVM’en kører på (f.eks. ved hjælp af SSE- eller AVX-instruktionssættene).
Før skulle udviklere bruge skalære funktioner eller bygge native biblioteker, der var specifikke for platformen. Implementering af Vector API i Java giver også en problemfri fallback-mekanisme, som var kompliceret i tidligere versioner.
Standardiseringen af Vector API gør det muligt for klasserne i JDK at bruge det. Java Arrays mismatch() metoder kunne ændres til at blive kørt på Java i stedet, hvilket eliminerer kravet om at vedligeholde og skrive flere platformsspecifikke implementeringer i JVM.
Foreign Function & Memory API
En ekstra inkubatorfunktion kaldes Foreign Function & Memory API ( JEP 412). Det er en udvikling og sammenlægning af to andre inkubatormoduler af Java 16, der er The Foreign Linker API ( JEP 389) og Foreign-Memory API ( JEP 393). Begge giver adgang til native hukommelse og kode ved at bruge statisk-type programmering skrevet i Java.
Mønstertilpasning til switch
Den sidste funktion af sprogeksemplet inkluderet i Java 17 er inkluderingen af Pattern Matching for Switch ( JEP 406). Denne sprogfunktion udvider switch-udtrykkene og -sætningerne efter type, svarende til den syntaks, der bruges gennem Pattern Matching (JEP 394), som blev standard med Java 16.
Tidligere, hvis du ønskede at udføre forskellige handlinger baseret på et objekts dynamiske karakter, ville du blive bedt om at konstruere en hvis-else-kæde ved hjælp af en forekomst af kontroller som:
String type(Object o) {
if (o instanceof List) {
return "A List of things.";
}
else if (o instanceof Map) {
return "A Map! It has keys and values.";
}
else if (o instanceof String) {
return "This is a string.";
}
else {
return "This is something else.";
}
}
Ved at kombinere switch-udtrykket samt den nye mønstertilpasningsfunktion for switches, kan processen reduceres til noget der ligner:
String type(Object o) {
return switch (o) {
case List l -> "A List of things.";
case Map m -> "A Map! It has keys and values.";
case String s -> "This is a string.";
default -> "This is something else.";
};
}
Som du måske har bemærket, er der erklæringen af en variabel i færd med at kontrollere. Ligesom de andre variabler i Pattern, indikerer matchningen af forekomst, at dette objekt blev typetjekket og castet og er tilgængeligt fra variablen inden for dets aktuelle område.
Preview-funktionen er endnu et skridt mod mønstermatchning. Det næste trin er at inkludere evnen til at dekonstruere arrays og poster.
Skal du opgradere til Java 17?
Ja, du skal konstant opgradere til den nyeste version, dog ikke så snart som dag ét. Den software og de biblioteker, du bruger, er muligvis ikke blevet opdateret til at inkludere kompatibilitet med Java 17, så du skal muligvis vente et stykke tid, indtil det er færdigt.
Hvis du sidder fast med en LTS-version af Java som Java 8 eller Java 11, er der adskillige muligheder inden for sproget og i selve JVM, der kræver en opgradering op til Java 17. Da det er en langsigtet vedligeholdelsesudgivelse, er der en stor chance for, at dit produktionsmiljø med tiden også bliver opdateret til Java 17.
Hvis du begynder på et helt nyt projekt, eller er i gang med at gøre dit projekt klar og klar til Java 17, er det nok det mest effektive valg at skifte til Java 17 før end senere, da det reducerer omkostningerne ved at flytte. Dette giver også udviklerne, der arbejder på projektet, mulighed for at bruge alle de nyeste funktioner og ops-siden.
Du kan drage fordel af de mange forbedringer, der er sket i løbet af de sidste par år, såsom forbedret understøttelse af containere, der kører på Java, såvel som nye lav-latency skraldeopsamlerimplementeringer.