Un des gros avantage de Groovy avec Java c’est que l’on peut quasiment reprendre la totalité d’un projet Java sans y toucher et qu’il soit compatible avec Groovy. Quasiment… c’est bien ce qui nous empêche de reprendre d’un simple copier-coller le Threadlocal sans générer une erreur de compilation.

Prenons un exemple d’utilisation en Java…

private static ThreadLocal<String> remoteUser = new ThreadLocal<String>() {
    protected synchronized String initialValue() {
        "inconnu";
    };
};

private static setRemoteUser(String p_user) {
    remoteUser.set(p_user);
}

public static String getRemoteUser() {
    return remoteUser.get();
}

Vous pouvez reprendre cette portion de code et l’intégrer dans une classe Groovy (avec les bons imports) vous constaterez immédiatement que le compilateur n’apprécie pas vraiment cette façon de faire… Voici maintenant l’équivalent en Groovy de cette portion de code :

private static ThreadLocal<String> remoteUser = [
    initialValue: { return UNKNOWN_USER }
] as ThreadLocal<String>;

private static void setRemoteUser(String user) {
    remoteUser.set(user)
}

public static String getRemoteUser() {
    remoteUser.get()
}

La différence de syntaxe est assez flagrante, mais il y également un point très important auquel il faut faire attention, c’est le point virgule sur cette ligne : as ThreadLocal<String>;. Si celui ci est supprimé, le parseur semble avoir quelques difficultées et ne distinguera pas la fin de l’instruction. Contrairement aux habitudes il faudra donc conserver cet élément dans ce cas bien précis.