Long-Term-Support (LTS)-versjonen av Java-språk- og kjøretidsplattformen Java 17 ble lansert 14. september 2021. La oss finne ut hva som er nytt i Java 17 og om du bør oppgradere.
Mange applikasjoner bruker eldre versjoner av Java, inkludert de tidligere LTS-versjonene av Java: Java 11 og Java 8.
Hvorfor bør bedrifter oppgradere til den nyeste Java-versjonen? Oppgraderingen til Java 17 krever innsats, hovedsakelig for å få mest mulig ut av de nye funksjonene og funksjonene inne i JVM.
Mange bedrifter bruker Docker- og Docker-bilder for å bytte til Java 17 enkelt med minimal innsats og tid. Utviklere kan definere sine kontinuerlige integrasjon/distribusjon (CI/CD) pipelines og kjøre alt i Docker-bilder. Dette vil ikke påvirke andre lag som bruker eldre Java-versjoner, da de kan bruke gamle Docker-bilder.
Innholdsfortegnelse
JAVA 17-funksjoner
macOS og AArch64-støtte
En av de kritiske JVM-funksjonene som er lagt til denne versjonen, er å forbedre støtten for macOS på AArch64-arkitektur ved å bruke JEP 391. Den vil støtte den siste serien med prosessorer (M1) som Apple lanserte sammen med datamaskinene deres det siste året.
Det er ikke nødvendigvis en stor sak for brukere på disse plattformene siden noen leverandører har lansert versjoner av JDK som støtter denne arkitekturen og til og med returnerer støtte opp fra Java 8. Det offisielle godkjenningsstempelet er imidlertid avgjørende for å sikre fremtidig vedlikehold og støtte for Plattformen. Til sammenligning er støtte for Linux/AArch64-plattformen lagt til Java 9 og Windows/AArch64 i Java 16.
Forseglede klasser
Sealed Classes er en funksjon som ble introdusert i Java 17. Sealed Classes-funksjonen har fullført prøvefasen og har blitt en offisiell plattform og språk i Java 17. Den tillater en utvikler å spesifisere de tillatte undertypene som en type kan ha og hindre andre i å utvide eller implementere det på en måte som ikke er tiltenkt.
Forseglede klasser lar også kompilatoren generere feil på kompileringstidspunktet når du prøver å konvertere en ikke-forseglet type til en ikke-tillatt undertype. Java 17 bringer også en ny gjengivelsespipeline for AWT/Swing-apper som kjører på macOS ved å bruke Apple Metal API i stedet for OpenGL. Den har en forbedret API og forbedrede funksjoner for å generere tilfeldige tall.
Endringer, slettinger og begrensninger i Java 17
Java 17 gir også flere endringer, slettinger og nye begrensninger.
Innkapsling av JDK Internals
En endring er konklusjonen av innkapslingsprosessen til JDK Internals. Første gang dette ble introdusert var innenfor Java 9 og ville gi advarsler under kjøretid når en bruker forsøkte å bruke refleksjon eller lignende for å omgå de vanlige restriksjonene for bruk av interne APIer. Kommandolinjeargumenter ble også lagt til for å regulere denne oppførselen.
Fra Java 9 har forskjellige APIer blitt laget for å tilby en enhetlig måte å utføre de mest brukte oppgavene på; brukere vil bruke disse APIene internt. Med Java 16 ble standarden endret fra en advarsel til å deaktivere tilgang til å kaste et unntak. Den bruker imidlertid kommandolinjeargumentet for å endre atferden.
Med Java 17 er kommandolinjeargumentet eliminert, og det er mulig å deaktivere denne begrensningen. Dette betyr at all ikke-autorisert tilgang til disse interne API-ene nå er beskyttet.
Alltid streng semantikk med flytende punkt
En ekstra «fjerning» kan beskrives som gjeninnføring av Always-Strict Floating Point-semantikk. Java 1.2 introduserte modifikasjoner av somantikkstandarden for flytende komma i Java som lar JVM handle inn en liten mengde presisjon i flytepunktberegninger for å forbedre ytelsen. I klasser og metoder der streng semantikk måtte brukes, ble et strictfp nøkkelord lagt til. Siden den gang har ulike instruksjonssetttyper blitt introdusert til CPU-ene, noe som gjør at streng flytende-punkts-semantikk kan brukes uten unødvendige kostnader. Behovet for å implementere en standard eller streng semantikk er eliminert.
Java 17 fjerner den tidligere standard semantikken, og alle flyttalloperasjoner utføres strengt. Begrepet strictfpis er fortsatt til stede. Det har imidlertid ingen effekt og forårsaker en advarsel på kompileringstidspunktet.
Ahead-of-Time (AOT)-samling
Java 9 introduserte forhåndskompilering (AOT) som en eksperimentell funksjon som bruker Graal-kompilatoren, og en JIT-kode ble skrevet med Java. Java 10 gjorde Graal-kompilatoren brukbar som en JIT-kompilator i OpenJDK ved å inkorporere JVMCI-grensesnittet. Siden den ble utgitt, har den vært en enorm forbedring. Graal-kompilatoren har sett enorme fremskritt og har sin JVM under navnet GraalVM.
RMI-aktivering
RMI-aktivering ble eliminert i JEP 407 etter at den ble fjernet fra Java 8 og til slutt avviklet og merket som et krav for fjerning i Java 15. RMI-aktivering ga en metode for å aktivere distribuerte objekter på forespørsel ved hjelp av RMI. Imidlertid så den minimal bruk, og et bedre alternativ er tilgjengelig i dag. Resten av RMI er upåvirket av eliminering av aktiveringsdelen.
Applet API fjerning
Applet API har endelig blitt utpekt for fjerning av JEP 398, opprinnelig fjernet i Java 9. Applet API ga en måte å integrere Java AWT/Swing-kontroller på en nettside i en nettleser. Ingen moderne nettleser kan imidlertid støtte dette, noe som betyr at applets har vært praktisk talt utilgjengelige i løpet av det siste tiåret eller så.
Sikkerhetssjef
Den mest avgjørende avskrivningen er at det er sikkerhetssjefen ( JEP 411). Security Manager har vært i bruk en stund siden Java 1.0. Den ble designet for å begrense hva Java kunne gjøre lokalt på maskinen, for eksempel å begrense tilgangen til nettverk, filer og andre nettverksressurser. Den prøver også å sandboxe kode som ikke er klarert ved å blokkere refleksjon og spesifikke APIer.
Slutten av Security Manager startet i Java 12. Et kommandolinjeargument ble lagt til for å blokkere bruken av sikkerhetsbehandlingen under kjøring. Endringen som er gjort i Java 17 betyr at en kjøretidsadvarsel vil bli generert i JVM når du prøver å sette en Security Manager, enten fra kommandolinjen eller dynamisk under kjøring.
Inkubator og forhåndsvisningsfunksjoner
Mange lurte på om Java 17 ville ha noen forhåndsvisnings- og inkubatorfunksjoner, med tanke på at Java 17 ble promotert til å være en langsiktig støttet versjon. Java 17 har to inkubatormoduler og en forhåndsvisningsfunksjon!
Vektor API
Vector API ( JEP 414) er for tiden i sin andre fase av inkubatoren. API-en lar utviklere definere vektorberegning som JIT-kompilatoren deretter vil konvertere til den riktige vektorinstruksjonen støttet av CPU-arkitekturen som JVM kjører på (for eksempel ved å bruke SSE- eller AVX-instruksjonssettene).
Før måtte utviklere bruke skalarfunksjoner eller bygge native biblioteker som var spesifikke for plattformen. Implementering av Vector API i Java gir også en sømløs reservemekanisme som var komplisert i tidligere versjoner.
Standardiseringen av Vector API gjør det mulig for klassene i JDK å bruke den. Java Arrays mismatch()-metoder kan endres til å kjøres på Java i stedet, og eliminerer kravet om å vedlikeholde og skrive flere plattformspesifikke implementeringer i JVM.
Foreign Function & Memory API
En ekstra inkubatorfunksjon kalles Foreign Function & Memory API ( JEP 412). Det er en utvikling og sammenslåing av to andre inkubatormoduler av Java 16 som er The Foreign Linker API ( JEP 389) og Foreign-Memory API ( JEP 393). Begge gir tilgang til innebygd minne og kode ved å bruke statisk skrevet programmering skrevet i Java.
Mønstertilpasning for Switch
Den siste funksjonen i språkforhåndsvisningen inkludert i Java 17 er inkluderingen av Pattern Matching for Switch ( JEP 406). Denne språkfunksjonen utvider bryteruttrykkene og setningene i henhold til type, lik syntaksen som brukes gjennom Pattern Matching (JEP 394), som ble standard med Java 16.
Tidligere, hvis du ønsket å utføre forskjellige handlinger basert på den dynamiske naturen til et objekt, ville du bli bedt om å konstruere en hvis-else-kjede ved å bruke en forekomst av sjekker 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 å kombinere bryteruttrykket så vel som den nye mønstertilpasningsfunksjonen for brytere, kan prosessen reduseres til noe som ligner på:
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 kanskje har lagt merke til, er det deklarasjonen av en variabel i ferd med å sjekke. I likhet med de andre variablene i Pattern, indikerer matching av forekomst at dette objektet ble typesjekket og kastet og er tilgjengelig fra variabelen innenfor dets gjeldende område.
Forhåndsvisningsfunksjonen er enda et skritt mot mønstertilpasning. Det neste trinnet er å inkludere muligheten til å dekonstruere arrays og poster.
Bør du oppgradere til Java 17?
Ja, du må hele tiden oppgradere til den nyeste versjonen, men ikke så snart som dag én. Programvaren og bibliotekene du bruker har kanskje ikke blitt oppdatert for å inkludere kompatibilitet med Java 17, så du må kanskje vente en stund til det er ferdig.
Hvis du sitter fast med en LTS-versjon av Java som Java 8 eller Java 11, er det mange alternativer innenfor språket og i selve JVM som krever en oppgradering opp til Java 17. Siden det er en langsiktig vedlikeholdsutgivelse, er det en stor sjanse for at produksjonsmiljøet ditt til slutt vil bli oppdatert til Java 17 også.
Hvis du begynner på et helt nytt prosjekt, eller er i ferd med å gjøre prosjektet klart og klart for Java 17, er det sannsynligvis det mest effektive valget å bytte til Java 17 før eller siden, siden det reduserer kostnadene ved å flytte. Dette lar også utviklerne som jobber med prosjektet bruke alle de nyeste funksjonene og ops-siden.
Du kan dra nytte av de mange forbedringene som har skjedd i løpet av de siste årene, for eksempel forbedret støtte for containere som kjører på Java, samt nye implementeringer av søppeloppsamlere med lav ventetid.