Er is geen koe zo bont of… Met dat gezegde in het achterhoofd werd de taal Java onlangs tegen het licht gehouden, met als resultaat elf ‘zwakke plekken’. Java-architect E.R.Kasanardjo vindt dat teveel van het ‘goede’ en poetst een aantal smetten op het blazoen van deze taal weg. Zo meent hij dat enkele punten van kritiek eigenlijk de ondersteunende bibliotheken betreffen, en niet Java zelf.
Chris Laffra levert in zijn artikel ‘Java-trein dendert langs alle platformen’ (Computable, 15 augustus) behoorlijk wat kritiek op Java en weet maar liefst elf zwakke punten aan te wijzen. Na het lezen van het artikel ben ik tot de conclusie gekomen dat hij de ‘zwakke punten’ nogal heeft aangedikt. Ik laat ze stuk voor stuk de revue passeren (zie het bewuste artikel voor de gebruikte afkortingen).
1. De ontwikkelomgevingen van Java leggen de nadruk op Java als programmeertaal en niet op zaken als versiecontrole, databases, linken met bestaande code, Corba, het opdelen van Java in separate processen en het analyseren van Java-code.
Laffra begint zijn betoog met een misser. Een ontwikkelomgeving en tools voor een programmeertaal zijn iets anders dan de programeertaal zelf. Dat de bestaande omgevingen niet de mogelijkheden hebben die Laffra daar graag in zou willen, is geen beperking van Java maar een beperking van de tools.
2. Java presteert minder snel dan de C/C++ code omdat de bytecode geïnterpreteerd wordt. Wel zijn er jit-compilers die de bytecode omzetten naar platformspecifieke code, zodat Java-applicaties sneller lopen. Laffra geeft aan dat er allerlei onderzoeken worden gedaan om de prestaties van Java op te krikken.
Het argument van ‘minder snel’ is waar. Dat komt natuurlijk doordat snelheid wordt ingeruild voor platform-onafhankelijkheid. Ik denk wel dat Laffra een fout maakt door een jit-compiler als een optimalisatietechniek te zien. Naar mijn idee is het een compiler die een source inleest (in dit geval bytecode) en er machinecode voor genereert. De claim dat jit alleen goed werkt voor Java-methods van gemiddelde lengte en met C-achtige loopconstructies, wordt niet toegelicht. Naar mijn idee werkt jit altijd.
3. Het Java-beveiligingsmodel is een alles (applets) of niets (applicaties) aanpak. Laffra betoogt dat binnen Java ook encryptie en authenticatie gewenst zijn. Hij merkt op dat deze technieken nog in de kinderschoenen staan en dat het bijvoorbeeld moeilijk is om als leverancier een betrouwbare (’trusted’) naam te krijgen.
Ik ben het hier mee eens. Dat er überhaupt een beveiligingsmodel in Java zit, wil ik eerder een sterk punt noemen.
Applet-downloadtijd
4. Interactie met de omgeving vindt Laffra ook een zwak punt. Hij noemt hierbij database-interactie, client/server-architecturen en koppelingen met bestaande programmatuur. De database-interactie wordt met Jdbc, Jdbc-Odbc-Bridge en later ook met JTS opgelost. De client/server-problematiek is (in opklimmende volgorde van flexibiliteit) op te lossen door sockets, RMI en Corba. Ik snap niet precies wat Laffra bedoelt als hij zegt dat interactie een zwak punt is. Ik denk eerder dat de punten die hij aanstipt juist aangeven dat interactie met de omgeving goed mogelijk is in Java.
5. De applet-downloadtijd is een volgend zwak punt. Browsers cachen applets niet, dus moeten bij het opstarten van een applet alle bijhorende classes worden opgehaald, wat leidt tot een trage opstarttijd. Oplossingen zijn het bundelen van classes in een archief (dit is al mogelijk) en het cachen van applets in browsers (hier wordt aan gewerkt). Laffra noemt ook het Marimba/Castagnet-concept; aan de ontvangende kant kun je dit zien als een cache van applets die zichzelf up-to-date houdt. Ik ben het eens met Laffra dat de downloadtijd voor zware applets een groot bezwaar kan zijn. Aan een kant is dat niet zo vreemd: Java is ontstaan vanuit het idee van een lichtgewicht netwerkcomputer, dus een client waarop lichte applets draaien. Juist omdat de applets licht zijn, is het goedkoop om ze elke keer te laden. Hierdoor heeft de gebruiker altijd de nieuwste versie. Er is nu een verschuiving gaande waarbij steeds zwaardere Java-applicaties/applets worden gebouwd. Om deze up-to-date te houden, zonder al te nare gevolgen voor de downloadtijd, moeten er verfijnde technieken worden bedacht. Men is er dus ook mee bezig, zoals Laffra aangeeft. Merk echter wel op dat met deze ontwikkelingen het idee van de lichtgewicht client ongemerkt aan de kant wordt geschoven: clients moeten steeds meer kunnen.
6. Java-decompilatie noemt Laffra ook een zwak punt. Er zijn tools om bytecode te decompileren tot de oorspronkelijke Java-code. Dit opent mogelijkheden voor concurrenten. Met ‘post-processors’ is het echter goed mogelijk om de gedecompileerde code (voor mensen) onleesbaar te maken. Decompilatie van bytecode is een punt waarmee je wel rekening moet houden, als je wilt dat de sourcecode geheim blijft. Dit lijkt mij echter geen echt zwak punt gezien de aanwezige oplossingen.
Veiligheid voor snelheid
7. Volgens Laffra is de api ook een zwak punt. Hij haalt een aantal voorbeelden aan: inconsistentie in argumentvolgorde in vergelijkbare methods ‘setElementAt(Object, int)’ en ‘setCharAt(int, char)’, inconsistentie in naamgeving bij gelijksoortige concepten bij ‘classes vector’, ‘string’ en ‘array’ waarvan de grootte wordt verkregen door respectievelijk size(), length() en length; alle generieke classes zijn ’threadsafe’ hetgeen ze trager maakt; strings kunnen niet als ‘reference’ worden meegegeven in een method.
Voor wat betreft de inconsistentie in vergelijkbare begrippen geef ik Laffra gelijk; dat had beter gekund. Maar volgens mij is dit niet zozeer een zwak punt van Java zelf, maar meer van het ontwerp van de bibliotheken.
Met de andere punten die Laffra aanhaalt, kan ik het niet eens zijn. Dat ’threadsafe’ classes trager zijn, spreekt vanzelf: veiligheid wordt hier ingeruild voor snelheid. En wat hij over string zegt klopt, maar ‘string buffer’-objecten, die zich als strings gedragen, kun je wel als ‘reference’ doorgeven.
8. Java is eigenlijk te snel geaccepteerd, waardoor veel software ontwikkelaars nu met het probleem zitten van incompatibiliteiten tussen api’s van de JDK 1.0.2 en de JDK 1.1. Dit is inderdaad een zwakke plek. Bij het ontwikkelen moet je voorlopig rekening houden met 1.0.2 browsers, maar deze toch volgens de 1.1 api proberen te gebruiken. Dit is vaak, maar niet altijd mogelijk en vereist van de programmeur vaak rare fratsen.
9. Inconsistentie tussen Java-implementaties is het volgende punt. Er zijn bijvoorbeeld subtiele verschillen in de implementatie van de virtuele machine van Microsoft en Netscape. Ook bibliotheekimplementaties kunnen op kleine punten inconsistent zijn. Er wordt gewerkt aan een globale standaard. Klopt.
10. AWT is een grafische bibliotheek met een api waarmee platform-onafhankelijk gui’s te programmeren zijn. De implementatie van de AWT maakt echter gebruik van de lokale objecten; dat betekent dat een button in een Win32-omgeving zich net even anders kan gedragen dan in een Motif-omgeving. Verder zijn de beschikbare objecten in de AWT beperkt. Er zit een nieuwe bibliotheek aan te komen: de JFC die beide bezwaren zal opvangen. Dit nadeel van Java zie ik als een beperking van de AWT, maar gezien de ontwikkeling van JFC, van voorbijgaande aard. Het is niet zozeer een zwakke plek van de taal Java, maar van de ondersteunende bibliotheken.
11. Hoewel Java zelf een eenvoudige taal is, maken de vele bibliotheken met elk een eigen api de taal toch complex.
Ik vind dit geen zwak punt van Java zelf; dit heeft weer te maken met de bibliotheken die bij Java horen. Het is heel simpel: als je allerlei programmaconstructies wilt kunnen bouwen, dan moet je daarvoor gereedschappen (bibliotheken) en kennis hebben. De gebruikte programmeertaal bepaalt welk gereedschap je nodig hebt en hoe je deze vasthoudt.
E.R.Kasanardjo,
Java-architect Infopulse, Best
