Java EE 6 vs Spring 3 stack [fermé]

Je démarre un nouveau projet maintenant. Je dois choisir les technologies. J'ai besoin de quelque chose de léger, donc pas d'EJB ou de Seam. D'un autre côté, j'ai besoin de JPA (Hibernate ou alternative) et JSF avec IceFaces.

Pensez-vous qu'une telle pile sur Spring 3 déployée sur Tomcat soit un bon choix? Ou une application Web Java EE 6 pourrait être meilleure? J'ai peur que Java EE 6 soit une nouvelle technologie, pas encore bien documentée. Tomcat semble être plus facile à entretenir que Glassfish 3.

Quelle est ton opinion? Avez-vous des expériences?

J'ai besoin de quelque chose de léger, donc pas d'EJB ou de Seam.

Voudriez-vous expliquer ce qui rend les EJB lourds depuis l'EJB3? Vous rendez-vous compte que nous ne sommes plus en 2004? J'aimerais beaucoup lire votre définition de la lumière et vos arguments (et je mettrai à jour ma réponse avec plaisir car je suis presque sûr que j'aurais quelques choses solides à dire).

D'un autre côté, j'ai besoin de JPA (Hibernate ou alternative) et JSF avec IceFaces.

Java EE 6 Web Profile qui inclut JSF 2.0, JPA 2.0, Bean Validation, EJB 3.1 Lite, CDI, ... serait parfait pour cela et vous pouvez utiliser GlassFish v3 Web Profile pour exécuter une application créée avec le profil Web Java EE 6 .

Pensez-vous qu'une telle pile sur Spring 3 déployée sur Tomcat soit un bon choix? Ou une application Web Java EE 6 pourrait être meilleure?

Eh bien, je aime l'idée de courir mon code sur une plate - forme non exclusive (Java EE) plutôt que sur un conteneur exclusif (printemps). Et je pense que Java EE 6 est assez bon (et c'est un euphémisme, EJB 3.1 (Lite), JPA 2.0, JSF 2.0, CDI kick ass). Notez que j'étais un sceptique JSF mais j'ai jeté un second regard et JSF 2.0 avec CDI est si différent que je ne peux même pas comparer. Et si vous n'avez pas regardé CDI, laissez-moi vous dire que ça marche.

J'ai peur que Java EE 6 soit une nouvelle technologie, pas encore bien documentée.

Java EE me semble assez bien documenté. Cela ressemble à une réclamation gratuite. Et, croyez-moi ou non, je commence à trouver que Spring se complique tandis que Java EE devient plus facile.

Tomcat semble être plus facile à entretenir que Glassfish 3.

Avez-vous essayé quelque chose? Avez-vous rencontré un problème particulier? Encore une fois, cela ressemble à une réclamation gratuite.

Je n'ai pas utilisé JavaEE6.

Cependant, j'ai été suffisamment battu par toutes les versions précédentes de JavaEE et d'EJB pour que je ne lui fasse pas confiance tant qu'il ne s'impose pas comme la norme de facto, pas seulement comme la norme de jure. À l'heure actuelle, le printemps est toujours la norme de facto.

Trompez-moi une fois, honte sur vous. Trompez-moi deux fois, honte sur moi. Trompez-moi trois fois, EJB.

Certains prétendront que Spring est propriétaire. Je dirais que les implémentations des fournisseurs des spécifications JavaEE ont été tout aussi propriétaires, sinon plus.

J'ai récemment subi une conversion majeure en déplaçant un tas d'applications Java de JBoss vers Weblogic. Toutes les applications Spring / Hibernate ont été portées sans aucune modification, car elles avaient toutes les bibliothèques dont elles avaient besoin intégrées. Toutes les applications qui utilisaient JPA, EJB et JSF étaient un désastre à porter. De subtiles différences dans les interprétations de JPA, EJB et JSF entre les serveurs d'applications ont provoqué toutes sortes de bugs désagréables qui ont mis une éternité à être corrigés. Même quelque chose d'aussi simple que le nommage JNDI était complètement différent entre les AppServers.

Spring est une implémentation. JavaEE est une spécification. C'est une énorme différence. Je préférerais utiliser une spécification SI la spécification était 100% étanche à l'air et ne laissait absolument aucune marge de manœuvre dans la manière dont les fournisseurs implémentent cette spécification. Mais la spécification JavaEE n'a jamais été cela. Peut-être que JavaEE6 est plus étanche à l'air? Je ne sais pas. Plus vous pouvez créer un package dans votre WAR, et moins vous dépendez des bibliothèques AppServer, plus votre application sera portable, et c'est après tout la raison pour laquelle j'utilise Java et non Dot-NET.

Même si les spécifications étaient hermétiques, ce serait bien de pouvoir mettre à niveau le serveur d'applications sans avoir à mettre à niveau toutes mes piles technologiques dans toutes mes applications. Si je souhaite passer de JBoss 4.2 à JBoss 7.0, je dois tenir compte de l'impact de la nouvelle version de JSF sur toutes mes applications. Je n'ai pas besoin de considérer l'impact sur mes applications Spring-MVC (ou Struts).

Cela n'a pas d'importance. Java EE 6 est assez bon et à cause des profils là-bas, il n'est pas "lourd" - vous utiliserez simplement le profil Web.

Personnellement, je préfère le printemps. Mais je suis à court d'arguments rationnels contre Java EE 6 :)

(Comme un commentaire m'a rappelé - vous voudrez peut-être essayer RichFaces , ainsi que ICEfaces et / ou PrimeFaces - en fonction des composants dont vous avez besoin).

Récemment, l'une de mes missions client impliquait l'évaluation de la pile de framework Spring Stack Vs Custom Vs a Java EE Standards. Après un mois d'évaluation et de prototypage, je n'étais pas seulement content mais époustouflé par l'ensemble des fonctionnalités de Java EE 6. Pour toute nouvelle architecture de projet «entreprise» en 2011 et à l'avenir, j'irais avec Java EE 6 et des extensions potentielles comme Seam 3 ou le prochain projet d'extensions Apache JSR299. L'architecture Java EE 6 est rationalisée et incorpore le meilleur des nombreuses idées open source qui ont évolué au cours des dernières années.

Considérez les fonctionnalités suivantes prêtes à l'emploi: gestion des événements, contextes et DI, intercepteurs, décorateurs, services Web RESTful, tests intégrés avec conteneur intégrable, sécurité et bien d'autres.

La plupart de mes résultats sont publiés dans mon blog expliquant les concepts clés de Java EE 6 que vous pourriez trouver utiles.

Bien sûr, il n'y a pas de règle absolue pour choisir un cadre. Java EE 6 pourrait être pléthorique pour les "sites Web" plus simples qui ne nécessitent pas un état de session conversationnel riche. Vous pouvez aussi bien choisir Grails ou Play! Cadre. Mais pour les applications Web conversationnelles, je ne vois pas de meilleur argument pour expliquer pourquoi Java EE 6 ne convient pas.

Maintenant, après un certain temps, j'ai de l'expérience avec les piles:

• Java EE 5 + Seam + GraniteDS + Flex
• Spring 3 + Vaadin (sur GWT)
• Printemps 3 + JSF 2.0 (PrimeFaces)

Mes colclusions sont:

• Spring 3 est beaucoup plus simple que Seam (presque Java EE 6) et fonctionne sur Tomcat et Jetty! (Jetty pour le développement avec le plugin maven est une trasure).
• J'adore Flex (j'étais en fait un développeur Flex pendant longtemps, donc je suis partial) et si vous avez besoin d'une interface riche et pouvez acheter FlashBuilder, utilisez-la, mais utilisez ce backend Spring + GraniteDS ou BlazeDs. Si vous ne pouvez pas acheter FlashBuilder, ne perdez pas votre temps.
• Vaadin est génial !. Le processus de développement est plus simple que Flex, mais vous pouvez créer facilement une application riche sans gâchis HTML. Vous n'écrirez pas une seule ligne JS. Vous avez juste besoin de CSS (dans Flex, vous en avez aussi besoin). Donc, si l'interface de votre application va se comporter comme une application de bureau et que vous ne pouvez pas (ou ne voulez pas) utiliser Flex, utilisez Vaadin. Avertissement! Vaadin a de gros frais généraux JS pour le navigateur.
• Si vous créez une application de type site Web plus simple, utilisez JSF2.0 (avec le backend à ressort comme ci-dessus). Vous devrez vous battre avec HTML (je déteste ça) et créer une interface riche sera plus difficile que Vaadin (en particulier les mises en page). Vous obtiendrez du HTML léger pour les navigateurs / ordinateurs plus lents. J'aime PrimeFaces - c'est facile et bien documenté. La deuxième place est IceFaces
• Si vous créez un site Web (PAS une application Web) où vous devez donner vie à HTML (au lieu de créer une application d'entreprise qui s'intègre dans le navigateur), utilisez Wicket (si vous préférez basé sur les composants, pull attitude) ou SpringMVC (si vous préférez basé sur un modèle , push attitude) ou utilisez simplement Play! cadre. N'oubliez pas que la création de composants riches à base de données sera beaucoup plus difficile, mais vous aurez le contrôle sur chaque balise HTML (votre concepteur HTML / graphique l'adorera)

Lisez Future Of Enterprise Java ... Is Clear d' Adam Bien (Java EE avec / sans Spring et Vice Versa) , y compris des commentaires pour obtenir les deux côtés de la médaille. Je choisirai Spring pour plusieurs raisons et voici l'une d'entre elles (reproduisant l'un des commentaires de l'article)

«Je ne sais pas de quel serveur Java EE 6 vous parlez. Il est certifié Glassfish et TMAX JEUS. Cela prendra un certain temps (lire: des années) avant que les versions compatibles Java EE 6 de WebSphere, WebLogic, JBoss, etc. soient en production et puissent être utilisées pour des applications réelles. Spring 3 n'a besoin que de Java 1.5 et J2EE 1.4 et peut donc être facilement utilisé dans presque tous les environnements '

Mon opinion est basée sur quelque chose qui n'a pas été mentionné par d'autres, à savoir que le code dans mon travail a tendance à vivre pendant des décennies (littéralement), et donc que la maintenance est très importante pour nous. Maintenance de notre propre code et des bibliothèques que nous utilisons. Nous contrôlons notre propre code, mais il est dans notre intérêt que les bibliothèques que nous utilisons soient maintenues par d' autres dans les décennies mentionnées ci-dessus ou plus.

Pour résumer, j'ai conclu que le meilleur moyen d'y parvenir est d'utiliser des implémentations open source des spécifications Sun jusqu'à la JVM brute.

Parmi les implémentations open source, Apache Jakarta a prouvé qu'il maintenait ses bibliothèques, et récemment Sun a fait beaucoup de travail pour produire des implémentations de haute qualité pour Glassfish v3. Dans tous les cas, nous avons également la source de tous les modules, donc si tout le reste échoue, nous pouvons les maintenir nous-mêmes.

Les spécifications Sun sont généralement très strictes, ce qui signifie que les implémentations conformes à la spécification peuvent être facilement échangées. Jetez un œil aux conteneurs de servlets.

Dans ce cas particulier, je suggérerais de jeter un œil à JavaServer Faces simplement parce qu'il fait partie de Java EE 6, ce qui signifie qu'il sera disponible et maintenu pendant très, très longtemps. Ensuite, nous avons choisi d'augmenter avec MyFaces Tomahawk car cela donne des ajouts utiles, et c'est un projet jakarta.

Il n'y a rien de mal avec JBoss Seam ou d'autres. C'est juste qu'ils se concentrent moins sur la question de la maintenance qui est si importante pour nous.

Je peux voir en utilisant Spring si vous l'avez déjà, mais pour le nouveau projet, à quoi ça sert? J'irais directement avec Java EE 6 (ejb3, jsf2.0, etc.)

Si le client est d'accord avec Flex, allez-y. Utilisez BlazeDS ou similaire - pas de mvc. Vous pourriez passer plus de temps sur cette partie (échange de données entre le serveur et le client), mais vous avez un contrôle total des deux côtés.

N'utilisez pas Vaadin, sauf si vous voulez tuer votre navigateur. De plus, vous passez plus de temps à contourner le code une fois que vos pages deviennent plus complexes. En outre, votre état d'esprit devra être complètement changé et tout ce que vous savez sur le développement frontal standard sera du gaspillage. L'argument selon lequel vous n'avez pas besoin d'utiliser HTML ou JS n'a pas beaucoup de sens. Vous devez toujours le savoir même si vous ne l'utilisez pas. Il rend finalement en HTML et JS. Ensuite, essayez de le déboguer - assurez-vous de disposer de quelques jours pour des choses simples. De plus, je ne peux pas imaginer un développeur Web qui ne connaît pas html / js.

Je ne comprends tout simplement pas pourquoi les gens essaient toutes ces abstractions au lieu d'utiliser directement Java EE.

Pourquoi y a-t-il encore des rumeurs sur le fait que l'EJB soit un poids lourd en 2010? Il semble que les gens ne soient pas mis à jour dans les technologies Java EE. Essayez-le, vous serez agréablement surpris de voir comment les choses sont simplifiées dans Java EE 6.

La réponse à vos questions dépend des exigences de votre projet. Si vous n'avez pas besoin des fonctionnalités Java EE telles que les files d'attente de messages, les transactions globales gérées par conteneur, etc., optez pour tomcat + spring.

Également par expérience, j'ai trouvé que les projets qui nécessitent beaucoup d'intégration de services Web, de planification et de files d'attente de messages sont mieux réalisés en utilisant une partie de la pile Java EE. La bonne chose est d'utiliser Spring que vous pouvez toujours intégrer aux modules Java EE exécutés dans un serveur d'applications.

Java EE 6 est très différent des versions précédentes, et cela rend vraiment tout beaucoup plus facile. Java EE 6 combine les meilleures idées de la communauté Java diversifiée - par exemple, Rod Johnson du framework Spring a été activement impliqué dans la création du Dependency Injection JSR dans Java EE 6. Un avantage de l'utilisation de Java EE 6 est que vous codez selon une norme, qui pourrait être importante dans certaines organisations pour le support des fournisseurs, etc.

GlassFish v3 prend en charge Java EE 6 et il est assez léger et démarre très rapidement. J'utilise glassfish v3 pour mes développements, et c'est vraiment facile à configurer. Il est livré avec une console d'administration très conviviale qui vous permet d'administrer graphiquement votre serveur.

Si vous utilisez GlassfishV3 et JSF 2, vous pouvez profiter des fonctionnalités CDI de Java EE 6, qui vous permettent de créer facilement des conversations (par exemple, des pages de type assistant) dans JSF.

Cela dit, l'utilisation de Java EE 6 vous oblige également à apprendre une nouvelle API. Selon la période disponible, ce n'est peut-être pas le meilleur choix pour vous. Tomcat existe depuis des lustres, et la combinaison tomcat + spring a été adoptée par de nombreux projets Web, ce qui signifie que de nombreux documents / forums sont disponibles.

J'ai travaillé à la fois avec Spring et Java EE 6. Ce que je peux dire de mon expérience, c'est que si vous optez pour le JSP séculaire ou le Flex propriétaire, vous êtes en sécurité si vous restez avec Spring.

Mais si vous voulez aller de l'avant avec JSF, il est temps de passer à Java EE 6. Avec Java EE 6, vous passez aux Facelets et aux bibliothèques de scripts et de composants standardisés. Fini les incompatibilités de script et les matrices de bibliothèques de composants.

En ce qui concerne Spring MVC, c'est bien tant que votre projet ne grossit pas trop. S'il s'agit d'une énorme application d'entreprise, restez fidèle à Java EE 6. Parce que c'est la seule façon de gérer vos propres bibliothèques de composants et ensembles de ressources de manière ordonnée.

Si vous avez besoin de la pile complète Java EE, je vous recommande GlassFish 3.1. Il démarre très rapidement par rapport aux autres conteneurs Java EE qui implémentent une partie ou la totalité de Java EE 6 (JBoss 6, WebLogic 10.3.4), le redéploiement prend quelques secondes et presque tout peut être fait par convention sur la configuration, c'est très convivial.

Si vous voulez quelque chose de "léger", vous pouvez personnaliser un Apache Tomcat 7.x avec les fonctionnalités souhaitées. J'ai beaucoup utilisé avec les bibliothèques suivantes: Weld 1.1.0 (CDI) JPA 2.0 (Hibernate 3.6.x) - uniquement les transactions locales de ressources JSF 2.x (Mojarra) RichFaces 4.0 BIRT runtime

Développeur Java EE depuis 10 ans (je souffre au début des technologies EJB, JSF et web), Java EE 6 est très simple, bien couplé et le matériel actuel fonctionne bien donc les raisons originales qui ont motivé Spring ne sont plus valables.

Je préférerais toujours le printemps.

Et je transmettrais JSF. Je pense que c'est une technologie morte. Spring MVC serait une meilleure alternative. Tout comme Flex. Pensez en termes de contrat de premiers services XML et vous pouvez dissocier complètement le back-end de l'interface utilisateur.

Je recommanderais Spring + Tomcat à moins que vous ne puissiez attendre le temps que Glassfish v3 et Weld deviennent plus matures. Il existe actuellement quelques problèmes de consommation de mémoire / charge du processeur lors de l'exécution de glassfish avec des applications compatibles CDI.

Je n'ai pas tout lu mais juste pour dire que vous pouvez maintenant utiliser EJB3 dans une guerre sur Java EE 6 afin que vous puissiez utiliser EJB3 sur Tomcat (je pense).

Je vous ai recommandé Tomcat avec Spring car:

1. Spring peut créer des backing beans pour JSP
2. Vous utiliserez Spring pour conserver l'objet via JPA

C'est un bon choix de choisir Tomcat car vous n'avez besoin d'aucun traitement lourd