février
2008
Vous êtes probablement au courant déjà de la JSR 316 qui groupe les spécifications du futur Java EE 6 et qui consiste à subdiviser le stack Java EE en profils spécifiques à des besoins particuliers.
Indéniablement, le profil le plus intéressant est le Profil Web.
Roberto Chinnici, le co-lead de la spécification Java EE 6, a publié sur son blog une première proposition pour le profil Web, en précisant que les membres du groupe d’expert en charge ne sont pas arrivé à se mettre d’accord sur une seule proposition (compréhensible et logique vu le nombre impressionnant de technologies et standards impliqués), et qu’ils voudraient récupérer l’avis de la communauté.
Il propose donc deux versions que voici:
Version A:
- Servlet 3.0
- JSP 2.2
- JSR-45 (Support de débogage d’autres langages que Java)
- EL 1.2
- JSTL 1.2
- JSR-250 (Annotations standard)
Version B:
- Servlet 3.0
- JSP 2.2
- JSR-45 (Support de débogage d’autres langages que Java)
- EL 1.2
- JSTL 1.2
- JSR-250 (Annotations standard)
- EJB 3.1 Lite: Un sous ensemble d’EJB 3.1, mais pas encore défini
- JTA 1.1
- JPA 2.0
- JSF 2.0 (Provoque une controverse)
- Web Beans 1.0 (Idem)
- etc.
Personellement, je préfère la version A, plus légère, mais surtout générique dans le fait qu’elle n’impose pas de framworks particuliers (web=JSF, persistence=JPA), et qu’elle se présente plutôt comme un support sur lequel reposent les autres framworks comme Wicket ou Struts, etc. côté web et Hibernate, iBatis, etc. pour la persistence.
Bien que j’utilise principalement JSF et JPA, je ne crois pas que les inclure dans le profil web soit une bonne idée vu que c’est en quelque sorte imposer quoi utiliser comme framework web et persistence, or l’un des atouts (problèmes ?) de l’ecosystème Java est jsutement la diversité du choix.
En fait, ce qui me dérange vraiment, c’est surtout l’inclusion de l’EJB (même lite) dans la version B: Je ne vois plus en quoi le profil Web va différer du stack complet, et ça va compliquer encore la mise en place d’implémentations de conteneurs web (Tomcat/Jetty).
De plus, je crois que Spring a déjà prouvé son efficacité dans ce domaine là.
Vous en pensez quoi ? Vous choisissez la version A ou B ?
ah oui, effectivement, ça discute pas mal. (a mon plus grand étonnement)
Bah ailleurs sur le net, beaucoup sont plutôt pour la B, en disant que la A existe déjà (Tomcat), et ça n’aura pas de sens ou d’utilité particulière …
Remrqu’aussi que cette histoire de profils et Java EE 6 en générl n’a pas eu un acceuil chalereux … loin de ça même (Indice: Spring). Suffit d’aller voir sur TSS par exemple.
moué, y a t il vraiment débat ?
clair que la A est la bonne !
Donc le profil A – JSR 45 – JSTL ? Ca se défend en effet : Qui a jamais utilisé la JSR 45 ? et c’est pas sorcier d’inclure soit même une implémenation JSTL (celle de Glassfish en fait).
En tout cas, j’adore l’idée de Vincent: Je reformule: « Le profil Web est en fait une couverture pour officialiser Tomcat »
Pour moi, le profil Web devrait correspondre à ce qu’on peut faire tourner sous Tomcat sans rajouter de JAR dans son application WEB.
Suffit donc de faire l’inventaire des JARs livrés avec en standard avec Tomcat. Et voilà
Hello Loic,
Au fait, pour clarifier un point: elon les dires de Roberto Chinnici, si l’application n’utilise pas une fonctionnalité particulière (JSF, JPA, etc.), cette dernière ne devrait consommer ni de cycles CPU ni de l’espace mémoire …
Moi aussi je pense que la version A est plus intéressante, et que la version B impose trop de choix.
Celà a peu d’intêts de proposer un sous emsemble de java EE 6 et d’imposer d’utiliser la quasi totalité des frameworks sun.
Du coup les développeurs comme moi qui préfèrent spring+hibernate+wicket ne pourraient pas se servir de ce profil web…