Pourquoi j'utilise le standard Java EE au lieu de Spring

Tout récemment, après une de mes sessions de formation, un participant m'a demandé quelles étaient les raisons de mon utilisation de Java EE. Au cours de la séance, j'ai mentionné que par le passé, j'étais aussi un gros fan de Spring.

En fait, j'ai toujours aimé programmer via Spring, et j'ai aimé le modèle de programmation déclarative avec des annotations et le fait que la technologie évolue assez rapidement. J'ai utilisé Spring jusqu'à la version 4 dans des projets concrets, et j'ai toujours essayé d'utiliser les dernières approches - comme @RestControllers, ou la configuration basée sur Java à l'époque.

Outre le fait que Spring a offert une excellente expérience de développement, je n'ai pas aimé certaines choses à ce sujet:

• Il y a beaucoup de configuration nécessaire (XML, puis config Java, configuration BD / transaction), qui doit être changé assez souvent.
• Des temps de construction plus longs (car l'implémentation est fournie dans l'artefact de déploiement) - on finit par déployer un war léger sur un conteneur de Servlet.
• Pas toujours rétrocompatible (ou entièrement compatible avec d'autres composants Spring et avec des cycles de vie différents, comme Spring Security) lors de la mise à jour des versions.

En plus de Spring, j'ai aussi utilisé beaucoup de Java EE - en fonction du projet. Ce que j'ai particulièrement apprécié à propos de Java EE, c'est la puissante injection de dépendance fournie par CDI et le fait que la technologie au sein de l'EE peut être utilisée immédiatement - comme Bean Validation avec CDI. En plus, les temps de construction rapides avec de petits fichiers war m'ont fait considérer Java EE comme le choix favorable de plus en plus.

Ce qui m'a vraiment plait, c'est le fait que Java EE 7 peut être utilisé avec Java 8 sans aucune autre dépendance (techniquement argumentée). Avec les approches conventionnelles sur-configuration et just-mix-and-match-what-you-like, il offre une expérience de développement productive et, je pense quelle est vraiment agréable.

Ainsi, à partir d'aujourd'hui, mes principales raisons pour favoriser Java EE en tant que framework d'entreprise - cela dépend toujours du projet et des cas d'utilisation - sont:

• L'utilisation des différentes spécifications de façon transparente.
• La configuration de zéro minimale, approches conventionnelles sur configurations.
• Le modèle de programmation puissant et flexible de CDI.
• La séparation du code Entreprise de la mise en œuvre du framework 
• Des temps de construction, de transfert et de déploiement très courts.
• Rétrocompatibilité (particulièrement intéressante pour les projets d'entreprise de longue durée) et aucune surprise lors de la mise à jour d'une version.

Conclusion

Généralement, le choix de la technologie dépend de ce que vous essayez de réaliser et de la façon dont vous et vos collègues connaissez ces technologies. La question n'est pas de savoir si A est meilleur ou pire que B mais plutôt quelles sont les forces et les faiblesses et quand les appliquer.

Peu importe si vous utilisez Spring ou Java EE, je vous conseillerais, en général, d'en choisir un, mais ne les mélangez pas ensemble. À mon avis, il n'est pas très judicieux de déployer Spring sur un serveur d'applications EE ou d'utiliser la technologie spécifique à Java EE dans une Stack Spring, qui est déjà couverte par un autre composant spécifique à Spring.