Vous aimez ce que vous lisez sur ce blog ?
Envie d'aller plus loin avec véritable formation d'expertise en Java ?
Venez suivre ma formation Masterclasse Expertise Java !

"Même un développeur experimenté a besoin de continuer à apprendre. Et dans cette formation... j'ai appris beaucoup !" - A.G., Java Champion

Prochaines sessions inter-entreprises : 28-31 mars 2017 / 13-16 juin 2017
Sessions intra-entreprises sur demande.
Inscrivez-vous vite !

Spring 3.0 M2 disponible

Jürgen Höller vient d'annoncer la disponibilité de Spring 3.0 M2 !

Pour faire court :

  • La réécriture du framework pour tirer parti de la JLS 3 se poursuit : génériques, varargs, etc.,
  • Le module de mapping Objet/XML a été déplacé de Spring Webservices vers Spring Core, car il s'agit d'une problématique transverse, applicable à plusieurs modules comme Spring MVC (qui s'enrichit au passage d'une MarshallingView) et Spring Remoting (JMS).
  • Spring Scheduling est en cours de réécriture pour prendre en charge les API java.util.concurrent. L'effort se poursuivra sur la M3 avec l'ajout d'un namespace dédié.
  • Spring MVC gère désormais les Portlets 2.0 (JSR 286)
  • Spring ORM commence à intégrer JPA 2.0

Il est intéressant de constater que, malgré les commentaires négatifs exprimés (cf. ci-dessous) par SpringSource à l'occasion du vote final de la spécification Java EE 6, Spring 3.0 M2 a tout de même choisi d'en implémenter certaines JSR.

On 2009-02-23 SpringSource voted Abstain with the following comment:

The introduction of profiles is a step in the right direction. However, we are disappointed not to see a minimal web profile, especially as this has become the choice of most enterprise Java users.

As with previous releases, the inclusion of unproven technology is a risk, especially in JSR 299 NDLR : la spécification WebBeans and EJB concurrency annotations. The number of substantial changes late in the process also gives us concern about the maturity of the result--especially, the impact of the scope creep of JSR 299 on other specifications.

Experience has shown that tying dependency injection features to a server environment does not match user requirements, as injection is common to all application types. We would have preferred to see a dependency injection model for SE, as we proposed in 2007.

Finally, we are not convinced that the end result matches the goals of Java EE 6 as defined in the original specification request, which we strongly supported.

(Sachant que la Fondation Apache a voté contre, et la Fondation Eclipse s'est abstenue... Java EE 6 part sur de bien mauvaises bases...)

Spring 3.0 n'est pas encore documenté, mais les Javadocs sont disponibles. Essayez-le !


Commentaires

1. Le lundi 2 mars 2009, 11:16 par Antonio Goncalves

Java EE 6 ne part sur de mauvaises bases. La fondation Apache vote systématiquement non à chaque JSR à cause du célèbrissime problème du Field of Use (cf lettre ouverte à Sun : http://www.apache.org/jcp/sunopenle... et la FAQ associé http://www.apache.org/jcp/sunopenle...). Ce n'est donc pas spécifique à Java EE 6.

Quant à l'abstention de SpringSource, c'est surtout à cause du refus de l'expert groupe d'intégrer un profile minimal. Java EE 6 sera livrée avec un profile Web intégrant les EJB 3.1 lite, JPA 2, JSF 2... bref, toute une batterie de spécifications que Spring n'implémente pas. Le profile minimal initialement proposé aurait du être constitué de Servlet et de JSP, c'est tout. Histoire de pouvoir spécifier Tomcat en somme.

Moi je trouve que Java EE 6 part sur de très bonnes bases avec un modèle clairement simplifié (qui fera peut-être de l'ombre à Spring) et de nouvelles spec comme JAX-RS (que Spring n'implémente pas, ce qui est très discutable)

2. Le lundi 2 mars 2009, 14:10 par Olivier Croisier

C'est vrai que la Fondation Apache mène toujours cette bataille contre Sun. D'ailleurs, je ne vois pas ce qui pousse Sun à ne pas diffuser ses tests de compatibilité ? Plus il y a d'implémentations certifiées compatibles d'une norme, et plus cette norme sera diffusée.

Par contre je suis assez d'accord avec SpringSource quand ils disent que JavaEE 6 est un gros mashup de technos parfois contradictoires et pas forcément mûres. Je pense qu'il aurait mieux valu rationaliser un bon coup la plateforme Java EE avant de songer à y intégrer d'autres briques, dont certaines sont très controversées et/ou encore instables

Par exemple, j'aurais aimé que JavaEE 6 propose :
- un modèle unique d'IOC, défini comme une norme (et utilisable en Java SE), plutôt que de se coltiner ceux des EJB, de WebBeans, etc. Pourquoi ne pas se rapprocher de Spring qui a déjà un modèle qui fonctionne bien ? (ou de Guice...)
- un langage de parcours de graphe unique : actuellement il y a JSP EL, JSF EL, etc. Pourquoi ne pas utiliser, par exemple, MVEL dont les performances sont reconnues ? Ou Groovy...

Quant au "modèle de développement clairement simplifié", je suis mitigé.
- Du côté des EJB, j'admets qu'il y a eu un progrès spéctaculaire niveau facilité d'utilisation... mais le système est toujours le même derrière, avec ses limitations.
- Du côté de la programmation web orientée requêtes, plutôt que de proposer des "améliorations" ridicules (par exemple l'auto-détection des filtres), il aurait été plus utile de supprimer définitivement jsp:usebean, de remplacer les Enumerations et les tableaux par des Collections dans les APIs (ex: request.getCookies), de fournir davantage de méthodes utilitaires (ex: request.getIntParameter), de proposer un système de templating intégré (ex: normaliser et intégrer Sitemesh)... Bref, d'éliminer tous ces points énervants qui parsèment la spec.
- Quant à la programmation web par composants... Il suffit de comparer JSF et Wicket (ou Tapestry)...

Bref, on verra comment le marché évolue, mais personnellement les nouvelles fonctionnalités de Java EE 6 me mettent nettement moins l'eau à la bouche que celles de Spring 3.0 par exemple.
Mais YMMV...

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.