Het Java-platform staat steeds meer open voor andere talen, hoewel Java als taal zeker nog niet aan het eind van haar Latijn is.

Het Java-platform – het geheel van de virtual machine en onderdelen als api’s (application programming interface) voor het draaien van Java-toepassingen – zet mede onder druk van het ‘web 2.0’-gebeuren steeds meer zijn deuren open voor andere talen dan Java. Zo introduceerde de Java Standard Edition 6 een api voor de ondersteuning van ‘scripting’-talen, met in de nakende versie 7 een nieuwe bytecode (invokedynamic, JSR292) voor een uitgediepte ondersteuning van dynamische talen.. De lijst van talen omvat vandaag onder meer Groovy, Scala en ook JRuby.

Platform voor JRuby

JRuby is een in Java geschreven implementatie van Ruby, de taal die in 1993 door de Japanner Yukihiro Matsumoto werd ontwikkeld met het oog op een meer mensgerichte ict, zowel voor de gebruikers als de ontwikkelaars. Ruby werd een objectgerichte taal conform een ‘policy of least sur-prise’ (dat laatste betekent dat Ruby-code geschreven door een ervaren programmeur geen twijfel mag laten over de het resultaat ervan). Door een versie van Ruby in Java (in plaats van het oorspronkelijke C) te ontwikkelen moeten programmeurs dan genieten van de voordelen van beide werelden (inclusief het Ruby on Rails applicatieframework), in casu de voordelen van de Java Virtual Machine (JVM) en de elegantie van Ruby. Deze en andere voordelen, inclusief de mogelijkheid gebruik te maken van de multithreading en concurrency-faciliteiten in de JVM, werden op Devoxx 2008 met vuur verdedigd door de twee hoofdontwikkelaars van JRuby – Thomas Enebo en Charles Nutter, allebei in dienst van Sun Microsystems.

Met behulp van JRuby kunnen snel en efficiënt frontendtoepas-singen worden gecreëerd, met goede toegang tot de achterliggende businessobjecten en bedrijfsdata. Bezwaren over steeds nieuwe technologieën voor gelijke toepassingen wuiven Enebo en Nutter vlotjes weg. Technologie blijft steeds in verandering en voor nieuwe problemen als webtoepassingen moet je nu eenmaal nieuwe technologieën bieden, klinkt het. Bovendien helpt het niet om van bovenaf technologieën op te leggen, want dat resulteert toch alleen maar in ongelukkige ontwikkelaars en luizige toepassingen. De ontwikkelaars van JRuby verwijzen naar het opzet van Matsumoto om een omgeving te creëren waarin het “prettig” werken is, met haast “artistieke” aspecten, en dat gekoppeld aan de programmeertechnische voordelen van de JRuby. Iets minder geruststellend was dan ook de wijze waarop ze ‘security’ afdeden als het minst aantrekkelijke aspect van software, maar dat JRuby hoedanook een compacte en erg leesbare taal is en dus heel wat makkelijker te auditen dan bijvoorbeeld C. Bedrijven hoeven overigens niet te vrezen dat JRuby voor een fragmentatie van de populaire Ruby-wereld zal zorgen, want JRuby streeft naar een volledige complementariteit met de referentie-implementatie. Meer nog, er zou vandaag veeleer sprake zijn van een kruisbestuiving tussen de twee werelden. Bij Sun zelf wordt JRuby in ieder geval als proefkonijn aangewend bij het werk rond de ondersteuning van andere talen op het Java-platform.

Maar ook Java

De aandacht voor andere talen op het Java-platform betekent overigens niet dat Java zelf aan verstarring zou lijden. Zo werd op Devoxx 2008 uitgebreid ingegaan op de toen net aangekondigde productieversie van JavaFX, de nieuwe taal voor het bouwen van RIA-frontends. Danny Coward, Suns chief architect voor Client Software, benadrukt dat JavaFX tegen Silverlight, Flash/Flex en tutti quanti zijn mannetje zal staan omdat “JavaFX van bij de aanvang voor RIA’s werd ontwikkeld,” en er optimaal gebruik wordt gemaakt van het onderliggende Java-platform. Dat is nu op haast elk systeem aanwezig, klinkt het, van mobiele systemen en ‘blu-ray spelers’ tot pc’s. JavaFX moet nu zo snel mogelijk onder de aandacht van zoveel mogelijk gebruikers worden gebracht. De versie 2.0 moet normalerwijze op JavaOne van dit jaar het daglicht zien. “We komen echt niet te laat,” stelt Danny Coward nog, integendeel, “concurrentie is gezond en zal de ontwikkelingen versnellen en ons inspireren.”

Ook aan de volgende Enterprise Edition – Java EE 6 – wordt nu hard gewerkt, de ‘early draft review’ werd afgerond in november 2008. Op het lijstje staan onder meer Enterprise Java Beans 3.1, JavaServer Faces 2.0, de Java Persistence architecture en Servlet 3.0. Co-spec leader Roberto Chinnici benadrukt daarbij het behoud van terugwaartse compatibiliteit, ondanks mogelijke wijzigingen in bijvoorbeeld de afhandeling van servlets. “Java Enterprise Edition is een matuur platform, maar er zijn nog een aantal pijnpunten,” omschrijft Chinnici de nood aan veranderingen, “Er zijn nieuwe gebruiksnoden, bijvoorbeeld andere vormen van webrequests, die niet door Java EE 5 kunnen worden aangepakt.” Allicht nog het grootste punt van discussie is de relatie met de OSGi Alliance rond de ontwikkeling van een nieuw packaging model voor Java-toepassingen en componenten, maar “we hebben de vredespijp gerookt,” aldus Chinnici. Hij geeft daarbij aan dat de industrie de richting van de OSGi-aanpak uitgaat. Voor Mark Reinhold, principal engineer bij Sun voor de Standard edition en de OpenJDK, staan een aantal punten in ieder geval al vast. “Java vreet resources,” geeft hij toe en modularisering van de Java Development Kit 7 staat zeker op het ‘to do’-lijstje. Algemeen wordt ook gestreefd naar een kleinere ‘footprint’, met bijvoorbeeld in de meest recente update van de standaard editie (SE 6 Update 10) al de voorziening voor een Java-kernelsysteem. Dat laat toe slechts de nodige delen van de Java Runtime Environment in te laden, waardoor toepassingen ook sneller starten. Ook de verspreiding van Java-toepassingen en -componenten wordt onder handen genomen, waarbij het eigen initiatief van Sun (de JSR 277 inzake het Java Module System) even de koelkast in gaat ten gunste van het werk in de JSR 294 (rond ‘verbeterde modulariteitsondersteuning’). Sun zal recht-streeks samenwerken met de OSGi Alliance (rond packaging), terwijl met de OpenJDK gemeenschap het project ‘Jigsaw’ wordt opgezet (voor een low level modulariseringssysteem, dat evenwel geen deel zal uitmaken van de Java SE 7 Platform Specification).

Geen closures in Java SE 7

En voorts garandeert Reinhold dat er inderdaad nog meer talen zullen worden ondersteund op de JVM, zij het dat je daar niet meteen C op moet verwachten. Inzake ‘closures’ is hij even duidelijk: niet in Java SE 7. “Over een aantal aspecten is er nog een gebrek aan consensus en het zou dan ook verkeerd zijn dat nu al in te voeren. Het zou gewoon de helft van de gemeenschap op stang jagen.” Is hij uiteindelijk tevreden met de hele gang van zaken? Er is vooruitgang geboekt, maar niet zoveel als “meeste mensen hadden gewild. Zeker niet wat ik had gewild,” klinkt het droog. Een preview van Java SE 7 op JavaOne van dit jaar zal “veel tonen, maar niet alle key features’.”

Guy Kindermans