3. 3
Meer dan een programmeertaal
Gestandaardiseerde
programmeertaal
Bedacht door Sun (nu
Oracle) in 1996
Ontwikkelomgeving
(JDK)
Libraries, tools, …
Virtuele Machine +
Runtime (JRE)
Abstracte, “eenvoudige”
machine om Java
applicaties te draaien
4. 4
Waarom een VM ?
Niet nieuw VMs bestonden al jaren
In principe makkelijker
te “porten”
Compiler is ook
eenvoudiger
“Write once, run
everywhere”
Zelfde applicatie voor
Windows/Intel,
Linux/ARM, …
5. 5
Waarom geen VM ?
Extra complexiteit
Runtime moet geïnstalleerd worden
Duurt langer om te starten
9. 9
HotSpot VM
Java bytecode naar machine code
Optimaliseert veelgebruikte “hot” code
Twee “JIT” compiler
instellingen
Client start sneller
Server is sneller na
verloop van tijd
14. 14
Native images
Vooraf omzetten naar
machine code
geen aparte VM
Gebruiken minder geheugen
Starten veel sneller
“micro-services”,
“serverless”
15. 15
Native images: nadelen
Alweer niet echt nieuw GCJ bestaat al lang
Compileren duurt (veel) langer
Werkt niet voor alle
applicaties
Vb. Spring framework is
erg lastig
Hallo, mijn naam is Bart Hanssens
en ik werk bij de FOD BOSA DG DT
Deze infosessie gaat over
Java Virtual Machines
- VM - en de nieuwe GraalVM.
Maar wat is Java nu precies ?
Java is niet alleen een
gestandaardiseerde programmeertaal,
Java is ook een complete
development kit:
een ontwikkelomgeving met een
hele reeks libraries en tools
zodat programmeurs meteen
aan de slag kunnen gaan.
Java code draait niet
rechtstreeks op een PC
maar in een "virtual machine".
Dit is een erg abstracte
en eenvoudige machine,
die op verschillende systemen
en platformen kan draaien.
Hiervoor is geen JDK nodig,
maar een kleinere runtime
de Java Runtime Environment.
Sun Microsystems (nu Oracle)
heeft Java bedacht in 1996.
Een VM was toen niets nieuws,
dat bestond al in de jaren 70.
Waarom dan zo'n VM gebruiken ?
In principe is het makkelijker
om Java te implementeren
op verscheidene systemen.
Daarvoor moet niet de hele JDK,
maar enkel de kleinere runtime
overgezet kunnen worden.
De code kan dan ongewijzigd
draaien op allerlei systemen.
Dezelfde applicatie draait
dus - ongewijzigd -
op Windows met Intel processor,
of Linux systeem op een ARM CPU:
"Write once, run everywhere"
Het is geen perfecte oplossing.
De runtime is gratis, maar
moet wel geinstalleerd worden.
Het opstarten van deze machine
neemt ook wat tijd in beslag.
Misschien enkele seconden,
maar dat kan al hinderlijk zijn.
En na het opstarten draait de
applicatie vaak wat trager
dan machine-specifieke code.
In dit schema zien we
het proces in werking.
Een programmeur schrijft code.
De compiler van de JDK
zet de code om
naar zogenaamde bytecode.
Deze bytecode draait ongewijzigd
in de runtime op Windows,
Linux, Mac enzovoort.
De runtime zelf,
weet eigenlijk niets van Java.
Ook andere talen kunnen
naar bytecode omgezet worden,
als er maar een compiler is.
Dit is bijvoorbeeld het gevallen
voor Scala, Groovy en Kotlin.
OpenJDK is een populaire JDK.
Sinds enkele jaren is dit
de "reference implementation".
Zoals gezegd is Java
een gestandaardiseerde taal,
maar omdat niet alles in detail
beschreven kan worden,
is deze open source versie
de bijkomende maatstaf:
bij twijfel over de specificatie,
is de werkwijze van OpenJDK
de "juiste" manier.
Andere producten, zoals
AdoptOpenJDK en Liberica
gebruiken OpenJDK als basis,
maar zijn 100% compatibel.
OpenJDK gebruikt HotSpot VM,
die een compiler bevat.
Deze compiler optimaliseert
veelgebruikte of "hot" code.
Dit gebeurt niet vooraf,
maar op het moment dat de code
wordt uitgevoerd, vandaar
de naam "Just in Time".
Dit kan op twee manieren:
"client" en "server"
De "client"-mode optimaliseert
de opstarttijd en probeert
minder geheugen te gebruiken,
wat deels ten koste gaat
van de snelheid van de applicatie.
De "server"-mode optimaliseert
voor snelheid, maar kan meer
geheugen verbruiken en start
ook iets trager.
Vroeger moest men ofwel de ene
ofwel de andere manier kiezen,
tegenwoordig worden ze
automatisch gecombineerd.
En nu is er dus GraalVM.
GraalVM is een project dat al
heel wat jaren bestaat, maar
nu is het een ondersteund product.
De naam is wat misleidend,
want het meer dan alleen een VM,
het is eigenlijk een heel platform.
Bedoeling is om een hele reeks
modulaires tools te maken,
die bruikbaar zijn voor
meerdere programmeertalen.
GraalVM bestaat in 2 versies:
een gratis "community" edition,
en een betalende versie.
De betalende versie is wat sneller,
en heeft extra functionaliteiten.
Met beide versies is het mogelijk
om "polyglot" applicaties te bouwen
en "native images" te genereren.
Een polyglot applicatie bevat
code van andere talen
Zo kan bijvoorbeeld een Java
applicatie een stuk Python
of Javascript uitvoeren.
Daarnaast kan GraalVM
- in bepaalde gevallen -
native executables maken.
Dit zijn gewone applicaties die
zonder aparte runtime draaien,
en waar de Java bytecode
wel vooraf naar machine code
omgezet moet worden.
Native images bevatten intern
nog een sterk afgeslankte VM,
SubstrateVM genaamd,
om geheugenbeheer te doen.
Hierdoor starten applicaties
een stuk sneller, en gebruiken
ze ook minder geheugen.
Dit is vooral belangrijk
voor "micro-services"
en "serverless" applicaties,
die vaak met tientallen of
zelfs honderden tegelijk
draaien in de cloud.
Dit is wederom niet nieuw.
Voordien was er ook al een
gratis compiler, GCJ,
maar deze werd zelden gebruikt.Het werkt ook niet voor alle
soorten Java applicaties.
Bijvoorbeeld applicaties gemaakt
met het "Spring" platform,
kunnen vaak niet "native" worden,
omdat ze heel dynamisch zijn:
tijdens het draaien kunnen
stukken code geladen worden,
die bij het starten nog niet
gekend zijn, wat het maken van
native images moeilijk maakt.
Hier wordt echter aan gewerkt,
en bij elke versie zijn er
meer mogelijkheden.
Een ander nadeel is dat het
compileren naar native images
- eenmalig - extra tijd neemt.
Toch zit er toekomst in.
Binnen de Java community
werd "project Leyden" opgestart,
met als doel om "static images"
te standardiseren.
Static images zijn applicaties
zonder de eerder vernoemde
"dynamische" eigenschappen.
Dit moeten dan niet per se
"native images" te zijn,
het is ook nuttig om
applicaties te optimaliseren
en verder te beveiligen.
Er zijn ook steeds meer
frameworks - zoals Quarkus en
Micronaut - die wel gemakkelijk
als native image draaien.
Voor alle duidelijkheid:
de Graal compiler kan ook
zonder native images
gebruikt worden.
Bijvoorbeeld ter vervanging
van de huidige Hotspot
JIT server compiler.
Dit is een experimentele
functie vanaf JDK versie 9,
en heeft als voordeel dat
de Graal compiler zelf
in Java is geschreven,
in plaats van in C++
(zoals de Hotspot compiler),
wat het makkelijker maakt
om de code te onderhouden
en verder te ontwikkelen.