Java 9 is hier: alles wat u moet weten

Java 9 - formeel Java Platform Standard Edition versie 9 - is eindelijk hier, en de Java Development Kit (JDK) is beschikbaar voor ontwikkelaars om te downloaden.

Het heeft verschillende belangrijke, maar controversiële nieuwe functies, maar is ook de laatste van de regel voor de oude stijl van Java-bezorging.

Waar kunt u de Java 9 JDK downloaden

Oracle heeft de Java SE 9 JDK en documentatie gepost om door ontwikkelaars te downloaden.

De belangrijkste nieuwe functies in Java 9

Debuteert bijna drie jaar na Java SE 8, Java SE 9 heeft een aantal belangrijke architecturale veranderingen, evenals een groot aantal verbeteringen.

De modulariteit van Java 9 is een game-wisselaar

De nieuwe, controversiële modulariteitsmogelijkheden, gebaseerd op Project Jigsaw, zullen zeker de interesse wekken van geavanceerde Java-winkels die willen zien wat JDK 9 nu te bieden heeft, zelfs als conservatievere winkels besluiten te wachten tot de modulariteit volwassen is geworden.

Modulariteit - in de vorm van het Java Platform Module System - verdeelt de JDK in een set modules die kunnen worden gecombineerd tijdens het uitvoeren, compileren of bouwen. Modulariteit wordt een "transitieve" verandering genoemd, waardoor de afhankelijkheden tussen modules kunnen worden begrepen.

De modulariteit van Java 9 is bedoeld om ontwikkelaars gemakkelijker geavanceerde applicaties te laten samenstellen en onderhouden. Bovendien zou het ervoor moeten zorgen dat Java beter kan worden teruggeschaald naar kleinere apparaten, terwijl de beveiliging en prestaties worden verbeterd.

De modulariteitsaspecten van Java 9 omvatten het verpakken van applicaties, het modulariseren van de JDK zelf en het reorganiseren van broncode in modules. Het build-systeem is verbeterd om modules te compileren en tijdens de build-tijd modulegrenzen af ​​te dwingen. JDK- en Java Runtime Environment (JRE) -afbeeldingen worden geherstructureerd om modules te verwerken. Ook zijn JavaFX UI-besturingselementen en CSS-API's nu toegankelijk voor modulariteit.

Een groot aantal configuraties wordt ondersteund; als resultaat moeten schaalbaarheid, beveiliging en applicatieprestaties worden verbeterd. Het eenvoudiger opschalen van Java naar kleine apparaten is een belangrijke motor van de modulaire inspanning.

Met modulariteit zullen ontwikkelaars beter in staat zijn om bibliotheken en grote applicaties te bouwen en te onderhouden voor zowel Java SE (Standard Edition) als Java EE (Enterprise Edition). Maar tijdens de ontwikkeling van Java 9 hadden Oracle, IBM, Red Hat en anderen grote meningsverschillen over hoe ze zo'n radicale verandering in het platform moesten aanbrengen. Het modulesysteem zelf werd in mei verworpen, maar werd pas na voortgang in juni bij een tweede stemming goedgekeurd.

Zelfs met overeenstemming tussen de grote Java-leveranciers, blijft er controverse over de vraag of modulariteit Java-ontwikkelaars veel goeds zal doen, waarbij sommige experts ja zeggen en anderen nee. Hoe dan ook, Java 9 is nu modulair opgebouwd.

Om migratie naar modulair Java 9 gemakkelijker te maken, staat Java 9 illegale reflectieve toegang toe voor code op het klassenpad, dat door de JRE wordt gebruikt om naar klassen en bronbestanden te zoeken. Deze mogelijkheid wordt niet meer toegestaan ​​na Java 9.

Compilerverbeteringen voor Java 9-code

De Java 9-upgrade biedt verschillende nieuwe mogelijkheden voor het compileren van code, waarvan de belangrijkste de AoT-compilatie is. Deze mogelijkheid bevindt zich nog in een experimentele fase en maakt compilatie van Java-klassen naar native code mogelijk voordat deze op de virtuele machine wordt gestart. Deze functie is bedoeld om de opstarttijd van zowel kleine als grote applicaties te verbeteren, met een beperkte impact op topprestaties.

Just-in-time (JIT) -compilers zijn snel, maar Java-programma's zijn zo groot geworden dat het lang duurt voordat de JIT volledig is opgewarmd, waardoor sommige Java-methoden niet-gecompileerd zijn en de prestaties verzwakken. Een compilatie van tevoren is bedoeld om deze problemen aan te pakken.

Maar Dmitry Leskov, marketingdirecteur bij Excelsior, leverancier van Java-technologie, maakt zich zorgen dat de vroegere compilatietechnologie niet volwassen genoeg is en zou willen dat Oracle had gewacht tot Java 10 op een meer solide versie.

Java 9 biedt ook fase twee van Oracle's slimme compilatie-implementatie. Deze functie omvat het verbeteren van de s javac stabiliteit en draagbaarheid van de  tool, zodat deze standaard kan worden gebruikt in de JVM (Java Virtual Machine). De tool wordt ook gegeneraliseerd, zodat deze kan worden gebruikt voor grote projecten buiten de JDK. JDK 9 heeft ook de javac compiler bijgewerkt,  zodat het Java 9-programma's kan compileren om op sommige oudere versies van Java te draaien.

Een andere nieuwe - maar experimentele - compilatiefunctie is de JVM Compiler Interface (JVMCI) op Java-niveau. Met deze interface kan een in Java geschreven compiler door de JVM als dynamische compiler worden gebruikt. De API van JVMCI biedt mechanismen voor toegang tot VM-structuren, installatie van gecompileerde code en aansluiting op het JVM-compilatiesysteem.

Het schrijven van een JVM-compiler in Java zou een compiler van hoge kwaliteit mogelijk moeten maken die gemakkelijker te onderhouden en te verbeteren is dan bestaande compilers die in C of C ++ zijn geschreven. Als gevolg hiervan zouden compilers die in Java zelf zijn geschreven gemakkelijker te onderhouden en te verbeteren moeten zijn. Andere bestaande inspanningen om in-Java-compilers mogelijk te maken, zijn onder meer het Graal Project en Project Metropolis.

Een nieuwe mogelijkheid voor compilercontrole is bedoeld om fijnmazige en methode-contextafhankelijke controle van JVM-compilers te bieden, waardoor ontwikkelaars de opties voor compilercontrole tijdens runtime kunnen wijzigen zonder prestatieverlies. De tool biedt ook tijdelijke oplossingen voor bugs in de JVM-compiler.

REPL komt eindelijk naar Java 9

Java 9 bevat een REPL-tool (read-eval-print loop) - een ander langetermijndoel voor Java dat in deze versie werkelijkheid wordt, na jaren van ontwikkeling onder Project Kulia.

Met de naam jShell evalueert REPL van Java 9 op interactieve wijze declaratieve statements en expressies. Ontwikkelaars kunnen feedback krijgen over programma's voordat ze worden gecompileerd door een paar regels code in te voeren.

Tot de mogelijkheden van de opdrachtregeltool behoren het aanvullen van tabbladen en de automatische toevoeging van de benodigde puntkomma's. De jShell API staat jShell-functionaliteit toe in IDE's en andere tools, hoewel de tool zelf geen IDE is.

Het ontbreken van een REPL wordt genoemd als reden voor scholen om weg te gaan van Java. (Talen zoals Python en Scala hebben lang een REPL gehad.) Maar de oprichter van Scala, Martin Odersky, zet vraagtekens bij het nut van een REPL in Java, door te zeggen dat Java statement-georiënteerd is, terwijl REPL's expressiegericht zijn.

Verbeteringen aan de Streams API in Java 9

Met streams in Java kunnen ontwikkelaars berekeningen uitdrukken, zodat gegevensparallellisme efficiënt kan worden benut. De Stream-mogelijkheid in Java 8 is bedoeld voor het declaratief verwerken van gegevens terwijl gebruik wordt gemaakt van multicore-architecturen.

In Java 9 voegt de Streams API methoden toe om voorwaardelijk items uit Stream te nemen en neer te zetten, Stream-elementen te herhalen en een stream te maken op basis van een nullable-waarde, terwijl de set Java SE API's die kunnen dienen als Streams-bronnen, wordt uitgebreid.

Code cache kan worden onderverdeeld in Java 9

Met JDK 9 kan de codecache in segmenten worden verdeeld om de prestaties te verbeteren en uitbreidingen mogelijk te maken, zoals fijnmazige vergrendeling. De resultaten zouden verbeterde sweep-tijden moeten zijn omdat gespecialiseerde iteratoren niet-methodecode overslaan; het scheiden van niet-methode, geprofileerde en niet-geprofileerde code; en het verbeteren van de uitvoeringstijd voor sommige benchmarks. 

Betere JavaScript-ondersteuning in Java 9 via Project Nashorn

Project Nashorn, dat een lichtgewicht JavaScript-runtime voor Java biedt, wordt verbeterd in JDK 9. Project Nashorn was een poging om een ​​krachtige, maar lichtgewicht JavaScript-runtime in Java te implementeren, in navolging van het Rhino-project dat in Netscape was begonnen. Project Nashorn werd belast met het mogelijk maken van het inbedden van JavaScript in Java-applicaties. Het voorzag Java van een JavaScript-engine in JDK 8.

JDK 9 bevat een parser-API voor de ECMAScript-syntaxisboom van Nashorn. De API maakt analyse van ECMAScript-code door IDE's en server-side frameworks mogelijk zonder afhankelijk te zijn van de interne implementatieklassen van Project Nashorn.

HTTP / 2-client-API komt naar Java 9

De bèta HTTP / 2-client-API is naar JDK 9 gekomen en implementeert in Java de upgrade naar het kern-HTTP-protocol van het web. WebSocket wordt ook ondersteund door de API.

De HTTP / 2-API kan de HttpURLConnection-API vervangen, die problemen heeft gehad, waaronder het ontwerp met protocollen die nu niet meer bestaan, ouder zijn dan HTTP / 1, te abstract zijn en moeilijk te gebruiken.

Verbeterde HTML5- en Unicode-ondersteuning in Java 9

In JDK 9 is de Javadoc-documentatietool verbeterd om HTML5-markeringen te genereren. De coderingsstandaard Unicode 8.0 - die 8000 tekens, 10 blokken en zes scripts toevoegt - wordt ook ondersteund.

DTLS-beveiligings-API is toegevoegd aan Java 9

Voor de veiligheid voegt Java 9 een API toe voor DTLS (Datagram Transport Layer Security). Het protocol is ontworpen om afluisteren, manipulatie en vervalsing van berichten in client / server-communicatie te voorkomen. Er is een implementatie voorzien voor zowel client- als servermodi.

Wat Java 9 veroudert en verwijdert

Java 9 veroudert of verwijdert verschillende functies die niet langer in zwang zijn. De belangrijkste daarvan is de Applet API, die verouderd is. Het is uit de mode geraakt nu beveiligingsbewuste browsermakers de ondersteuning voor Java-browserplug-ins hebben verwijderd. De komst van HTML5 heeft ook bijgedragen aan hun ondergang. Ontwikkelaars worden nu naar alternatieven geleid, zoals Java Web Start, voor het starten van applicaties vanuit een browser of installeerbare applicaties. 

De appletviewer-tool wordt ook verouderd.

Java 9 schaft ook de Concurrent Mark Sweep (CMS) garbage collector af, met ondersteuning om te stoppen in een toekomstige release. De bedoeling is om de ontwikkeling van andere garbage collectors in de virtuele HotSpot-machine te versnellen. De G1 garbage collector met lage pauze is bedoeld als vervanging voor CMS op lange termijn.

Ondertussen worden garbage collection-combinaties die voorheen verouderd waren in JDK 8 verwijderd in JDK 9. Deze omvatten zelden gebruikte combinaties zoals Incremental CMS, ParNew + SerialOld en DefNew + CMS, die extra complexiteit toevoegden aan de garbage collector-codebasis.

Java 9 verwijdert ook Java-waarschuwingen over importinstructies om te helpen grote codebases vrij te maken van lintwaarschuwingen. Met deze codebases moet verouderde functionaliteit vaak enige tijd worden ondersteund, maar het importeren van een verouderde constructie geeft geen waarschuwing als het gebruik van de constructie opzettelijk is en wordt onderdrukt.

Ook verwijderd in Java 9 is de mogelijkheid om de JRE tijdens het opstarten te selecteren via de Multiple JRE (mJRE) -functie. De mogelijkheid werd zelden gebruikt, bemoeilijkte de implementatie van het Java-opstartprogramma en het werd nooit volledig gedocumenteerd toen het debuteerde in JDK 5.

Oracle heeft de JVM TI (Tool Interface) hprof (Heap Profiling) -agent verwijderd, die is vervangen in de JVM. De jhat-tool werd ook verwijderd, omdat deze achterhaald was door superieure heap-visualizers en -analysatoren.

Java 9 is het einde van zijn regel als de nieuwe Java 9-regel begint

Je zou kunnen zeggen dat Java 9 met een knaller uitgaat, met alle nieuwe mogelijkheden. Oracle heeft onlangs onthuld dat Java 9 de laatste in zijn soort is, in termen van aanduiding en verstreken tijd tussen grote releases.

Vanaf nu is Java gepland om een ​​release-cadans van zes maanden te hebben, met de volgende hoofdversie, genaamd Java 18.3, verwacht in maart 2018, gevolgd door Java 18.9 zes maanden later.

Java's nieuwe release-cadans betekent ook dat JDK 9 niet zal worden aangemerkt als een ondersteuningsrelease voor de lange termijn. In plaats daarvan is de volgende langetermijnrelease Java 18.9.

Java's snellere release-cadans betekent dat ontwikkelaars niet zo lang hoeven te wachten op grote releases. Het kan ook betekenen dat ontwikkelaars Java 9 en zijn "onvolwassen" modulariteitsfuncties overslaan en zes maanden wachten op de nieuwe versie, waardoor alle knikken, zei Simon Maple, directeur van Java-belangenbehartiging bij ZeroTurnaround, leverancier van Java-tools.