Java 9 — formelt, Java Platform Standard Edition version 9 — er endelig her, og dets Java Development Kit (JDK) er tilgængelig for udviklere at downloade.
Det har flere vigtige, hvis kontroversielle nye funktioner, men er også den sidste af linjen for den gamle stil med Java-levering.
Hvor downloades Java 9 JDK
Oracle har sendt Java SE 9 JDK og dokumentation til download af udviklere.
De vigtigste nye funktioner i Java 9
Debuterer næsten tre år efter Java SE 8, og Java SE 9 har flere vigtige arkitektoniske ændringer samt en række forbedringer.
Java 9's modularitet er en game-changer
De nye, kontroversielle modularitetsfunktioner, der er baseret på Project Jigsaw, vil helt sikkert vække interessen for avancerede Java-butikker, der ønsker at se, hvad JDK 9 har at tilbyde nu, selvom mere konservative butikker beslutter at vente på, at modulariteten modnes.
Modularitet - i form af Java Platform Module System - opdeler JDK i et sæt moduler til kombination ved kørsel, kompilering eller byggetid. Modularitet er blevet kaldt en "transitiv" ændring, der muliggør forståelse af afhængigheder på tværs af moduler.
Java 9's modularitet formodes at lade udviklere lettere samle og vedligeholde sofistikerede applikationer. Det skal også gøre Java bedre i stand til at skalere ned til mindre enheder, mens sikkerhed og ydeevne forbedres.
Modularitetsaspekterne af Java 9 inkluderer applikationsemballage, modulering af selve JDK og omorganisering af kildekode i moduler. Bygningssystemet forbedres til at kompilere moduler og håndhæve modulgrænser ved byggetid. JDK- og Java Runtime Environment (JRE) -billeder er omstruktureret til at håndtere moduler. Også JavaFX UI-kontroller og CSS API'er er nu tilgængelige med henblik på modularitet.
En række konfigurationer understøttes; som et resultat skalerbarhed, sikkerhed og applikationsydelse forbedres. Nemmere skalering af Java ned til små enheder er en nøgledriver til den modulære indsats.
Med modularitet vil udviklere være bedre i stand til at konstruere og vedligeholde biblioteker og store applikationer til både Java SE (Standard Edition) og Java EE (Enterprise Edition). Men under Java 9's udvikling havde Oracle, IBM, Red Hat og andre store uenigheder om præcis, hvordan man foretog en så radikal ændring i platformen. Selve modulsystemet blev afvist i maj for kun at blive godkendt ved anden afstemning i juni, efter at der var gjort fremskridt.
Selv efter aftale mellem de største Java-leverandører er der fortsat kontroverser om, hvorvidt modularitet vil gøre Java-udviklere meget godt, hvor nogle eksperter siger ja, og andre siger nej. Uanset hvad er Java 9 nu moduleret.
For at gøre migrering til modulariseret Java 9 nemmere tillader Java 9 ulovlig reflekterende adgang til kode på klassestien, der bruges af JRE til at søge efter klasser og ressourcefiler. Denne mulighed vil ikke blive tilladt efter Java 9.
Compiler forbedringer til Java 9-kode
Java 9-opgraderingen har adskillige nye muligheder for at kompilere kode, hvoraf den største er AoT-kompilering. Stadig i en eksperimentel fase muliggør denne mulighed kompilering af Java-klasser til native-kode, før de lanceres på den virtuelle maskine. Denne funktion er beregnet til at forbedre opstartstiden for både små og store applikationer med begrænset indflydelse på peak performance.
Just-in-time (JIT) -compilere er hurtige, men Java-programmer er blevet så store, at det tager lang tid for JIT at varme op fuldstændigt, hvilket efterlader nogle Java-metoder ukompileret og svækker ydeevnen. Kompilering forud for tiden er beregnet til at løse disse problemer.
Men Dmitry Leskov, marketingdirektør hos Java-teknologileverandøren Excelsior, er bekymret for, at den tidlige kompileringsteknologi ikke er moden nok og ønsker Oracle havde ventet indtil Java 10 på en mere solid version.
Java 9 tilbyder også fase to af Oracles intelligente kompilering. Denne funktion indebærer forbedring afs javac værktøjets stabilitet og bærbarhed, så det som standard kan bruges i JVM (Java Virtual Machine). Værktøjet bliver også generaliseret, så det kan bruges til store projekter uden for JDK. JDK 9 har også opdateretjavac compiler, så den kan kompilere Java 9-programmer til at køre på nogle ældre versioner af Java.
En anden ny - men eksperimentel - kompilationsfunktion er JVM Compiler Interface (JVMCI) på Java-niveau. Denne grænseflade lader en compiler skrevet i Java bruges som en dynamisk compiler af JVM. JVMCI's API giver mekanismer til adgang til VM-strukturer, installation af kompileret kode og tilslutning til JVM-kompilationssystemet.
Skrivning af en JVM-kompilator i Java skal give mulighed for en kompilator af høj kvalitet, der er lettere at vedligeholde og forbedre end eksisterende kompilatorer skrevet i C eller C ++. Som et resultat skal kompilatorer skrevet i selve Java være lettere at vedligeholde og forbedre. Andre eksisterende bestræbelser på at aktivere in-Java kompilatorer inkluderer Graal Project og Project Metropolis.
En ny kompilatorstyringsfunktion er beregnet til at tilvejebringe finkornet og metode-kontekstafhængig kontrol af JVM-compilere, så udviklere kan ændre compiler-kontrolindstillingerne i løbetid uden præstationsforringelse. Værktøjet muliggør også løsninger på JVM-compiler-fejl.
REPL kommer endelig til Java 9
Java 9 har et REPL-værktøj (read-eval-print loop) - et andet langsigtet mål for Java, der bliver ægte i denne version efter mange års udvikling under Project Kulia.
Kaldet jShell, evaluerer Java 9's REPL interaktivt erklærende udsagn og udtryk. Udviklere kan få feedback på programmer inden kompilering bare ved at indtaste nogle linjer med kode.
Kommandolinjeværktøjets muligheder inkluderer færdiggørelse af faner og automatisk tilføjelse af nødvendige terminalsemikoloner. JShell API tillader jShell-funktionalitet i IDE'er og andre værktøjer, selvom selve værktøjet ikke er en IDE.
Manglen på en REPL er nævnt som en grund til, at skoler flytter væk fra Java. (Sprog som Python og Scala har længe haft en REPL.) Men Scala-sprogstifter Martin Odersky sætter spørgsmålstegn ved nytten af en REPL i Java og siger, at Java er sætningsorienteret, mens REPL'er er udtryksorienterede.
Forbedringer af Streams API i Java 9
Streams i Java lader udviklere udtrykke beregninger, så dataparallelisme effektivt kan udnyttes. Stream-kapaciteten i Java 8 er til at behandle data erklærende, mens man udnytter multicore-arkitekturer.
I Java 9 tilføjer Streams API metoder til betinget at tage og slippe emner fra Stream, gentage over Stream-elementer og oprette en stream fra en ugyldig værdi, mens de udvider sæt Java SE API'er, der kan fungere som Streams-kilder.
Kodecache kan opdeles i Java 9
JDK 9 tillader, at kode-cache opdeles i segmenter for at forbedre ydeevnen og tillade udvidelser som finkornet låsning. Resultaterne bør forbedres fejetider på grund af specialiserede iteratorer, der springer kode over ikke-metoden over; adskille ikke-metode, profileret og ikke-profileret kode; og forbedring af udførelsestid for nogle benchmarks.
Bedre JavaScript-sikkerhedskopiering i Java 9 via Project Nashorn
Project Nashorn, der leverer en let JavaScript-runtime til Java, forbedres i JDK 9. Project Nashorn var et forsøg på at implementere en højtydende, men let JavaScript-runtime i Java, efter opfølgning af Rhino-projektet, der blev påbegyndt hos Netscape. Project Nashorn blev anklaget for at muliggøre indlejring af JavaScript i Java-applikationer. Det forsynede Java med en JavaScript-motor i JDK 8.
JDK 9 inkluderer en parser-API til Nashorns ECMAScript-syntaks-træ. API'en muliggør ECMAScript-kodeanalyse af IDE'er og serverrammer uden at være afhængig af Project Nashorns interne implementeringsklasser.
HTTP / 2-klient API kommer til Java 9
Beta HTTP / 2-klient-API'en er kommet til JDK 9 og implementerer i Java opgraderingen til Internets kerne HTTP-protokol. WebSocket understøttes også af API'en.
HTTP / 2 API kan erstatte HttpURLConnection API, som har haft problemer, herunder at være designet med nu defunct protokoller, forudgående HTTP / 1, være for abstrakt og være svær at bruge.
Forbedret HTML5 og Unicode support i Java 9
I JDK 9 forbedres Javadoc-dokumentationsværktøjet til at generere HTML5-markering. Unicode 8.0-kodningsstandarden - som tilføjer 8.000 tegn, 10 blokke og seks scripts - understøttes også.
DTLS-sikkerheds-API føjes til Java 9
Af sikkerhedshensyn tilføjer Java 9 en API til DTLS (Datagram Transport Layer Security). Protokollen er designet til at forhindre aflytning, manipulation og forfalskning af meddelelser i klient / server kommunikation. En implementering leveres til både klient- og servertilstande.
Hvad Java 9 forælder og fjerner
Java 9 forælder eller fjerner flere funktioner, der ikke længere er i mode. Hoved blandt dem er Applet API, som er udfaset. Det er gået ud af stil nu, da sikkerhedsbevidste browserproducenter har fjernet understøttelse af Java-browser-plug-ins. Fremkomsten af HTML5 hjalp også med til at skabe deres død. Udviklere styres nu til alternativer som Java Web Start, til at starte applikationer fra en browser eller installerbare applikationer.
Appletviewer-værktøjet udfases også.
Java 9 fratager også affaldssamleren Concurrent Mark Sweep (CMS) med støtte til at ophøre i en fremtidig frigivelse. Hensigten er at fremskynde udviklingen af andre affaldssamlere i den virtuelle HotSpot-maskine. G1-affaldssamleren med lav pause er beregnet til at være en langsigtet erstatning for CMS.
I mellemtiden fjernes skraldopsamlingskombinationer, der tidligere er udfaset i JDK 8, i JDK 9. Disse inkluderer sjældent anvendte kombinationer såsom Incremental CMS, ParNew + SerialOld og DefNew + CMS, hvilket tilføjede ekstra kompleksitet til skraldespandkodebasen.
Java 9 fjerner også Java-advarsler på importerklæringer for at gøre store kodebaser rene for fnugadvarsler. Med disse kodebaser skal forældet funktionalitet ofte understøttes i nogen tid, men import af en udfaset konstruktion garanterer ikke en advarselsmeddelelse, hvis anvendelsen af konstruktionen er forsætlig og undertrykt.
Også fjernet i Java 9 er muligheden for at vælge JRE ved starttid via funktionen Multiple JRE (mJRE). Funktionen blev sjældent brugt, komplicerede implementeringen af Java-launcheren, og den blev aldrig fuldt dokumenteret, da den debuterede i JDK 5.
Oracle har fjernet JVM TI (Tool Interface) hprof (Heap Profiling) -agenten, som er blevet afløst af JVM. Jhat-værktøjet blev også fjernet efter at være blevet forældet af overlegne bunkevisualisatorer og analysatorer.
Java 9 er slutningen af sin linje, da den nye Java 9-linje begynder
Man kan sige, at Java 9 går ud med et brag med alle de nye muligheder. Oracle afslørede for nylig, at Java 9 er den sidste af sin art, hvad angår dens betegnelse og forløbet tid mellem større udgivelser.
Herfra og ud planlægges Java at have en seks måneders frigivelseskadence, med den næste store version, der kaldes Java 18.3, som skyldes marts 2018, efterfulgt af Java 18.9 seks måneder senere.
Java's nye frigivelseskadence betyder også, at JDK 9 ikke vil blive udpeget som en langsigtet supportudgivelse. I stedet bliver den næste langsigtede frigivelse Java 18.9.
Java's hurtigere frigivelseskadence betyder, at udviklere ikke behøver at vente så længe på større udgivelser. Det kan også betyde, at udviklere springer over Java 9 og dens "umodne" modularitetsfunktioner og venter seks måneder på den nye version, hvilket sandsynligvis vil stryge enhver kinks, sagde Simon Maple, direktør for Java advocacy hos Java-værktøjsleverandøren ZeroTurnaround.
