Gavin King [1], le père d'Hibernate, a recommandé aux développeurs de passer à la plate-forme Java EE 6 et a souligné que la réticence actuelle à mettre à niveau est en réalité infondée.
Après la sortie de Java EE 6, j'ai constaté une forte résistance à la mise à niveau vers la nouvelle plate-forme. La plupart de ces objections sont soulevées par les utilisateurs de Tomcat/Jetty et de certains frameworks open source (comme Hibernate et Spring).
Bien entendu, le choix d’une technologie open source non standard présente de nombreux avantages. De plus, dans EE 6, vous pouvez utiliser les frameworks open source qui vous intéressent. Servlet 3 et CDI peuvent intégrer de manière transparente des frameworks tiers. Il n'y a donc aucune raison de ne pas utiliser EE 6. Pourtant, j'ai vu quelqu'un dire :
La mise à niveau vers EE Application Server est difficile
Cela semble être une question politique pour l’organisation spécifique plutôt qu’une véritable question technique. Bien entendu, mettre à niveau un serveur tel que GlassFish ou JBoss est une tâche très simple. (La mise à niveau des frameworks tiers est encore plus pénible.) Certaines organisations ont un processus très lourd pour la mise à niveau des serveurs, mais pas tellement pour la mise à niveau des frameworks exécutés sur les serveurs. Par conséquent, il est plus facile pour l’équipe de développement de mettre à niveau les frameworks tiers.
Je pense que développer un processus plus convaincant et meilleur est la chose la plus importante, plutôt que d'abandonner Java EE. Il existe de nombreux risques associés à l’exécution de votre application sur une plate-forme de serveur ancienne et obsolète, et le processus ne doit pas encourager de telles pratiques.
Mais d’un point de vue pratique, presque tout le monde envisage de passer à Servlet 3 dans un avenir proche. Que vous utilisiez Tomcat, Jetty, JBoss, GlassFish, Resin, WebLogic, Oracle ou WebSphere, cela signifie une mise à niveau du serveur. C'est une excellente opportunité de passer au profil Web EE 6, c'est le moment idéal.
Le serveur d'applications EE est trop gros
L'objection est que EE Server contient de nombreuses fonctionnalités qui ne sont pas (actuellement) disponibles. Les arguments des opposants impliquent généralement de discuter de la taille du package jar et de l'espace disque occupé par le moteur Servlet + framework tiers et le serveur d'applications EE. En fait, cet argument est problématique :
L'utilisation du disque et l'espace disque discutés sont en fait insignifiants lorsqu'ils sont mesurés en $, et le package de guerre d'application est beaucoup plus important que la taille du package d'installation du serveur. Le serveur contient en fait de nombreuses fonctions pour minimiser la taille de la guerre.
De plus, je pense que la chose la plus convaincante est que le profil Web Java EE 6 n'est pas énorme du tout. Une fois les serveurs de profils Web certifiés sur le marché, nous pouvons trouver un équilibre entre les grands serveurs d'applications EE et les petits conteneurs de servlets.
Mauvais J2EE et EJB2 !
Avec le processus de standardisation de JCP, ce problème n’existe plus :
1. Cela fait 8 ans que EJB2 est apparu ! Est-ce toujours votre meilleur choix ?
2. De bonnes spécifications ont été fusionnées grâce à la normalisation continue du JCP, et certaines d'entre elles peuvent être utilisées avec une grande certitude. Cependant, JCP ne réussit pas à 100 % en matière de normalisation.
3. Tous ceux qui travaillent sur la plateforme EE 6 détestent EJB2 et J2EE. C'est pourquoi des gens rejoignent constamment le JCP pour aider à résoudre ces problèmes. Par exemple, le fondateur d'Hibernate et l'auteur de cet article. Voulez-vous vraiment lui donner une leçon sur EJB2 ? :-)
4. Presque toutes les personnes qui travaillent sur Entity Beans sont désormais à la retraite !
En fait, le profil Web Java EE 6 est suffisant. Si vous n'essayez pas Java EE 6 vous-même, vous ne pourrez pas vraiment ressentir les avantages de EE6 pour le développement.
La portabilité des serveurs d'applications est un tel mystère !
Vraiment? Nous voyons de nombreuses personnes diviser leurs applications et les déployer sur différents serveurs d'applications ? Oh, j'ai vu cela signifie un portage d'application 100 % sans faille, sans changement, un idéal platonicien de portabilité. Je comprends la faiblesse de la vérité absolue et des idéaux platoniciens, mais regardons d’abord des exemples.
Voici une vue très typique d'un problème de portabilité :
9 % du code, 85 % des métadonnées externes sont entièrement compatibles sur différentes plates-formes de serveur, et les 1 % et 15 % restants peuvent être répartis de manière appropriée
0 % de code, 80 % de métadonnées externes liées à une architecture de conteneur non standard et à fournisseur unique
Alors que je divisais ces points, j'ai soudainement voulu changer le sujet de cette section de la portabilité des serveurs d'applications, qui est trop mystérieuse, à "Je ne me soucie pas du tout de la portabilité des conteneurs". L’idée d’un changement de thème confirme que la problématique de portabilité du serveur est réelle et qu’il sera très utile à de nombreuses organisations.
J'ai toujours voulu voir de vraies critiques sur EE 6 de la part de responsables techniques non-EE 6. Certains des arguments mentionnés ci-dessus ne proviennent pas du monde réel, il est donc difficile de déclencher des discussions sur les problèmes techniques réels liés au développement d'applications sur la plateforme EE. La dernière série de spécifications du JCP semble avoir quitté le camp anti-EE (temporairement ?), mais manque de preuves factuelles pour garantir son succès.
Note de l'éditeur :
[1] Gavin King : fondateur d'Hibernate, membre du comité d'experts EJB3, l'un des principaux membres de JBoss, leader du framework Seam, leader des spécifications JSR-299 (CDI) et auteur du livre "Hibernate in Action" .
Source : Vous devez passer à Java EE 6