Spring 3.0 – le grand nettoyage du printemps

Un an après la sortie de la version 2.5, le premier milestone de Spring 3.0 devrait bientôt voir le jour. La release officielle est planifiée pour le premier trimestre 2009. Nous lançons donc une nouvelle série d’articles dédiés à Spring 3.0. Dans ce premier article, nous vous présentons quelques détails des restructurations annoncées par Jürgen Höller (développeur le plus actif depuis la création de Spring, co-fondateur d’interface 21) lors de différentes conférences.

L’actualité battant son plein, vous aurez certainement noté la nouvelle mise à jour de la politique de maintenance effectuée par SpringSource hier soir incitant la communauté open-source à migrer vers les nouvelles versions de son framework. Ainsi, à publication de Spring 3.0 RC1, plus aucun tag ne sera effectué sur la branche 2.5.x.

Restructuration de Spring Core

Exit le JDK 1.4

La première des nouveautés n’est pas fonctionnelle, mais purement technique. Spring a décidé de laisser tomber une fois pour toutes le JDK 1.4. La refonte de Spring Core dépendra donc dorénavant des fonctionnalités du JDK 5.

Cette décision va certainement en choquer certains, mais il ne faut pas oublier que le JDK 5 est sorti il y plus de 3 ans et qu’il est supporté par tous les serveurs d’applications du marché depuis bien longtemps. De plus, cette refonte coïncide avec l’annonce de Sun du passage du JDK 1.4 en End Of Service Life (EOSL) à la fin du mois.

En fait, rien de vraiment étonnant : Spring prépare le terrain depuis sa version 2.5, dont les principales nouveautés s’appuyaient sur les notions introduites par le JDK 5. Certains modules dépendaient déjà de celui-ci. Cette généralisation à Spring Core en est la suite logique. Quitte à faire une cure de jouvence, autant profiter des avancées techniques.

Nettoyage de printemps

Spring profite de cette refonte pour se débarrasser de tout ce qui était précédemment déclaré deprecated. Ce choix n’est pas facile pour tout le monde : n’oublions pas que Sun traîne dans son JDK certaines méthodes deprecated depuis plusieurs années qui ne sont pas prêtes d’être retirées. Rod Johnson a d’ailleurs lancé des appels dans ce sens pour nettoyer JavaSE et JavaEE.

La liste complète des interfaces, classes et méthodes deprecated est disponible sur la Javadoc de Spring 2.5, où les destinées de ces différents éléments sont renseignées. Seront par exemple supprimées dans Spring 3.0 :

• AbstractPathMapHandlerMapping, CommonsPathMapHandlerMapping, PathMap, remplacées par les annotations permettant de mapper les requests.
• ServerSessionMessageListenerContainer, SimpleServerSessionFactory, au profit des beans DefaultMessageListenerContainer et JmsMessageEndpointManager.
• …

D’autre part, ce coup de balai terminé, Spring profite également de cette refonte pour déprécier certains cas d’utilisation et technologies quelque peu archaïques.

Seront probablement rendus deprecated :

• L’intégration avec la hiérarchie de classe de JUnit 3.8
• La hiérarchie de classe des contrôleurs de Spring MVC, remplacée par les annotations @Controller
• Et probablement certaines classes liées à HibernateTemplate et JPATemplate

En plus de cela, un certain nombre de fonctionnalités seront extraites de Spring Core et placées dans des modules legacy.

Ces modules seront disponibles, au besoin, séparément :

• L’intégration avec l’API Apache Commons Attributes qui n’a plus beaucoup de sens dans un environnement Java 5.
• Les APIs spécifiques TopLink

Pour conclure sur cette première partie, par ce grand ménage, Spring compte donner un coup de jeune au cœur de son framework. Aussi nombreux et importants que soient ces changements, si tout se passe comme prévu, les utilisateurs ne se rendront probablement pas compte de cette restructuration. Spring nous annonce, comparé à Spring 2.5, un modèle de programmation identique et une rétrocompatibilité quasiment complète.

Ajout de fonctionnalités

Pour finir, voici quelques-unes des nouvelles fonctionnalités attendues pour Spring 3.0 :

• Spring EL à tous les niveaux : il vous sera possible d’utiliser les Expression Language dans n’importe quel module de Spring. Cela vous permettra par exemple de définir des propriétés dont les valeurs seront fixées au runtime lors de la création du bean. Les EL seront aussi bien utilisables à partir des fichiers de configuration que par les différentes annotations @Value(#{anotherBean.anotherProperty})
• Support de REST via Spring MVC : cette fonctionnalité devrait être disponible dès le premier milestone de Spring 3.0. Elle sera également accompagnée de nouveau type de vues JSON, XML ou ATOM, nous rappelant ce que font certains frameworks concurrents (dont Grails). Comme nous l’avons annoncé dans une récente revue de presse, nous espérons que Spring 3.0 supporte l’intégralité de la JSR-311 : Java API for RESTful Web Service nouvellement terminée.
• Support des Portlets 2.0 : les premiers tests et développements ont apparemment commencé en utilisant le conteneur Pluto. Le support de cette JSR-286 : Portlet Specification 2.0 permet d’espérer l’apparition de fonctionnalités très attendues dans le monde des portlets, telles que la demande de ressources et communication inter portlets via événements
• Validation du modèle via annotations : depuis Spring 2.5 l’ancien modèle de validation parait un peu dépassé. Pour sa version 3.0, Spring nous propose de revoir tout cela avec l’arrivée de nouvelles annotations. On peut espérer une compatibilité avec la JSR-303, sujet fortement influencé par JBoss. Une intégration forte avec Spring MVC et Spring JS est également attendue.
• Un nouveau scope : la conversation. Présent dans Spring WebFlow, ce nouveau scope sera rendu disponible dans Spring Core.Il se basera sur une API spécifique pour ouvrir et terminer programmatiquement les conversations. Une conversation peut se comparer à une sous-session spécifique à un process. Avec ce nouveau scope, l’utilisateur pourra associer des objets dont la durée de vie dépendra d’un ensemble défini d’actions. Lorsque ce processus se terminera, les objets liés à celui-ci seront supprimés.

Les développements n’étant pas encore terminés et les sources n’étant pas disponibles, cette liste n’est ni exhaustive, ni définitive … ni officielle. Nous ne manquerons pas de publier des articles complémentaires sur ces différents sujets lorsque nous en saurons plus.