Java 9 är här: Allt du behöver veta

Java 9 — formellt, Java Platform Standard Edition version 9 — är äntligen här, och dess Java Development Kit (JDK) är tillgängligt för utvecklare att ladda ner.

Det har flera viktiga om kontroversiella nya funktioner, men är också den sista av raden för den gamla stilen för Java-leverans.

Var kan jag ladda ner Java 9 JDK

Oracle har lagt upp Java SE 9 JDK och dokumentation för nedladdning av utvecklare.

De viktigaste nya funktionerna i Java 9

Debuterar nästan tre år efter Java SE 8, Java SE 9 har flera viktiga arkitektoniska förändringar, liksom en mängd förbättringar.

Java 9: ​​s modularitet är en spelväxlare

De nya kontroversiella modularitetsfunktionerna, baserade på Project Jigsaw, kommer säkert att väcka intresset för banbrytande Java-butiker som vill se vad JDK 9 har att erbjuda nu, även om mer konservativa butiker beslutar att vänta på att modulariteten ska mogna.

Modularitet - i form av Java Platform Module System - delar upp JDK i en uppsättning moduler för att kombinera vid körning, kompilering eller byggtid. Modularitet har kallats en ”transitiv” förändring, vilket möjliggör förståelse av beroenden mellan moduler.

Java 9: ​​s modularitet är tänkt att låta utvecklare lättare montera och underhålla sofistikerade applikationer. Det bör också göra Java bättre i stånd att skala ner till mindre enheter medan säkerhet och prestanda förbättras.

Modularitetsaspekterna av Java 9 inkluderar applikationsförpackning, modulering av själva JDK och omorganisation av källkod till moduler. Byggsystemet förbättras för att kompilera moduler och upprätthålla modulgränser vid byggtiden. JDK- och Java Runtime Environment (JRE) -bilder är omstrukturerade för att hantera moduler. JavaFX UI-kontroller och CSS API: er är nu tillgängliga för modulärhet.

En mängd konfigurationer stöds; som ett resultat bör skalbarhet, säkerhet och applikationsprestanda förbättras. Enklare skalning av Java ner till små enheter är en viktig drivkraft för det modulära arbetet.

Med modularitet kommer utvecklare att bättre kunna konstruera och underhålla bibliotek och stora applikationer för både Java SE (Standard Edition) och Java EE (Enterprise Edition). Men under Java 9: ​​s utveckling hade Oracle, IBM, Red Hat och andra stora meningsskiljaktigheter om exakt hur man skulle göra en så radikal förändring i plattformen. Själva modulsystemet avvisades i maj, bara för att godkännas vid andra omröstningen i juni, efter att framsteg gjordes.

Även efter överenskommelse mellan de stora Java-leverantörerna, finns det fortfarande kontroverser om huruvida modularitet kommer att göra Java-utvecklare mycket bra, med vissa experter som säger ja och andra säger nej. Oavsett är Java 9 nu modulerad.

För att göra migreringen till moduliserad Java 9 enklare tillåter Java 9 olaglig reflekterande åtkomst för kod på klassvägen, som används av JRE för att söka efter klasser och resursfiler. Denna funktion kommer inte att tillåtas efter Java 9.

Kompilatorförbättringar för Java 9-kod

Java 9-uppgraderingen har flera nya funktioner för att kompilera kod, varav främst AoT-kompilering. Fortfarande i en experimentell fas, möjliggör denna funktion sammanställning av Java-klasser till inbyggd kod innan de lanseras i den virtuella maskinen. Den här funktionen är avsedd att förbättra starttiden för både små och stora applikationer, med begränsad inverkan på topprestanda.

Just-in-time (JIT) kompilatorer är snabba, men Java-program har blivit så stora att det tar lång tid för JIT att värmas upp helt och lämnar vissa Java-metoder okompilerade och försvagar prestanda. Sammanställning i förväg är tänkt att ta itu med dessa problem.

Men Dmitry Leskov, marknadsdirektör på Java-teknologileverantören Excelsior, oroar sig för att kompileringstekniken i förväg inte är mogen och önskar att Oracle hade väntat till Java 10 för en mer solid version.

Java 9 erbjuder också fas två av Oracles smarta kompilering. Denna funktion innebär att s javac verktygets stabilitet och bärbarhet förbättras  så att det kan användas i JVM (Java Virtual Machine) som standard. Verktyget kommer också att generaliseras så att det kan användas för stora projekt utanför JDK. JDK 9 har också uppdaterat  javac kompilatorn så att den kan kompilera Java 9-program för att köras på vissa äldre versioner av Java.

En annan ny - men experimentell - kompileringsfunktion är JVM Compiler Interface (JVMCI) på Java-nivå. Detta gränssnitt låter en kompilator skriven i Java användas som en dynamisk kompilator av JVM. JVMCIs API tillhandahåller mekanismer för åtkomst till VM-strukturer, installation av kompilerad kod och anslutning till JVM-kompileringssystemet.

Att skriva en JVM-kompilator i Java bör möjliggöra en högkvalitativ kompilator som är lättare att underhålla och förbättra än befintliga kompilatorer skrivna i C eller C ++. Som ett resultat bör kompilatorer skrivna i själva Java vara lättare att underhålla och förbättra. Andra befintliga insatser för att möjliggöra in-Java-kompilatorer inkluderar Graal Project och Project Metropolis.

En ny kompilatorkontrollfunktion är avsedd att ge finkornig och metodkontextberoende kontroll av JVM-kompilatorer, så att utvecklare kan ändra kompilatorstyrningsalternativen under körning utan prestandaförsämring. Verktyget möjliggör också lösningar för JVM-kompileringsfel.

REPL kommer äntligen till Java 9

Java 9 har ett REPL-verktyg (read-eval-print loop) - ett annat långsiktigt mål för Java som blir verkligt i den här versionen, efter år av utveckling under Project Kulia.

Kallas jShell, utvärderar Java 9: ​​s REPL interaktivt deklarativa uttalanden och uttryck. Utvecklare kan få feedback om program före sammanställning bara genom att ange några kodrader.

Kommandoradsverktygets funktioner inkluderar flikavslutning och automatiskt tillägg av nödvändiga terminal semikolon. JShell API tillåter jShell-funktionalitet i IDE och andra verktyg, även om verktyget i sig inte är en IDE.

Bristen på en REPL har nämnts som en anledning för skolor att flytta från Java. (Språk som Python och Scala har länge haft en REPL.) Men Scala-språkets grundare Martin Odersky ifrågasätter nyttan av en REPL i Java och säger att Java är uttalande-orienterat medan REPLs är uttrycksorienterade.

Förbättringar av Streams API i Java 9

Strömmar i Java låter utvecklare uttrycka beräkningar så att dataparallellitet kan utnyttjas effektivt. Stream-förmågan i Java 8 är att behandla data deklarativt samtidigt som man använder multicore-arkitekturer.

I Java 9 lägger Streams API till metoder för att villkorligt ta och släppa objekt från Stream, itera över Stream-element och skapa en ström från ett ogiltigt värde medan du utökar uppsättningen Java SE API som kan fungera som Streams-källor.

Kodcache kan delas i Java 9

JDK 9 tillåter kodcache att delas in i segment för att förbättra prestanda och tillåta tillägg som finkornig låsning. Resultaten bör förbättras svepningstider på grund av specialiserade iteratorer som hoppar över icke-metodkod; separera icke-metod, profilerad och icke-profilerad kod; och förbättra exekveringstiden för vissa riktmärken. 

Bättre JavaScript-säkerhetskopiering i Java 9 via Project Nashorn

Project Nashorn, som ger en lätt JavaScript-runtime för Java, förbättras i JDK 9. Project Nashorn var ett försök att implementera en högpresterande men lätt JavaScript-runtime i Java, efter uppföljningen av Rhino-projektet som startades på Netscape. Project Nashorn anklagades för att möjliggöra inbäddning av JavaScript i Java-applikationer. Det gav Java en JavaScript-motor i JDK 8.

JDK 9 innehåller ett parser-API för Nashorns syntaxträd för ECMAScript. API: et möjliggör ECMAScript-kodanalys av IDE: er och ramar på serversidan utan att bero på Project Nashorns interna implementeringsklasser.

HTTP / 2-klient-API kommer till Java 9

Beta-HTTP / 2-klient-API: et har kommit till JDK 9 och implementerat i Java uppgraderingen till webbens kärn HTTP-protokoll. WebSocket stöds också av API: et.

HTTP / 2 API kan ersätta HttpURLConnection API, som har haft problem, inklusive att vara utformad med nu nedlagda protokoll, föregå HTTP / 1, vara för abstrakt och vara svår att använda.

Förbättrat HTML5- och Unicode-stöd i Java 9

I JDK 9 förbättras dokumentationsverktyget Javadoc för att generera HTML5-markering. Unicode 8.0-kodningsstandarden - som lägger till 8 000 tecken, 10 block och sex skript - stöds också.

DTLS-säkerhets-API läggs till Java 9

För säkerhet lägger Java 9 till ett API för DTLS (Datagram Transport Layer Security). Protokollet har utformats för att förhindra avlyssning, manipulering och förfalskning av meddelanden i klient / serverkommunikation. En implementering tillhandahålls för både klient- och serverlägen.

Vad Java 9 upphäver och tar bort

Java 9 avskaffar eller tar bort flera funktioner som inte längre är på modet. Chief bland dem är Applet API, som är utfasad. Det har gått ur stil nu när säkerhetsmedvetna webbläsartillverkare har tagit bort stöd för Java-webbläsarinsticksprogram. Tillkomsten av HTML5 hjälpte också till att de blev dödade. Utvecklare guidas nu till alternativ som Java Web Start, för att starta applikationer från en webbläsare eller installerbara applikationer. 

Appletviewer-verktyget avskaffas också.

Java 9 avskriver också sopuppsamlaren Concurrent Mark Sweep (CMS), med stöd att upphöra i en framtida släpp. Avsikten är att påskynda utvecklingen av andra sopsamlare i HotSpot virtuella maskin. G1-sopuppsamlaren med låg paus är avsedd att vara en långsiktig ersättning för CMS.

Under tiden tas bort sopkombinationskombinationer som tidigare avskaffats i JDK 8 i JDK 9. Dessa inkluderar sällan använda kombinationer som Incremental CMS, ParNew + SerialOld och DefNew + CMS, vilket tillför extra komplexitet till sopsamlarens kodbas.

Java 9 tar också bort Java-varningar vid importförklaringar för att göra stora kodbaser rena från luddvarningar. Med dessa kodbaser måste avskaffad funktionalitet ofta stödjas under en längre tid, men import av en utfasad konstruktion garanterar inte ett varningsmeddelande om användningen av konstruktionen är avsiktlig och undertryckt.

I Java 9 tas också bort möjligheten att välja JRE vid starttiden via funktionen Multiple JRE (mJRE). Förmågan användes sällan, komplicerade implementeringen av Java-startprogrammet och den dokumenterades aldrig fullständigt när den debuterade i JDK 5.

Oracle har tagit bort JVM TI (Tool Interface) hprof (Heap Profiling) -agenten, som har ersatts i JVM. Jhat-verktyget togs också bort efter att ha blivit föråldrat av överlägsna heapvisualiserare och analysatorer.

Java 9 är slutet på sin rad när den nya Java 9-linjen börjar

Man kan säga att Java 9 går ut med en smäll, med alla de nya funktionerna. Oracle avslöjade nyligen att Java 9 är den sista i sitt slag, när det gäller dess beteckning och tid som gått mellan större utgåvor.

Härifrån planeras Java att ha en sexmånaders release-kadens, med nästa större version, som ska kallas Java 18.3, i mars 2018, följt av Java 18.9 sex månader senare.

Java: s nya release-kadens betyder också att JDK 9 inte kommer att utses som en långvarig supportrelease. Istället är nästa långsiktiga version Java 18.9.

Javas snabbare släppkadens innebär att utvecklare inte behöver vänta så länge på större utgåvor. Det kan också betyda att utvecklare hoppar över Java 9 och dess "omogna" modularitetsfunktioner och väntar sex månader på den nya versionen, vilket sannolikt skulle stryka ut alla kinks, säger Simon Maple, chef för Java-förespråkande hos Java-verktygsleverantören ZeroTurnaround.