Pour créer des instances de classes dont on ne connait que le nom, rien de plus facile : il suffit de récupérer l'instance de Class<?> puis d'appeler newInstance() dessus, et puis de traiter les nombreuses exceptions susceptibles d'être levées.

C'est ce que fait la méthode statique newInstance ci-dessous :

public class TestNewInstance {
    public static void main(String[] args) {
        final Object o = newInstance(args[0]);
        System.out.println(String.valueOf(o));
    }
 
    private static Object newInstance(String className) {
        try {
            Class<?> clazz = Class.forName(className);
 
            return clazz.newInstance();
        } catch (ClassNotFoundException e) {
            System.out.println("-- Class Not Found --");
        } catch (IllegalAccessException e) {
            System.out.println("-- Illegal Access --");
        } catch (InstantiationException e) {
            System.out.println("-- Cannot Instantiate --");
        }
        return null;
    }
}

Bien sûr, la classe en question doit posséder un constructeur sans argument ; si ce n'est pas le cas, InstantiationException sera levée.

Cependant, malgré toutes ces précautions, ce code pose un gros problème de robustesse, qui ne se révèle que pour quelques classes bien particulières. Pourquoi ? Comment l'éliminer ?

Depuis une classe tierce, comment afficher la valeur du champ "message" de la classe ci-dessous ?
Il est naturellement interdit de court-circuiter les règles de visibilité des champs de la classe.

package net.thecodersbreakfast.quiz35
public class OuterClass {
 
	private String message = "Hello World";
 
	private class InnerClass {
		private String getMessage() {
			return message;
		}
	}
}

Google...
Tout le monde connaît Google, son moteur de recherche, ses outils de communication (GMail, Wave, Buzz), ses outils bureautiques (Docs, Maps, Picasa, Postini) et de développement (GWT, App Engine, et sa contribution exceptionnelle à Java), et ses périphériques d'accès à Internet (Android, Chrome, Chrome OS). Sans oublier le nerf de la guerre, sa régie publicitaire Adsense, qui justifie l'existence de tous les produits précités.

En mettant un pied dans chaque industrie liée de près ou de loin à l'obtention, au classement et à la restitution des données, Google approche de son objectif d' "organiser l'immense volume d'information disponible sur le Web et dans le monde".

Le BIRT User Group vient de se créer.
Comme son nom l'indique, il vise à fédérer une communauté autour de cet outil de reporting opensource.
Vous trouverez le communiqué de presse ci-dessous.

Vous vous demandez peut-être pourquoi je vous signale cet événement, alors que je ne vous ai jamais parlé de reporting auparavant.
Hé bien, tout simplement parce que j'ai participé à la réalisation de son logo !

Hé oui, votre Coder préféré a aussi une âme d'artiste à ses heures...
D'ailleurs, saviez-vous que j'avais également conçu le logo du Spring User Group France, ainsi que le design des blogs Zenika, YesWicket, et The Coder's Breakfast (v1 et v2) ?

JESS3 / The State of The Internet from JESS3 on Vimeo.

Vous pouvez maintenant éteindre votre ordinateur et reprendre une activité normale.

Edit : apparemment, le 10 milliardième twitt vient d'être atteint. On n'arrête pas le progrès !

Dans la droite lignée des Barcamps, le premier KawaCamp s'organise le 23 mars au Quigley's Point.

Mais concrètement, un KawaCamp, c'est quoi ?
C'est tout simplement un regroupement spontané et informel de développeurs Java, qui ont envie de discuter et de partager leurs dernières trouvailles. Contrairement à un JUG, il n'y a pas vraiment d'ordre du jour, pas de speaker, et pas de sponsors. Bref, les développeurs parlent aux développeurs.

Si vous voulez y participer, il suffit de vous inscrire en éditant la page du wiki. On vous attend tous le 23 mars !

Le Paris JUG se réunit de nouveau le mardi 9 mars à l'ISEP pour donner la parole à Emmanuel Bernard.
De 19h30 à 20h25 puis de 21h05 à 22h00, l'un dse principaux contributeurs d'Hibernate donnera les dernières nouvelles du célèbre framework de persistance, et présentera les différents algorithmes de recherche disponibles dans Hibernate Search.

Ceux qui ne pourront y assister en personne pourront toujours suivre la Wave en temps réel sur ce billet, ou depuis leur compte Wave à cette adresse : Wave Paris JUG "Emmanuel Bernard".
Elle sera retranscrite par la suite au format texte, pour ceux de mes lecteurs qui n'auraient pas de compte Wave.

Je viens de découvrir une fonctionnalité méconnue d'Eclipse : les catégories.
Grâce à l'annotation javadoc @category, il est possible de définir des groupes virtuels de méthodes et de propriétés au sein des classes Java. Il est ensuite possible de les filtrer dans les vues Outline et Members, afin de n'afficher que ce qui vous intéresse.

Cette astuce peut être très pratique lorsque vous naviguez dans une classe imposante, et que vous cherchez à en comprendre la structure.
Pour peu que le code soit mal organisé, il se peut très bien que des méthodes métiers soient perdues au milieu des accesseurs, et que vous passiez à côté par inadvertance.

Une classe injustement méconnue du JDK est Scanner (java.util.Scanner).
Elle offre pourtant des fonctionnalités très intéressantes pour parser des chaînes de caractères, et en extraire et convertir les composants.

Un Scanner peut se brancher sur à peu près n'importe quelle source : InputStream, Readable (et donc Reader), File... et bien sûr une simple String. Ensuite, deux options s'offrent à vous : utiliser les méthodes de type hasNext...() / next...(), ou alors les méthodes de type find...() / match() / group().

Dans ce billet, nous verrons comment utiliser ces deux jeux d'instructions.

Vous savez qu'au sein de la JVM, une classe est identifiée de manière unique par son nom complet et son classloader.

Cette règle est facile à implémenter sous la forme d'une méthode utilitaire :

public class ClassUtils {
	public static boolean isSameClass(Class<?> class1, Class<?> class2) {
		if ((class1 == null) || (class2 == null)) { return false; }
		return (
			class1.getClassLoader().equals(class2.getClassLoader()) && 
			class1.getName().equals(class2.getName()) );
	}
}

Il ne reste plus qu'à vérifier :

System.out.println( ClassUtils.isSameClass(ClassUtils.class, ClassUtils.class) ); // true
System.out.println( ClassUtils.isSameClass(String.class, ClassUtils.class) ); // false

A moins que... ?