Twee van de sessies die ik gisteren bijwoonde op JavaOne hadden te maken met de ontwikkelingen van de programmeertaal Java. Echt spannende dingen heb ik nog niet gezien, het closures onderwerp wordt stug vermeden. Het is opvallend hoe vaak de panels laten weten dat grote veranderingen vrijwel onmogelijk zijn in een taal als Java. Alle belangrijke veranderingen lijken te komen in de vorm van annotaties (JSR-308).

De volgende features zullen waarschijnlijk deel gaan uitmaken van Java 7:

Switch op string

Het team wil het switchen op strings graag mogelijk maken; het had eigenlijk altijd al zo moeten zijn:

switch("asdf"){
    case "asdf": foo(); break;
    case "qwer": bar(); break;
}

Multi Catch

Hiermee wordt het mogelijk per catch block meerdere excepties af te handelen:

try{ ... }
catch(X1, X2 e){ foo(); }
catch(X3     e){ bar(); }

Safe rethrow

Het is momenteel niet mogelijke om het volgende te doen zonder aan te geven date de methode waar deze code in staat Throwable kan gooien:

try {
    doable.doIt();  // Specified to throw several different exceptions
} catch (Throwable ex) {
    logger.log(ex);
    throw ex;  // Won't compile unless method is specified to throw Throwable!
}

Het voorstel is om het final keyword te gebruiken om ervoor te zorgen dat allen checked exceptions uit het try block hoeven worden te gedefinieerd:

try {
    doable.doIt();
} catch (final Throwable ex) {
    logger.log(ex);
    throw ex;
}

Modules

Met het modules voorstel wil men de tekortkomingen van packages aanpakken. Het gaat dan vooral om het ontbreken van hierarchische verwantschappen; classes in een subpackage hebben geen verwantschap met packages in de parent package. Om dit te verwezelijken wil men het module keyword toevoegen. Dit zal zowel gebruikt gaan worden voor het aangeven van de module waar een bepaalde class onderdeel van uitmaakt en als access modifier.

module org.netbeans.core;
package org.netbeans.core;
public class Debugger{
    ... = new ErrorTracker();
}
 
module org.netbeans.core;
package org.netbeans.core.utils;
module class ErrorTracker{
    module int getErrorLine(){ ...}
}

De ‘ErrorTracker’ class is in dit geval alleen zichtbaar binnen de module waar deze zelf onderdeel van is.

Verder zal het waarschijnlijk mogelijk worden om dependencies op bepaalde versies van een module op te nemen in client code:

@Version("7.0")
@ImportModule(name="java.se.core", version=1.7)

Op zich interessant, maar nu OSGi een steeds groter draagvlak krijgt misschien wat laat.

JSR-308: Annotations on generics and arrays

JSR-308 lijkt het stokpaardje van het taal-team. Annotaties lijken een onontgonnen gebied waar alles nog mogelijk is. Door het uitbreiden van het aantal locaties waar annotaties mogen staan. Persoonlijk bekroop mij toen ik dit hoorde een angstig gevoel; de hoeveelheid annotaties die ik in de afgelopen jaren mijn code heb zien binnensluipen groeit explosief en maakt het niet altijd mooier.

Een belangrijke feature die men hiermee wil gaan implementeren is een soort type checking systeem:

List<@NonNull String> strings = ...
 
class UnmodifiableList<T> implements @Readonly List<@Readonly T>{
    ...
}

Arrays gaan op een soortgelijke manier werken.

Alhoewel ik begrijp waar de wens vandaan komt zit ik hier toch niet echt op te wachten. Mijn vraag aan het panel “maar gaat dit niet ten koste van de leesbaarheid” werd afgedaan met opmerkingen als: “Dit soort dingen zie je alleen als API designer”, “per 100 regels code heb je misschien 1 of 2 annotaties”. De praktijk als JEE developer wijst echter heel anders uit.

Opmerkingen en vragen

Het publiek stelde opmerkelijk goede vragen:

• Waarom dit maar geen ‘const’ of ‘unsigned’ keyword?
• Word het niet eens tijd om te breken met het verleden?
• Integratie met scriptingtalen wordt alleen maar lastiger door het toevoegen van annotaties (talen zoals JRuby hebben deze niet). Dit staat integratie van de verschillende talen in de weg; wordt dit overwogen?
• Waarom hebben we het niet over closures?

De antwoorden op deze vragen brachten weinig voldoening; het panel deed ze af als te moeilijk of niet nuttig. Jammer!

En nu?

Vandaag is er een sessie over closures, in dit geval door Neal Gafter (iemand die ik hoog heb zitten als spreker). Ik ben benieuwd of dat de ontwikkelingen van de taal in een beter daglicht kan stellen; anders kunnen we het wat mij betreft misschien beter laten zoals het is!