Java 9 — formelt sett, Java Platform Standard Edition versjon 9 — er endelig her, og Java Development Kit (JDK) er tilgjengelig for utviklere å laste ned.
Den har flere viktige om kontroversielle nye funksjoner, men er også den siste av linjen for den gamle stilen med Java-levering.
Hvor laster du ned Java 9 JDK
Oracle har lagt ut Java SE 9 JDK og dokumentasjon for nedlasting av utviklere.
De viktigste nye funksjonene i Java 9
Debuterer nesten tre år etter Java SE 8, og Java SE 9 har flere viktige arkitektoniske endringer, samt en rekke forbedringer.
Java 9s modularitet er en spillveksler
De nye, kontroversielle modularitetsfunksjonene, basert på Project Jigsaw, vil sikkert vekke interessen til banebrytende Java-butikker som vil se hva JDK 9 har å tilby nå, selv om mer konservative butikker bestemmer seg for å vente på at modulariteten skal modnes.
Modularitet - i form av Java Platform Module System - deler JDK i et sett med moduler for kombinasjon ved kjøring, kompilering eller byggetid. Modularitet har blitt kalt en ”transitiv” endring, som muliggjør forståelse av avhengigheter på tvers av moduler.
Java 9s modularitet er ment å la utviklere lettere montere og vedlikeholde sofistikerte applikasjoner. Det bør også gjøre Java bedre i stand til å skalere ned til mindre enheter mens sikkerhet og ytelse forbedres.
Modularitetsaspektene til Java 9 inkluderer applikasjonsemballasje, modulering av selve JDK og omorganisering av kildekoden i moduler. Byggesystemet er forbedret for å kompilere moduler og håndheve modulgrenser ved byggetid. JDK- og Java Runtime Environment (JRE) -bilder er omstrukturert for å håndtere moduler. Dessuten er JavaFX UI-kontroller og CSS APIer nå tilgjengelige for modularitet.
En rekke konfigurasjoner støttes; som et resultat skal skalerbarhet, sikkerhet og applikasjonsytelse forbedres. Enklere skalering av Java ned til små enheter er en nøkkeldriver for modulinnsatsen.
Med modularitet vil utviklere bedre kunne konstruere og vedlikeholde biblioteker og store applikasjoner for både Java SE (Standard Edition) og Java EE (Enterprise Edition). Men under Java 9s utvikling hadde Oracle, IBM, Red Hat og andre store uenigheter om nøyaktig hvordan man skulle gjøre en så radikal endring i plattformen. Selve modulsystemet ble avvist i mai, bare for å bli godkjent ved andre avstemning i juni, etter at fremgangen ble gjort.
Selv med enighet blant de største Java-leverandørene, er det fortsatt kontrovers om modulæriteten vil gjøre Java-utviklere mye bra, med noen eksperter som sier ja og andre sier nei. Uansett er Java 9 nå modularisert.
For å gjøre migrering til modulær Java 9 enklere, tillater Java 9 ulovlig reflekterende tilgang for kode på klassebanen, brukt av JRE til å søke etter klasser og ressursfiler. Denne funksjonen vil ikke bli tillatt etter Java 9.
Kompilatorforbedringer for Java 9-kode
Java 9-oppgraderingen har flere nye muligheter for å kompilere kode, og den viktigste er AoT-kompilering. Fortsatt i en eksperimentell fase, muliggjør denne muligheten kompilering av Java-klasser til naturlig kode før de blir lansert på den virtuelle maskinen. Denne funksjonen er ment å forbedre oppstartstiden for både små og store applikasjoner, med begrenset innvirkning på topp ytelse.
Just-in-time (JIT) kompilatorer er raske, men Java-programmer har blitt så store at det tar lang tid for JIT å varme seg opp helt, og etterlater noen Java-metoder ukompilert og svekker ytelsen. Tidlig samling er ment å løse disse problemene.
Men Dmitry Leskov, markedsdirektør hos Java-teknologileverandøren Excelsior, er bekymret for at den tidlige kompileringsteknologien ikke er moden nok og ønsker Oracle hadde ventet til Java 10 på en mer solid versjon.
Java 9 tilbyr også fase to av Oracles smarte kompileringsutrulling. Denne funksjonen innebærer å forbedres javac verktøyets stabilitet og bærbarhet slik at den kan brukes i JVM (Java Virtual Machine) som standard. Verktøyet vil også bli generalisert, slik at det kan brukes til store prosjekter utenfor JDK. JDK 9 har også oppdatertjavac kompilator slik at den kan kompilere Java 9-programmer for å kjøre på noen eldre versjoner av Java.
En annen ny - men eksperimentell - kompileringsfunksjon er JVM Compiler Interface (JVMCI) på Java-nivå. Dette grensesnittet lar en kompilator skrevet i Java brukes som en dynamisk kompilator av JVM. JVMCIs API gir mekanismer for å få tilgang til VM-strukturer, installere kompilert kode og plugge inn i JVM-kompilasjonssystemet.
Å skrive en JVM-kompilator i Java skal tillate en kompilator av høy kvalitet som er lettere å vedlikeholde og forbedre enn eksisterende kompilatorer skrevet i C eller C ++. Som et resultat bør kompilatorer skrevet i Java selv være lettere å vedlikeholde og forbedre. Andre eksisterende bestrebelser for å aktivere in-Java kompilatorer inkluderer Graal Project og Project Metropolis.
En ny kompilatorkontrollfunksjon er ment å gi finkornet og metodekontekstavhengig kontroll av JVM-kompilatorer, slik at utviklere kan endre kompilatorstyringsalternativene i løpetid uten ytelsesforringelse. Verktøyet muliggjør også løsninger for JVM kompileringsfeil.
REPL kommer endelig til Java 9
Java 9 har et REPL-verktøy (read-eval-print loop) - et annet langsiktig mål for Java som blir virkelig i denne versjonen, etter mange års utvikling under Project Kulia.
Kalt jShell, evaluerer Java 9’s REPL interaktivt erklærende uttalelser og uttrykk. Utviklere kan få tilbakemelding på programmer før kompilering bare ved å legge inn noen kodelinjer.
Kommandolinjeverktøyets funksjoner inkluderer fullføring av faner og automatisk tillegg av nødvendige terminalkolikoner. JShell API tillater jShell-funksjonalitet i IDEer og andre verktøy, selv om selve verktøyet ikke er en IDE.
Mangelen på en REPL har blitt sitert som en grunn til at skolene flytter fra Java. (Språk som Python og Scala har lenge hatt en REPL.) Men Scala språkstifter Martin Odersky stiller spørsmål ved nytten av en REPL i Java og sier Java er uttalelsesorientert mens REPL er uttrykksorientert.
Forbedringer av Streams API i Java 9
Strømmer i Java lar utviklere uttrykke beregninger slik at dataparallellisme kan utnyttes effektivt. Stream-funksjonen i Java 8 er for å behandle data erklærende mens du bruker multicore-arkitekturer.
I Java 9 legger Streams API til metoder for betinget å ta og slippe elementer fra Stream, itere over Stream-elementer og opprette en stream fra en nullverdi mens du utvider settet med Java SE APIer som kan fungere som Streams-kilder.
Kodebuffer kan deles i Java 9
JDK 9 lar kodebufferen deles inn i segmenter for å forbedre ytelsen og tillate utvidelser som finkornet låsing. Resultatene bør forbedres feietider på grunn av spesialiserte iteratorer som hopper over ikke-metode-kode; skille ikke-metode, profilert og ikke-profilert kode; og forbedre gjennomføringstiden for noen referanser.
Bedre JavaScript-sikkerhetskopiering i Java 9 via Project Nashorn
Project Nashorn, som gir en lett JavaScript-runtime for Java, forbedres i JDK 9. Project Nashorn var et forsøk på å implementere en høy ytelse, men lett JavaScript-runtime i Java, etter oppfølging av Rhino-prosjektet som ble startet på Netscape. Project Nashorn var tiltalt for å muliggjøre innbygging av JavaScript i Java-applikasjoner. Det ga Java en JavaScript-motor i JDK 8.
JDK 9 inkluderer en parser-API for Nashorns ECMAScript-syntaks-tre. API-et muliggjør ECMAScript-kodeanalyse av IDEer og serverrammer uten å avhenge av Project Nashorns interne implementeringsklasser.
HTTP / 2-klient-API kommer til Java 9
Beta HTTP / 2-klient-API-et har kommet til JDK 9, og implementerer i Java oppgraderingen til nettets kjerne HTTP-protokoll. WebSocket støttes også av API.
HTTP / 2 API kan erstatte HttpURLConnection API, som har hatt problemer, inkludert å være designet med nå nedlagte protokoller, forut HTTP / 1, være for abstrakt og være vanskelig å bruke.
Forbedret HTML5 og Unicode-støtte i Java 9
I JDK 9 forbedres Javadoc-dokumentasjonsverktøyet for å generere HTML5-markering. Unicode 8.0-kodingsstandarden - som legger til 8000 tegn, 10 blokker og seks skript - støttes også.
DTLS-sikkerhets-API er lagt til Java 9
For sikkerhet legger Java 9 til et API for DTLS (Datagram Transport Layer Security). Protokollen er designet for å forhindre avlytting, manipulering og forfalskning av meldinger i klient- / serverkommunikasjon. En implementering er gitt for både klient- og servermodus.
Hva Java 9 avskriver og fjerner
Java 9 avvikler eller fjerner flere funksjoner som ikke lenger er på moten. Hoved blant dem er Applet API, som er avviklet. Det har gått ut av stil nå som sikkerhetsbevisste nettleserprodusenter har fjernet støtte for Java-nettleser-plugin-moduler. Fremkomsten av HTML5 bidro også til å få dem til å dø. Utviklere blir nå guidet til alternativer som Java Web Start, for å starte applikasjoner fra en nettleser eller installerbare applikasjoner.
Appletviewer-verktøyet avvikles også.
Java 9 avskriver også søppeloppsamleren Concurrent Mark Sweep (CMS), med støtte til å opphøre i en fremtidig utgivelse. Hensikten er å få fart på utviklingen av andre søppeloppsamlere i den virtuelle HotSpot-maskinen. G1-søppeloppsamleren med lav pause er ment å være en langsiktig erstatning for CMS.
I mellomtiden blir søppeloppsamlingskombinasjoner som tidligere er utfaset i JDK 8 fjernet i JDK 9. Disse inkluderer sjelden brukte kombinasjoner som Incremental CMS, ParNew + SerialOld og DefNew + CMS, som tilførte ekstra kompleksitet til søppelkollektorkodebasen.
Java 9 fjerner også Java-advarsler på importuttalelser, for å gjøre store kodebaser rene for lofvarsler. Med disse kodebasene må avviklet funksjonalitet ofte støttes i noen tid, men import av en utdatert konstruksjon garanterer ikke en advarsel hvis bruk av konstruksjonen er forsettlig og undertrykt.
Også fjernet i Java 9 er muligheten til å velge JRE ved lanseringstid via Multiple JRE (mJRE) -funksjonen. Evnen ble sjelden brukt, kompliserte implementeringen av Java-lanseringen, og den ble aldri fullstendig dokumentert da den debuterte i JDK 5.
Oracle har fjernet JVM TI (Tool Interface) hprof (Heap Profiling) -agenten, som er erstattet i JVM. Jhat-verktøyet ble også fjernet, etter å ha blitt foreldet av overlegne haugvisualiserere og analysatorer.
Java 9 er slutten på linjen når den nye Java 9-linjen begynner
Du kan si at Java 9 går ut med et smell, med alle de nye mulighetene. Oracle avslørte nylig at Java 9 er den siste i sitt slag, når det gjelder betegnelse og tid som har gått mellom store utgivelser.
Herfra og ut er Java planlagt å ha en seks måneders frigivelseskadens, med neste store versjon, som skal kalles Java 18.3, med utgangspunkt i mars 2018, etterfulgt av Java 18.9 seks måneder senere.
Java's nye utgivelseskadens betyr også at JDK 9 ikke vil bli utpekt som en langsiktig støtteutgivelse. I stedet blir den neste langsiktige versjonen Java 18.9.
Java's raskere utgivelseskadens betyr at utviklere ikke trenger å vente så lenge på store utgivelser. Det kan også bety at utviklere hopper over Java 9 og dens "umodne" modularitetsfunksjoner og venter seks måneder på den nye versjonen, noe som sannsynligvis vil stryke ut noen kinks, sa Simon Maple, direktør for Java advocacy hos Java-verktøyleverandøren ZeroTurnaround.
