Spring 3.0 vs Java EE 6.0

Question

Je suis confronté à une situation...

On m'a demandé de donner un avis sur l'approche à adopter, en termes de développement Java EE, entre Spring 3.0 et Java EE 6.0. J'étais, et je suis toujours, un promoteur de Spring 2. 5 par rapport au développement classique de Java EE 5, en particulier avec JBoss, j'ai même migré d'anciennes applications vers Spring et j'ai influencé la redéfinition de la politique de développement ici pour inclure des API spécifiques à Spring, et j'ai aidé au développement d'un plan stratégique pour favoriser des solutions plus légères comme Spring + Tomcat, au lieu des solutions plus lourdes de JBoss, actuellement, nous utilisons JBoss simplement comme un conteneur Web, ayant ce que j'appelle le "paradoxe du conteneur à l'intérieur du conteneur", c'est-à-dire ayant des applications Spring, avec la plupart de ses API, fonctionnant à l'intérieur de JBoss, Nous sommes donc en train de migrer vers Tomcat.

Cependant, avec l'arrivée de Java EE 6.0, de nombreuses caractéristiques qui rendaient Spring attrayant à l'époque (déploiement facile, couplage réduit, même une sorte de D.I., etc.) semblent avoir été imitées, d'une manière ou d'une autre. JSF 2.0, JPA 2.0, WebBeans, WebProfiles, etc.

Donc, la question est...

De votre point de vue, dans quelle mesure est-il sûr, et logique, de continuer à investir dans un cadre de développement Java EE non standard comme Spring, compte tenu des nouvelles perspectives offertes par Java EE 6.0 ?

Pouvons-nous parler de 3 ou 4 années supplémentaires de développement de Spring, ou recommandez-vous une adoption rapide des API de Java EE 6.0 et de ses pratiques ?

J'apprécierai tout commentaire à ce sujet.

Answer 1

Le point crucial, à mon avis, n'est pas celui des caractéristiques. À cet égard, Spring aura toujours une longueur d'avance sur JavaEE, car il est naturel qu'il s'agisse d'un logiciel libre ou d'un standard. Le fait est que vous obtenez les nouvelles fonctionnalités beaucoup plus tôt avec Spring qu'avec JavaEE (par exemple, les tests d'intégration des conteneurs sont une nouvelle fonctionnalité dans JavaEE 6 et sont disponibles dans Spring depuis longtemps).

Le point le plus important, à mon avis, est celui des cycles de vie pour l'administration et le développement. Lorsque vous choisissez JavaEE, vous liez votre modèle de programmation à votre infrastructure. En général, les fournisseurs de serveurs d'applications ne sont pas les plus rapides à adopter les nouvelles versions de la norme (c'est la faute de WebSphere, JBoss, etc.). Cela signifie donc que nous ne verrons probablement pas de produits JavaEE 6 prêts pour la production et supportés par les grands fournisseurs avant la fin de l'année.

Même si c'est le cas, vous devez encore franchir l'obstacle de votre administration, de votre département informatique et des responsables du contrôle budgétaire pour accepter de passer à cette nouvelle version brillante. De ce point de vue, JavaEE 6 n'est même pas une option pour de nombreux magasins. Vous pouvez choisir ce que vous voulez pour déployer vos applications ? Vous voulez choisir Glassfish pour la production ? Allez-y, essayez. La plupart des entreprises ne sont pas dans une situation aussi "confortable".

Exactement le contraire : Le printemps. Modèle de programmation découplé de l'infrastructure. Prenez la version actuelle 3.0.x et utilisez @Inject JPA 2 et autres dans votre serveur d'applications Tomcat ou patrimoniales.

Answer 2

Si vous êtes déjà un magasin Spring, pourquoi changer ? Vous en êtes satisfait, il fait ce que vous voulez, il est activement développé, vous ne cherchez probablement pas à fonctionner en dehors de Tomcat dans un avenir proche, voire jamais, puisque Tomcat est très mature et fonctionne partout. Ainsi, toute promesse de portabilité que Java EE pourrait suggérer s'envole.

Je ne vois aucune raison d'abandonner le printemps.

Answer 3

Puisque Will et Oliver ont déjà dit les choses les plus importantes, j'ajouterai seulement ceci : "si ça marche et que le travail est fait, alors laissez-le tranquille !". "Plus récent" et "standardisé" n'est pas toujours synonyme de "meilleur", en fait c'est rarement le cas - les nouvelles choses sont maladroites et boguées et (c'est le plus important pour moi) ne sont pas largement supportées. Si le reste de Java EE 6 est aussi "standardisé" que JSF2.0 (et toutes les Rich/Ice/Prime/WhateverFaces), alors croyez-moi, restez-en à Spring pour le moment. Beaucoup d'entreprises s'en tiennent à des technologies un peu plus anciennes pour une raison (stabilité > *), Spring est sur le marché depuis des années et est bien établi.

@Edit : Surtout pour @ymajoros : JSF (à la fois 1.x et 2.x) est un standard défectueux pour de multiples raisons et n'est utile que dans une poignée de cas (c'est-à-dire lorsque vous créez de petits sites web CRUD simples ou lorsque vous êtes un enthousiaste de Java EE) :

• La création de nouveaux composants est une véritable corvée. Puisque c'est un composant je suppose que cela rendrait les choses plus facile pas plus difficile. Actuellement, je préfère utiliser JS+Java en backend. puisqu'il est plus facile pour moi de créer des composants là. Le seul point positif de JSF est qu'il y a une tonne de bibliothèques de composants. Le problème commence lorsqu'elles ne fonctionnent pas, que vous voulez changer quelque chose ou créer votre propre composant.
• la gestion des exceptions est un désordre (ou quelque chose a changé au cours de la dernière année ou deux ?)
• JSF a des problèmes parce qu'il est trop étatique - quelques mauvaises décisions, une mauvaise dev dans votre projet et la moitié de votre application peut être stateful et sérialisée.
• la partie IU de la norme ne le fait pas (ou du moins ne le faisait pas lorsque j'ai écrit cette réponse) ne couvre pas la plupart des collections de Java (en fait, seuls les structure de données décemment couverte était une liste).

Quant à la norme que vous affectionnez tant, ont-ils enfin intégré JSF et JAX-RS ? Car la dernière fois que j'ai vérifié, ces spécifications étaient totalement séparées, même si l'on pouvait apporter de nombreuses améliorations. Par exemple, pourquoi ne puis-je pas annoter une méthode avec @Path dans mon backing bean pour qu'elle soit traitée à la fois par une requête REST et une requête JSF ?

Peut-être que certains (tous ?) de ces problèmes sont maintenant corrigés, mais lorsque j'ai écrit cette réponse, ils n'étaient que quelques-uns parmi toutes les mauvaises choses concernant JSF et la norme en général.

Actuellement, si je veux créer une très petite application CRUD simple, j'utilise Play 2.0 (même si c'est un énorme anti-modèle) ou quelque chose comme RoR. Lorsque je veux créer une grande application de niveau "entreprise", je prends un framework JS (comme ExtJS) et une bibliothèque de composants JS, je les combine avec un backend Java (et par exemple Spring) et je fais ce dont j'ai besoin sans aucune surcharge que cette soi-disant norme pourrait apporter.

Bien sûr, il y a des parties intéressantes de JEE6 comme JPA2, JAX-RS2, la validation des haricots n'est pas si mauvaise. Mais utiliser l'ensemble de la pile standard uniquement parce qu'ils l'ont appelée "standard" (et comme je l'ai mentionné ci-dessus, la plupart des spécifications ne sont même pas synergiques) est, à mon avis, la meilleure façon de faire. très humble avis, tout simplement faux.

Answer 4

Je pense que vous aurez remarqué que travailler avec Spring vous rend plus productif que Java EE. Je ne pense pas qu'ils seront un jour capables de faire voler le cochon (Java EE). Java est un langage/une plateforme formidable, ne l'entravez pas avec Java EE. Pourquoi se contenter d'une "sorte d'injection de dépendances", si vous pouvez aujourd'hui avoir Spring ?