Java niet risicoloos overal inzetbaar

Een enthousiaste Java-adept voelt zich geroepen op enkele punten kritiek te leveren op de beweringen van een 'Ontketende Java-gebruiker'. Hij betwijfelt ondermeer of Java bijzonder geschikt is voor realtime-systemen.

Hierbij plaats ik enige kanttekeningen bij de opmerkingen van Jan Monsuur in de ingezonden brief 'Ontketende Java-gebruikers (Computable, 27 maart). Ik wil me niet mengen in enige discussie over de praktijkervaring van auteurs van artikelen.
- De volwassenheid van de taal Java valt enigszins tegen, gezien de grote wijzigingen bij de verschillende versies van Java (bijvoorbeeld het event-model in 1.1, JFC/Swing in 1.2).
- Dankzij het gebruik van de garbage collector en de 'transparantie' daarvan is de prestatie van Java-applicaties niet voorspelbaar. Wanneer de applicatie veel te doen heeft, dus veel componenten start en uitvoert, zal het geheugengebruik toenemen. De 'garbage collector' komt vaak pas in actie als te laat is. Daarbij hangt het er nog van af of er met een move-and-copy, met een mark-and-sweep of met nog een ander algoritme wordt gewerkt. De verschillende 'garbage collection'-algoritmes beïnvloeden de prestaties op verschillende manieren.
Kortom: Java is met deze onvoorspelbaarheid niet bijzonder geschikt voor realtime-systemen of voor oltp-componenten. Overigens, wanneer de algoritme van de 'garbage collector' wel bekend is, kun je daar rekening mee houden, maar dan is de applicatie niet meer platform-(of VM!)-onafhankelijk.
- De opmerking over pointers is grotendeels waar. Het is trouwens in C++ ook mogelijk om middels 'smart pointers' de problemen voor een deel te voorkomen. In Java geldt echter ook dat niet alle pointers automatisch door de 'garbage collector' worden behandeld: bijvoorbeeld bij componenten die relaties hebben met de buitenwereld, zoals windows (niet alleen 'Windows'), moet expliciet met dispose-vrijgave plaatsvinden.
- Ten aanzien van compileren en testen ben ik het niet helemaal met de heer Monsuur eens. Zolang je met een compiler en een 'virtual machine' werkt, is er geen vuiltje aan de lucht. Zo gauw je met meerdere producten werkt, word je geconfronteerd met het feit dat verschillende compilers van hetzelfde Java-programma verschillende class-files kunnen maken.
Vervolgens kunnen verschillende virtual machines op een aantal punten hun eigen implementatie kiezen, bijvoorbeeld voor de class loader en voor de security manager, waardoor het runtime-gedrag niet altijd hetzelfde hoeft te zijn. Dat kan komen door bugs of door aspecten die nog niet in de Java-specificaties zijn vastgelegd.
Ik ben zelf overigens erg enthousiast over Java als taal, omdat er state-of-the-art constructies in zijn toegepast. Maar in mijn ogen maken de compilers en virtual machines voor Java, in combinatie met de groei van de taal zelf, deze taal nog niet tot een omgeving die risicoloos voor alle soorten toepassingen is te gebruiken.
 
Ir. Hans Miedema RI
Info Support b.v.