Java-trein dendert langs alle platformen

Twee jaar geleden had nog bijna niemand van Java gehoord. Tegenwoordig heeft iedere grote softwareproducent wel een Java-product. Java’s gebruiksgemak, platform-onafhankelijkheid en integratie met het Web trekt de aandacht van bijna ieder programmeergebied. Dit heeft geleid tot een unieke mate van acceptatie en maakt Java tot de invloedrijkste programmeertaal ooit.

Moet u op de Javatrein springen? Dat kan een reis met hindernissen worden. Moet u achterover leunen en afwachten? Dan mist u misschien de grootste softwarerevolutie van deze tijd. Java-expert Chris Laffra vertelt wat u moet weten over Java voor uw bedrijfsdoelstellingen als u de taal nu wilt gebruiken. Hij geeft aan wat de zwakke plekken zijn, aan welke oplossingen wordt gewerkt en wanneer het probleem waarschijnlijk is opgelost.
Java is één van de interessantste nieuwe softwaretechnologieën. Terwijl geen van de elementen in de Java-omgeving op zich uniek is, combineert Java deze elementen tot één samenhangend geheel. Die elementen bevatten: platform-onafhankelijkheid door middel van een virtuele machine (VM), krachtige object-georiënteerde technieken, zoals ‘classes’ (klassen) en ‘interfaces’, multiple threads, garbage collection, exception handling, late binding, type checking, beveiliging en het applet/browser download-model.
Sun, de ontwikkelaar van Java, koos ervoor om dit aantrekkelijke pakket gratis te verspreiden en de broncode onder licentie te verstrekken. Dat is belangrijk geweest voor het vroege succes. Later heeft Sun het afgeleide Javasoft opgericht, geconcentreerd op Java-ontwikkeling.
Vroegtijdige ondersteuning door grote leveranciers, zoals Netscape, heeft enorm bijgedragen aan de acceptatie. De berichtgeving in de media, die Java vaak het wondermiddel noemden voor alle softwareproblemen, hielp ook mee om het nieuws te verspreiden. Gesteund door de groeiende angst voor de complexiteit van C++ en de toenemende interesse in gedistribueerde systemen werd Java tot de spreekwoordelijke onstopbare trein. Hoewel de trein niet te stoppen lijkt, heeft het traject nog wel de nodige hobbels. Dit artikel behandelt de ‘zwakke plekken’ in de Java-taal en -omgeving die uw projecten zouden kunnen bedreigen.
Over de vele voordelen van Java is al uitvoerig bericht in de media (ondermeer recent in Computable, 18 juli en 31 augustus). Kort samengevat zijn dat ondermeer: platformonafhankelijkheid door het gebruik van een virtuele machine, geschiktheid als programmeertaal voor Internet en vanwege zijn eenvoud snel te leren door C++-programmeurs.

Java-ontwikkelomgevingen

De eerste zwakke plek betreft de Java-ontwikkelomgevingen. Javasoft distribueert gratis de Java Development Kit (JDK). Deze is te vinden op http://java.sun.com. De JDK bevat een Java VM (Virtuele Machine), een ‘Java naar bytecode’-compiler en een debugger. Samen met een standaard editor is deze omgeving voldoende voor het ontwikkelen van basale Java-applicaties.
Verder is een aantal Java-ontwikkelomgevingen gemaakt uit omgebouwde C- en C++-ide’s (interactive development environments). De overeenkomst tussen C++ en Java stelde een bedrijf als Symantec in staat om binnen een ongelooflijk korte tijd met de eigen Java-ontwikkelomgeving Cafe te komen. Microsoft kon ook snel met een omgeving komen, gebaseerd op zijn Visual C++-product. Beide zijn niet in Java geschreven, maar in een mix van C en C++, in verband met de snelheid en betrouwbaarheid.
Een ambitieuzer project is Java Workshop van Sunsoft. Het doel is een geheel in Java geschreven Java-ontwikkelomgeving (editor, compiler en debugger). Java Workshop gebruikt de browser-methodiek en er is een naadloze integratie met Html-documentatie. Geschreven in Java liep dit product, één van de eerste grote Java-projecten, tegen de serieuzere kinderziektes aan.
IBM’s Visualage For Java gaat ook zijn eigen weg door te kiezen voor een omgeving gebaseerd op het Smalltalk-model. Het ondersteunt met name een dynamische interactieve Java-executie in de ide, vergelijkbaar met Smalltalk en het populaire Envy-ontwikkelteamsysteem. Bèta-versies zijn beschikbaar op http://www.software.ibm.com/ad.
Voor wat betreft het compileren voorzien zowel Symantec als Microsoft in een compiler die zelf is geschreven in C of C++. IBM levert Jikes!, een snelle compiler die de Java-compiler uit de JDK vervangt en tegelijkertijd betere diagnoses en foutboodschappen levert. Jikes is op te halen op http://www.alphaworks.ibm.com.
In principe zijn alle genoemde ontwikkelomgevingen onvolwaardige kopieën van de omgevingen die beschikbaar zijn voor C++. Ze bieden dezelfde compile/edit-cyclus, maar de simpelheid van de Java-taal en het formaat van de huidige Java-projecten zorgen voor een snellere hercompilatie. Verder leggen deze producten nog steeds de nadruk op Java als programmeertaal en niet op zaken als een gemeenschappelijke ontwikkelomgeving (met bijvoorbeeld versiecontrole), connectie met databases, het linken met bestaande code, Corba-services (Common object request broker architecture), het opdelen van Java in separate processen en het analyseren van Java-code voor prestatie- en synchronisatiedoeleinden. De huidige Java-projecten moeten dit zelf maar oplossen door of ervarener programmeurs in te zetten of beperktere doelstellingen te kiezen.

Javabeans

Los van de belangrijkste ide’s is er een aantal Java-tools die voorzien in databasetoegang via de Jdbc-laag (Java database connectivity). In 1998 zullen de meeste Java-tools naar verwachting verder groeien naar volledige ondersteuning van multitier applicatie-ontwikkeling en tuning (fijn-instelling), vergelijkbaar met de interessante maar geslotener Forte-omgeving. De eerste stap zal zijn het Corba-bewust maken van de omgevingen om later de ontwikkelaar in de gelegenheid te stellen aandacht te besteden aan load balancing (gelijkmatige taakverdeling) van client/server-toepassingen.
De nieuwe generatie ontwikkelomgevingen zal niet de fouten in de huidige ide’s verbeteren, maar zich concentreren op Javabeans in plaats van het simpel intikken van Java-broncode en die compileren. Javabeans zijn softwarecomponenten, Java-klassen met specifieke methods voor runtime-interactie. Een Javabean-applicatie wordt samengesteld uit componenten die zich conformeren aan dit protocol. Javabeans zijn in Java te schrijven en daardoor net zo overdraagbaar als Java zelf.
Behalve dat het voorziet in een standaard interactiemodel ondersteunt Javabeans het ‘visueel ontwerpen’. Ontwikkelaars kunnen Javabeans uit een standaard pakket slepen en ze visueel verbinden. Javabeans produceren events. De tools bieden de ontwikkelaar de mogelijkheid om connecties te maken om op die events te reageren. Dit alles gebeurt zonder één regel code te schrijven. De omgeving genereert de gewenste code, en compileert en test deze. In principe geeft een Javabean-tool een hogere productiviteit dan Visual Basic, terwijl hij voorziet in een applicatie die volledig platformonafhankelijk is. Voorbeelden van omgevingen voor het werken met Javabeans zijn te vinden op Javasofts website (http://splash.javasoft.com/beans/). Dergelijke omgevingen zullen de acceptatie van Java bij een grotere groep ontwikkelaars versterken en bijdragen aan de echte toekomst van Java: component-gebaseerde ontwikkeling.

Prestatie

De tweede zwakke plek betreft de prestatie. Als we groeien van ‘opsmuk’ Java-applets in webpagina’s naar Java-bedrijfsapplicaties, moeten we in ons ontwerp rekening houden met de prestaties. Dat betekent leren omgaan met de mogelijkheden en beperkingen van standaard onderdelen van Java, het dubbel bufferen van beeld, het bufferen van invoer en uitvoer, en het gebruiken van geschikte datastructuren. Verder zult u zelf ervaring moeten opdoen met het ontwikkelen van dit soort applicaties. Zelfs als u meent dat Java snel genoeg is voor uw project, zullen sceptici binnen of buiten uw ontwikkelteam u toch nog daarop aanspreken. Ze zullen u erop wijzen dat Java niet gemaakt is om met Fortran en C te concurreren op snelheid. Deze klachten beschouwend kunnen we kijken naar de realiteit van vandaag en het potentieel van morgen.
Sommige beginnende Java-ontwikkelaars zullen stellen dat Java geïnterpreteerd wordt en precies daardoor zo langzaam is. Java hoeft echter niet geïnterpreteerd te worden. Een jit-compiler (just in time) kan de Java-bytecodes vertalen naar platformspecifieke instructies zodat deze sneller lopen. De jit-compilers zijn voornamelijk effectief voor methodes van gemiddelde grootte en met simpele C-achtige loopconstructies. Jit’s gebruiken in feite standaard C-optimalisatietechnieken. Terwijl jit’s beschikbaar zijn voor vele platformen, waaronder Symantec, Microsoft, HP en IBM, zijn ze geen noodzakelijk deel van de het Java-systeem. Kijk daarom naar kritische platforms of er rekenintensieve methodes zijn.
Naast jit’s zijn er omgevingen die een heel Java-programma compleet omzetten in uitvoerbare code, zoals Supercede van Asymetrix (http://www.asymetrix.com) en Hpcj van IBM (http://www.alphaworks.ibm.com). Deze omgevingen verliezen binaire overdraagbaarheid, maar bieden betere optimalisatie dan jit-compilers. Beperkte platformoverdracht en hogere ontwikkelkosten moeten worden afgewogen tegen verbetering van de prestatie. Zie deze oplossingen als deel van een migratiestrategie.

Optimalisatie

Een meer ervaren ontwikkelaar zal beseffen dat Java te compileren valt, maar misschien toch blijven stellen dat Java te langzaam is, zelfs met jit. De meesten baseren zich daarbij op ervaring met rekenintensieve toepassingen die draaien op te kleine machines. We moeten ons realiseren dat de prestatie van het hedendaagse Java meer dan voldoende is voor veel moderne toepassingen die zich richten op gebruikersinteractie, communicatie of een snelle ontwikkeltijd.
Verder zijn moderne systemen te bouwen met meerdere talen. Bedrijfstoepassingen en architecturen baseren zich op gedistribueerde applicaties die zich uitstrekken over meerdere knooppunten in een intranet. Een standaard model plaatst Java-clients, wellicht als applets in een webbrowser, die zich verbinden met diverse services via Corba, gebruikmakend van het Iiop-protocol. In dit model kunnen de servers in C++ blijven draaien (we noemen C++ al legacy), terwijl de meer interactieve en snel wijzigende multiplatform-clients in Java te schrijven zijn.
Zelfs de prestatiekritische toepassingen kunnen in de toekomst baat hebben bij Java. Naarmate de ontwikkelkosten blijven stijgen en de vraag naar nieuwe projecten dramatisch toeneemt, vormt niet de computer- maar de ontwikkelproductiviteit de sleutel tot succes. Zelfs als Java wat langzamer loopt, zullen de voordelen van een eenvoudige taal, een bredere standaard, een open architectuur en platformonafhankelijkheid eraan bijdragen dat grote delen van de systemen in Java worden gebouwd. Hier liggen mogelijkheden in het koppelen van prestatieservers aan meer dynamische drivers die in Java zijn ontwikkeld.
Ten slotte zijn er ontwikkelaars die zeggen dat Java nooit zo snel zal lopen als C++. De gedachte dat het afhangt van ‘wat je ermee bouwt’ zal hen er niet van overtuigen dat Java toekomst heeft. Als Java echter sneller dan C++ zou kunnen zijn? Op de afgelopen Javaone-conferentie introduceerde Javasoft onlangs Hotspot, een nieuwe VM-technologie. Hotspot biedt dynamische optimalisatie van Java-methods, zich concentrerend op de ‘hotspots’, de meest uitgevoerde delen van een Java-programma. Gebruikmakend van een ultieme prestatie-analyse, een eindgebruikersprofiel, biedt het de beste fijn-instelling die mogelijk is. De Hotspot-optimalisatie verbetert zelfs de C-achtige optimalisaties die jit-compilers al aanbrengen. De Hotspot-technologie kwam uit een ander door Sun gesponsord project, de Self-programmeertaal, ontwikkeld als uitgebreid onderzoeksproject bij de Stanford Universiteit in Californië.
Het heeft geen zin om onmiddellijk grote rekenprogramma’s te gaan herschrijven in Java, maar het is ook zinloos om vooroordelen te hebben over het potentieel van Java’s prestaties.

Beveiliging

De derde zwakke plek ligt in de beveiliging. Java’s beveiligingsmodel is een ‘alles of niets’-aanpak. Java verdeelt programma’s in applets onder beveiligingscontrole en ‘programma’s’ zonder beveiligingscontrole. Applet-beveiliging is gebaseerd op een ‘zandbak’-model, waarin het benaderen van systeembronnen strikt gelimiteerd is. Applets worden getransporteerd naar een uitvoeringsomgeving waar ze naar hartenlust kunnen functioneren, zolang ze maar in de zandbak blijven. Alleen als de implementatie van het Java-beveiligingsmechanisme bugs bevat, kunnen de applets ontsnappen uit de zandbak en overal zand gaan strooien. Enkele van deze fouten kwamen voor in bijvoorbeeld de vroege versies van Netscape’s virtuele machines. Dat leidde tot publicaties en bezorgdheid over de veiligheid van Java.
In de praktijk heeft het Java-applet-beveiligingsmodel bewezen te werken, maar blijkt het te beperkend voor sommige projecten. Java-programma’s kennen helemaal geen beveiligingsmodel. Tot nu toe hebben bedrijfsprojecten gekozen voor het strikte applet-model. In deze projecten wordt alle invoer en uitvoer geleid via de server die de applet heeft aangeboden. Daaruit vloeit het risico voort van slechte prestaties en het ontstaan van minder bruikbare systemen, omdat de applets geen gebruik kunnen maken van lokale informatie.
Applet-beveiliging ondersteunt het gebruik van online adverteren: het beveiligt de browser tegen corrupte, foutieve of geïnfecteerde bytecodes. Applet-beveiliging doet echter niets voor elektronische handel, het beveiligen van data op Internet en de beveiliging die nodig is voor samenwerkende computersystemen, bijvoorbeeld om lokale informatie te benaderen. Uiteindelijk zal Java toegang moeten krijgen tot een encryptiestandaard om data op een netwerk te beveiligen en tot een systeem van elektronische handtekeningen om lokale toegang toe te staan. Encryptie, als basiselement voor Internethandel, zal komend jaar beschikbaar komen.
Elektronische handtekeningen zullen langer op zich laten wachten. Het kan daarbij gaan om organisaties die software verstrekken en deze voorzien van een digitale handtekening, waarna de gebruiker bepaalt of hij de software van die organisatie wil vertrouwen. Elektronische handtekeningen zijn inmiddels wel toegevoegd aan de Java-archiefbestanden in JDK 1.1. Dat biedt de gebruiker de mogelijkheid om de deur te openen voor applets met beperkte toegang tot lokale machines, bijvoorbeeld om lokaal bestanden op te slaan. Naar verwachting zullen de browsers komende winter met deze mogelijkheden worden uitgerust.
Dit geeft Java een betrouwbaar zandbakmodel met mogelijkheden uiteenlopend van totale controle tot totale vrijheid. Het vervalsen van elektronische handtekeningen is uitermate moeilijk en de technologie is betrouwbaar. Het is voor een leverancier moeilijk om een betrouwbare naam te krijgen. Er is weinig praktijkervaring met systemen met elektronische handtekeningen. Het is een interessant gebied om te verkennen, maar verwacht niet te snel resultaten.

Interactie

De vierde zwakke plek is de interactie met de omgeving. Java’s eerste applets toonden leuke animaties, bijvoorbeeld de bekende zwaaiende Duke, of andere op zichzelf staande applicaties, zoals lopende teksten. Echte programma’s vragen echter om interactie met de omgeving. Dat omvat het bewaren en laden van gegevens uit relationele databases, ondersteuning voor client/server-architecturen en verbindingen met bestaande programmatuur en infrastructuren. Dit is allemaal met het huidige Java te realiseren, maar is wel een arbeidsintensief en foutgevoelig proces. Gelukkig is het één van de gebieden die het snelst in beweging zijn en een terrein met weinig risico’s voor degenen die in een vroeg stadium met Java in zee zijn gegaan.
Om toegang tot SQL-databases mogelijk te maken, is Java uitgebreid met de Jdbc-laag (Java database connectivity). Er is een Odbc-brug gemaakt om toegang te krijgen tot Odbc-conforme databases. Voor praktisch alle commerciële databases is wel een Jdbc-laag beschikbaar (zie http://splash.javasoft.com/jdbc/jdbc.drivers.html). Jdbc is nu beschikbaar en zal naar verwachting uitgebreid aan testen worden onderworpen, zodat de risico’s voor bestaande investeringen in relationele databases laag zijn als men overgaat tot het gebruik van Java.
Javasoft en zijn partners werken ook aan een transactiemodel: JTS (Java Transaction Services api – application programming interface). JTS is gebaseerd op het OMG-transactiemodel en wordt voorgesteld als de standaard voor het verwerken van transacties in Java. Dit zal meer tijd nodig hebben om volwassen te worden.

Communicatiemechanisme

Om delen van een applicatie te scheiden in een client- en een serverdeel moesten vroege Java-applicaties hun toevlucht nemen tot het opzetten van een eigen socket-verbinding tussen de client en de server, en hun eigen protocol ontwikkelen. Dit is niet langer nodig. Als zowel de client als de server in Java zijn geschreven, is het aanbevolen communicatiemechanisme de Java Remote Method Invocation-api (RMI). Een speciale RMI-compiler neemt een Java-klasse en genereert de objectomgeving voor zowel de client- als de serverkant. Voor heterogene omgevingen, bijvoorbeeld een client in Java en een server in C++, is Corba van OMG de meer aangewezen weg. Met Corba wordt de interface beschreven door gebruik te maken van de Corba IDL (Interface definition language). Een speciale compilertool vertaalt dan de IDL in Java. Zowel RMI als Corba zijn eenvoudig in het gebruik. RMI maakt deel uit van JDK 1.1 (nu beschikbaar). De productversie van Java IDL wordt later dit jaar verwacht. In de loop van dit jaar is ook te verwachten dat de Corba-technologie van Visigenic zal worden opgenomen in de Netscape-browser. Andere producten zijn al beschikbaar – bijvoorbeeld Orbixweb van Iona (http://www.iona.com) – en die werken ook prima. Javasoft heeft onlangs aangekondigd te gaan samenwerken met de OMG aan een upgrade van Corba Iiop, zodat deze Java RMI-voordelen kan ondersteunen.
Soms wil men bestaande code opnemen in een Java-applicatie. Een op Corba gebaseerd systeem met aan de ene kant Java en aan de andere kant een oud systeem kan een oplossing zijn om Java te verbinden met bestaande systemen. Als sprake is van een grote hoeveelheid oude code die verbeterd moet worden of uitgebreid moet worden met een Java-interface, valt de code ook direct vanuit een Java-applicatie te benaderen via native methods. Dat zijn methods in een Java-klasse waarvan de eigenschappen beschreven zijn in Java, maar waarvan de feitelijke implementatie geschreven is in C. De C-code is gecompileerd en beschikbaar in executeerbaar formaat (vaak in de vorm van een DLL). Omdat de ‘native method’ platformafhankelijk is, verliest men platformonafhankelijkheid (de applet kan niet langer overal draaien omdat toegang tot de DLL een noodzaak is). Als de te herschrijven hoeveelheid code echter aanzienlijk is en te verwachten valt dat de applicatie op een specifieke locatie zal draaien, kan deze aanpak aanvaardbaar zijn.
Een andere effectieve combinatie met Java RMI is ook mogelijk: een client, geschreven als een applet in Java, die via RMI verbonden is met een Java-server die gebruik maakt van ‘native methods’ om C- of C++-code te benaderen. Dit voorkomt dat clients, bijvoorbeeld applets, gebruik moeten maken van ‘native methods’ en dat men DLL’s moet compileren en installeren voor ieder te voorzien gebruikersplatform. Het verplaatst ook al de communicatie-code naar Java. Dat vereenvoudigt het aanmaken van gedistribueerde systemen.

Applet-ophaaltijd

De vijfde zwakke plek ligt in de applet-ophaaltijd. Java is een geweldige taal voor het ontwikkelen van platformonafhankelijke code die een browser kan ophalen in de vorm van een applet. Het ophalen van deze applets kan echter een aanzienlijke hoeveelheid tijd kosten.
Een goed voorbeeld van het applet-model is de Corel Office Suite voor Java. De bètaversie die op dit moment gratis te downloaden is, bevat ongeveer tweeduizend Java-klassebestanden. Dat resulteert in ongeveer 11 MB aan code. Met de huidige netwerkbandbreedte is het onpraktisch zo’n applicatie ergens anders te draaien dan op een hoge-snelheids lan. Dat was ook één van de ontwerpdoelen van Corel. Als een systeem echter gebruik moet maken van bijvoorbeeld telefoonlijnen, is het verstandiger om te kiezen voor een bescheidener client.
De huidige browsers cachen geen Java-bytecode. Plaatjes en Html-pagina’s worden lokaal opgeslagen, zodat bij een latere referentie ernaar de responstijd beter is, in tegenstelling tot bij een pagina die een applet bevat. Als de pagina meerdere malen wordt opgevraagd, wordt de applet niet opgeslagen maar iedere keer opnieuw opgehaald, ook als de code in de tussentijd niet is gewijzigd. Applets zijn vaak honderden kilobytes groot. Dat leidt vaak tot meerdere http-connecties om de applet helemaal te kunnen inlezen. In het geval van langzame modemverbindingen kan dat een probleem worden. Naar verwachting zullen browsers rond komende winter het cachen gaan ondersteunen.
Zowel Netscape Navigator als Microsoft Internet Explorer ondersteunen het mechanisme om meerdere klasse-bestanden in één pakket te plaatsen. Op dit moment ondersteunt Netscape Navigator zip-bestanden zonder compressie. Microsoft IE gebruikt een ander archiefmodel, CAB-bestanden (cabinet). CAB-bestanden gebruiken compressie en zijn daardoor kleiner. Om de naam van het archiefbestand weer te geven, worden verschillende Html-’tags’ gebruikt. Applet-ontwikkelaars zullen hiermee rekening moeten houden als ze willen dat hun applet zo snel mogelijk op te halen is. JDK 1.1 bevat het begrip JAR-bestanden (Java Archive). Die zijn een specificatie voor zip-bestanden met compressie. Zowel JAR- als CAB-bestanden bieden de mogelijkheid van encryptie en het toevoegen van elektronische handtekeningen. Voor eind 1997 zal het waarschijnlijk mogelijk zijn om applets efficiënter op te halen.

Sneller

Het Java-applet-ophaalmodel (in feite doet de browser dat) houdt in dat alwat een applet nodig heeft en niet in de kern-bestanden beschikbaar is, moet worden opgehaald voordat een applet kan lopen. Hoewel de klasse-bestanden te verzamelen zijn in een archief, is het met de huidige Html-opdrachten slechts mogelijk om één archief op te geven. Dit betekent dat de browser �f alles, �f niets moet ophalen. Het zou beter zijn als de gebruiker een zoekpad kan opgeven waar de browser de klasse-bestanden kan vinden. Het resultaat zou zijn dat meerdere applets dezelfde herbruikbare Java-klassen kunnen gebruiken en de applet-specifieke bytecodes ophalen op hun eigen locatie. Een andere applet die gebruik maakt van de gedeelde code, opgehaald door een eerdere applet, zou hierdoor veel sneller laden. De ophaaltijd zou beter worden. Ik ben me niet bewust van plannen om de Html-specificatie uit te breiden met de mogelijkheid om meerder archiefbestanden op te geven. Het dichtst in de buurt komen de inspanningen om de Java-kernbestanden uit te breiden als een vorm van gemeenschappelijke code.
Een alternatief, veelbelovend, softwaredistributiemodel is Castanet van Marimba (http://www.marimba.com). Op de desktop van de gebruiker wordt een ontvanger geplaatst. Deze haalt automatisch een applicatie op die een Castanet-zender verzendt. Elk deel van de applicatie heeft een versie-aanduiding. De ontvanger controleert regelmatig bij de zender of één van de onderdelen is vernieuwd. Dat geldt voor zowel Java-klassebestanden als -databestanden. De ontvanger haalt vervolgens alleen die onderdelen op die zijn gewijzigd en die nodig zijn om de gebruikerskopie te actualiseren. Dientengevolge vernieuwt Castanet de applicatie automatisch en incrementeel. Als hij is opgehaald, blijft de applicatie lokaal bij de gebruiker en valt hij te draaien zonder een netwerkverbinding of zelfs een browser. Het ophalen kan gebeuren met specifieke tijdsintervallen. Netscape Communicator (release 4.0) is uitgerust met netcast, een distributiemodel gebaseerd op Marimba-technologie. (De ontvanger van Marimba is te proberen op http://www.marimba.com. Experimenteren met het opzetten van een Castanet-zender kan via http://www.developer.ibm.com/welcome/ebusiness.html.)
Het asynchrone Castanet ophaalmodel ziet er veelbelovend uit als u denkt aan het ophalen van data. U kunt bijvoorbeeld om vier uur ’s nachts de nieuwste versie van het NRC ophalen om te lezen op de laptop in de trein naar het werk. Programmatuur is echter een ander verhaal. Upgrades van belangrijke bedrijfskritische applicaties om vier uur ’s nachts doen meer aan een nachtmerrie denken met incompatibiliteiten en fouten (zie ook de achtste zwakke plek).

Java-decompilatie

De zesde zwakke plek betreft de Java-decompilatie. ‘Write Once, Decompile and Steal Everywhere!’ Als Java-broncode wordt gecompileerd, blijven belangrijke delen van de originele structuur beschikbaar. Behalve de namen van de lokale variabelen in een method blijven de namen van klassen, velden en methods zichtbaar in de resulterende bytecode. Hoewel code als die voor Java for-loops geen equivalent heeft in de bytecode-instructies, kunnen slimme decompilers standaard flowpatronen herkennen en verrassend succesvol zijn in het terugvertalen van bytecode naar Java-broncode. De risico’s hiervan worden vaak weggewuifd omdat weinig softwaretechnologieën te kopiëren zijn, zelfs niet door het lezen van de broncode. Niettemin zijn Java-systemen kwetsbaarder, juist omdat ze actief het distribueren van applicaties ondersteunen.
Compilers en post-processors kunnen het decompilers moeilijk maken. Een eerste stap kan het verknoeien van alle namen in programma’s zijn, door het hernoemen van alle klassen, velden en methods in willekeurige namen. Als dat niet genoeg is, zijn eenvoudige bytecode-patronen te verwarren door opdrachten te verplaatsen of zelfs dummy opdrachten toe te voegen. Het online tijdschrift Javaworld van juni dit jaar bespreekt diverse commerciële hulpmiddelen die op effectieve wijze de intellectuele eigendommen van bedrijven beschermen (zie http://www.javaworld.com). Het gebruik van deze hulpmiddelen lost het probleem van decompilatie dan voldoende op.

Taal- en api-onderwerpen

De zevende zwakke plek ligt in de taal- en api-onderwerpen. De Java-taal bestaat uit een zorgvuldig uitgebalanceerde combinatie van verschillende moderne programmeertaal-paradigma’s. Java leent de beste zaken uit talen als C++, Objective C en Smalltalk, terwijl het tegelijkertijd de minder gebruikte en complexere elementen weglaat. Dat maakt de taal eenvoudig te leren voor ontwikkelaars die C++ of Smalltalk kennen. Eenvoudige structuren zorgen verder ook voor een korte leercurve voor Java-nieuwelingen.
Een tweede onderdeel van de Java-omgeving zijn de application programming interfaces, de api’s. Er zijn enkele problemen met de api’s die aangeven dat de Java-bibliotheken (libraries) ruwe kanten hebben waarvan ontwikkelaars op de hoogte moeten zijn, temeer omdat geen snelle oplossing te verwachten is.
Eén van de problemen met api’s is het instellen van een element. Java ondersteunt vectors en strings. Dit wil zeggen dat Java het invoegen of veranderen van een element in een reeks toestaat. De syntax voor de vector-method is setElementAt(Object,int). De stringversie luidt setCharAt(int,char). Het verschil is dat de index soms de eerste en soms de tweede parameter is. Dit is inconsistent en kan leiden tot verwarring en de noodzaak tot hercompilatie.
Het volgende api-probleem betreft groottebepaling. De drie meest gebruikte elementen in de Java-taal, vectors, strings en arrays, zijn erg vergelijkbaar. Elk vertegenwoordigen ze een reeks elementen, en toch heeft ieder zijn eigen voorkomen en sterke kanten. Omdat ze zo vergelijkbaar zijn, verwacht je dat hun api vergelijkbaar is. Alle drie kennen ze een mechanisme om de huidige hoeveelheid elementen te bepalen. Voor de vector luidt de syntax van de method int size(). De string-klasse gebruik ook een method, maar die wordt anders aangeroepen: int length(). De arrays tenslotte gebruiken geen method, maar een veld: int length. Deze ongelijkheid is feitelijk onnodig.
Een ander api-probleem, het schrijven van overdraagbare gui’s (grafische gebruikersinterface), komt bij de tiende zwakke plek aan de orde.

Synchronisatie

Verder vormt de afweging tussen genericiteit en prestatie een probleem. Alle generieke datastructuren, zoals vectors, hashtables en strings, zijn threadsafe in Java. Dit houdt in dat de ontwerpers van deze generieke klassen hebben besloten om potentiële problemen te voorkomen door alle toegangsmethoden gesynchroniseerd te maken. Daarom kunnen verschillende threads in een lopend Java-programma niet op hetzelfde moment dezelfde vector of string manipuleren. Helaas zijn de huidige implementaties van synchronisatie in virtuele machines nogal omslachtig, dus kostbaar. Een oplossing zou kunnen liggen in het gebruik van betere synchronisatiemechanismen. In 1998 zijn op dit gebied nieuwe inspanningen te verwachten. Een andere aanpak wordt getoond door de Java Generic Libraries (zie http://www.objectspace.com). Hier wordt de synchronisatiekeuze overgelaten aan de ontwikkelaar en niet afgedwongen door de implementatie van de datastructuren. Het is een riskanter model, maar waarschijnlijk wel een met een betere prestatie.
Tot slot is er het probleem van string-manipulatie. Java ondersteunt strings direct. Ze worden weergegeven door objecten, en zijn door te geven en te manipuleren als objecten. Om strings een vergelijkbare semantiek te geven als standaard types wanneer ze worden doorgegeven aan methods, zijn ze onveranderlijk gemaakt. Dit houdt in dat er geen methods zijn die de waarde van de string veranderen. Verder zijn de klassen gedefinieerd als final, zodat er geen subklasse te definiëren valt die de string weer veranderlijk zou kunnen maken. Daarom betekent het manipuleren van strings dat er meerdere Java-objecten gemaakt moet worden. Dat kan kostbaar zijn. Ook dit is weer een onderwerp in het Java-ontwerp waarbij is gekozen voor een simpel model dat de meeste problemen kan oplossen. Speciale gevallen met veelvuldig stringgebruik zullen moeten zoeken naar een optimalisatie van hun stringcode.

Webversie van de week

De achtste zwakke plek valt te typeren als de Webversie van de week. De nooit eerder vertoonde snelle acceptatie van Java in combinatie met de downloadbare upgrades op het Web geven aanleiding tot een andere zwakke plek in Java: versie-ongelijkheid. Gelukkig is de specificatie van de bytecodes van de virtuele machines betrouwbaar gebleken sinds de publieke introductie van Java. De bibliotheken en de Java-taalspecificatie zijn een ander verhaal, met belangrijke veranderingen tussen de Java 1.0- en Java 1.1-systemen.
Javasoft geeft in zijn officiële handleiding (How to write compatible software, JDK 1.0.2/1.1) toe dat, zelfs als alle aangeboden browsers 1.1 zouden ondersteunen, het toch nog een tijd zou duren voordat alle gebruikers naar die nieuwe browsers zouden overstappen (zie http://www.javasoft.com/products/jdk/1.1/compatible). Eén van de mogelijke oplossingen om JDK 1.1-applets te laten werken in een oudere JDK 1.0.2-omgeving is het gebruik van een afvanglaag om de code die 1.1-specifieke api’s gebruikt. Hoe je het ook wendt of keert, dit soort code is niet de makkelijkste om te schrijven en te onderhouden.
In het perfecte geval zouden alle gebruikers op hetzelfde moment een upgrade ondergaan. In de praktijk moeten we volstaan met het upgrade-beleid van Javasoft. Licentiehouders van de Java-technologie zijn verplicht de volledige Java-specificatie te implementeren binnen zes maanden na het verschijnen van een nieuwe versie. Dit betekent dat er in de overgangsfase leveranciers zijn met verschillende productieplanningen en met verschillende versies van Java. Verder zullen individuele gebruikers (of organisaties of afdelingen) niet overstappen naar de laatste versie of een upgrade overslaan. In ieder geval zal een ontwikkelaar van Java meerdere systeemversies van Java moeten ondersteunen. Dit is geen kwestie van de volwassenheid van het product, maar meer een weerspiegeling van software-ontwikkeling in een in hoge mate verbonden en in beweging zijnde wereld. Java bestaat nu eenmaal in het snelst veranderende softwarecircus en werken met Java betekent werken in een veranderende wereld.

Inconsistente implementaties

De negende zwakke plek zijn de inconsistente implementaties van Java. Gezamenlijke inspanningen van de Java-leveranciers hebben Java doen doordringen in alle hoeken en gaten van de computerindustrie. De combinatie van Java’s goed gevulde standaard bibliotheken, de overdraagbaarheid en de ondersteuning van Internet-programmering in de hedendaagse vluchtige computerwereld legt de inconsistente implementaties van Java bloot als zwakke plek van Java. Dubbelzinnig of inconsistent taalgebruik en bibliotheek-definitie zijn niet te vermijden in deze snelle omgeving. Op dit moment bijvoorbeeld hebben de browsers van Microsoft en Netscape subtiele verschillen in sommige delen van hun implementatie, eenvoudigweg door een andere interpretatie van de specificatie van de virtuele machine. Ontwikkelaars zullen moeten leren hoe ze afhankelijkheden van die verschillen kunnen vermijden.
De oplossing voor deze problemen is een internationale standaard en een daarbij behorende testomgeving (hieraan werkt Javasoft al). Voor de Java-standaard heeft Sun Microsystems toestemming gevraagd om het zogenaamde JCT 1-proces te gebruiken. Dat proces is ontworpen om bestaande technologieën te verheffen tot internationale standaarden. Op 5 juni 1997 stemde de Amerikaanse TAG (Technical Advisory Group) van het ISO/IEC JTC 1 (International Standards Organization/International Electrotechnical Commision Joint Technical Committee 1) over dat verzoek. De uitslag luidde: ‘No, with comments’. Eén van de toelichtingen somde het potentieel op: "Gestandaardiseerd Java kan een enorm scala aan mogelijkheden bieden aan een willekeurige organisatie die computers gebruikt." We zijn dus nog niet begonnen met Java-standaardisatie, maar iedereen wil het wel. In de tussentijd voorziet Javasoft in een initiële test-omgeving, de Java Compliance Kit. Die zou kunnen helpen het aantal implementatie-afhankelijkheden te verminderen.

Abstract Windows Toolkit

De tiende zwakke plek is de AWT, de Abstract Windows Toolkit. De bibliotheek met grafische ondersteuning die met Java wordt meegeleverd, de AWT, gebruikt een ‘peer’-benadering. Dit betekent dat Java-gui-elementen worden geïmplementeerd met lokale oplossingen. Een AWT-button wordt onder Windows bijvoorbeeld een Win32-button en onder Unix een Motif-button. Omdat deze ‘peers’ verschillend reageren op de afzonderlijke platformen, is het moeilijk een applicatie te schrijven die zich exact hetzelfde gedraagt op alle platformen. Verder ondersteunt AWT maar een beperkt aantal gui-elementen.
Deze problemen hebben sommige gebruikers van de Java Newsgroups ertoe doen besluiten AWT de bijnaam ‘Awful Windows Toolkit’ te geven. Daartegenover staat weliswaar het overduidelijke succes van AWT als eerste echte overdraagbare grafische toolkit, maar het is inderdaad een uitdaging om betrouwbare, professionele applicaties te schrijven met AWT. Een groot aantal ontwikkelaars neemt dan ook zijn toevlucht tot het schrijven van zijn eigen componenten, zoals tab-controls, buttons en schuifbalken.
Javasoft is begonnen deze beperkingen in AWT op te lossen met de Java Foundation Klassen (JFC). Een onderdeel is de ‘Swing-set’ van Sun, die uitgroeide tot een gezamenlijke inspanning van Netscape, Lighthouse Design en IBM. Deze bevat eenvoudige oplossingen en ingebouwde ‘look and feel’. In JFC worden elementen als knoppen nu geëmuleerd en volledig in Java opgenomen. Dit verzekert hetzelfde gedrag op alle platformen. JFC zal onderdeel uitmaken van JDK 1.2 (verwacht in de loop van komende winter). Omdat alle Java-licentiehouders hun producten binnen zes maanden moeten aanpassen, zal JFC in elke belangrijke browser beschikbaar zijn in de zomer van 1998.

Complexiteit

De elfde en laatste zwakke plek, de complexiteit, vormt het grootste probleem. Java is verstrikt in de ongelooflijk complexe Internetwereld met ontelbare dagelijks wijzigende technologieën (zie de ‘Java-expert checklist’). Om Java te laten functioneren in deze wereld en het geschikt te maken voor bedrijfsgebruik werden vele nieuwe api’s geïntroduceerd in JDK 1.1. Deze toegevoegde ‘Enterprise api’s’ maken Java krachtiger; het wordt bijna de softwareversie van het Zwitserse zakmes. Echter, dit grote aantal bibliotheken verlengt de leercurve dramatisch, terwijl Java eerst zo eenvoudig was. Het vereist aanzienlijke studie om alle api’s te leren en te begrijpen. Zelfs de JDK 1.1-versie van David Flanagans populaire Java in a nutshell past niet meer in één boek. De bedrijfsapi’s zullen in een afzonderlijke versie verschijnen en de bruikbare voorbeelden in het begin van het boek hebben ook het veld moeten ruimen.
Naar verwachting zal de lawine van api’s afnemen aan het eind van dit jaar met het vrijgeven van JDK 1.2. Daarna zullen updates van Java zich richten op het in orde maken van bekende fouten, het efficiënter maken van Java en het opnemen van meer en meer ‘native’ code in Java zelf, zoals gedaan wordt met JFC. Verder is er onnodige codereplicatie bij de implementatie van RMI, reflectie en het laden van klassen. Al deze zaken zullen onder handen worden genomen, zodat de gebruiker de kans krijgt zich de nieuwe mogelijkheden van de taal eigen te maken. Dat zal de Java-ontwikkelomgeving iets stabieler maken, maar niets kan de wereld veranderen waarin Java zich begeeft. De belofte en spanning van alomtegenwoordige automatisering draagt de prijs van het elke dag leren over nieuwe interessante systemen. De wereld is gecompliceerd: geniet ervan.
 
Chris Laffra, IBM T.J. Watson Research Center.
Na zijn promotie, vijf jaar geleden, werkte Chris Laffra bij IBM aan ontwikkeltools voor C++. Momenteel is hij verbonden aan het IBM T.J. Watson Research Center. Als lid van de Java Tools groep houdt hij zich bezig met zaken als Java-compilers, virtuele machines, debuggers en Java-visualisatiesystemen.
Tijdens een driejarig verblijf op Wall Street bij Morgan Stanley schreef hij het boek ‘Advanced Java, idioms, pitfalls, styles and programming tips’, Prentice Hall, 1996 (zie: http://members.aol.com/laffra). Dit boek zette als eerste kritische kanttekeningen bij de taal Java.
 
Dit artikel is tot stand gekomen dankzij de goede suggesties van John Barton, Lee Nackman en Jim Russel van het IBM T.J. Watson Research Center en de excellente ondersteuning van Han Tammer van Fortis Nederland. De Engelse versie van dit artikel verschijnt in het tijdschrift Application Development Trends, augustus 1997.
&nbsp