Je vous ai déjà présenté le Service Provider API de Java 6+, qui permet de découvrir dynamiquement au runtime les implémentations disponibles d'une interface donnée.

Nous avions également vu qu'il était possible de parvenir à un résultat similaire dans un environnement Spring, grâce à l'import dynamique de ses fichiers de configuration et à un BeanPostProcessor. Toutefois, cela demandait davantage de travail et ne permettait de découvrir que sur des classes expressément déclarées comme beans Spring.

Dans cet article, nous verrons comment interfacer ces deux technologies, de manière à pouvoir injecter dans un contexte Spring des implémentations non-Spring détectés par le Service Provider API.

Les architectures modernes sont typiquement découpées en couches représentant des services concentriques de plus en plus haut niveau :

• Accès aux données (couche de persistance ou DAO, l'objet de ce billet),
• Traitements métiers,
• Présentation à l'utilisateur ou exposition à des systèmes tiers.

Les bonnes pratiques imposent que chacune de ces couches soit représentée par une interface exprimant le service qu'elle rend et masquant la façon dont elle est implémentée. Leur respect permet d'obtenir des architectures modulaires et faiblement couplées, facilitant le test et la maintenance des applications.

Pourtant, les ORMs remettent en cause ce schéma.

Soit un système de gestion dynamique de blogs. Chacun est représenté par une classe qui s'occupe d'assembler ses différentes parties (Header, Content, Footer) placées dans un sous-package propre. Une factory permet d'obtenir dynamiquement le contenu d'un site en fonction de son nom.
Pourquoi ce système ne fonctionne-t-il pas ?

net.thecodersbreakfast.quiz29
+-- sites
    +-- TheCodersBreakfast
    |   +-- Content.java, Footer.java, Header.java
    +-- LeTouilleurExpress
    |   +-- Content.java, Footer.java, Header.java
    +-- TheCodersBreakfast.java
    +-- LeTouilleurExpress.java
    +-- SiteFactory.java

As a Java architect, your role is to define rules and best-practices, based on well-known patterns and personal experience.
Being a conscientious professional, you take time to painstakingly write them down in some specification document or on the local Wiki, complete with code samples and colorful UML diagrams - only to find out that most of your developers never remember (or even bother) to read your literature and apply your rules.
So at one point, you realize that what you really need is an automated mean to enforce your design rules at development time.

In this article, I will present a technique to apply package-level restrictions with annotations and a custom annotation processor.

Un petit quiz facile pour se rafraîchir en cette semaine bien chaude !
Alors, que fait ce code ?

public class Summer {
	public static void main(String[] args) {
		List<String> list = new ArrayList<String>(10);
		Collections.fill(list, "très ");
		list.set(0, "Il fait "); 
		list.set(9, "chaud !");
		System.out.println(list);
	}
}