Discussion :

[Hinault Romaric]

Java souffle sa 20e bougie
que pensez-vous de l’évolution du langage et de son avenir sous l’égide d’Oracle ?

Voilà déjà 20 ans que le langage de programmation Java existe dans l’univers du développement informatique, et il n’est pas prêt à prendre sa retraite.

Les travaux sur Java débutent en 1991, sous le nom du projet Green, dans les laboratoires de Sun Microsystems. Le projet est dirigé par Patrick Naughton, Mike Sheridan et James Gosling. Il donne naissance finalement au langage de programmation « Oak ».

Basé sur une syntaxe très proche de celle du C++, le langage est destiné à la conception des applications pour les petits appareils. Il reprend le concept de machine virtuelle déjà exploité dans le Pascal UCSD.

En 1992, Sun développe avec Oak un assistant numérique, qui sera un échec. Mais, les éléments de base de Oak ont été repris pour créer un nouveau langage appelé Java, qui fut présenté pour la première fois le 23 mai 1995, lors de la conférence SunWorld à San Francisco.

Sun dévoile alors le navigateur Web HotJava écrit en Java, et capable d’exécuter des applets Java. Le concept a été repris par les autres navigateurs, dont Netscape.

L’explosion de la bulle d’Internet et le fait que Java ne dépende pas d’une plateforme particulière ont contribué au succès du langage de programmation.

Robuste, performant, multiplateforme et disposant d’un vaste ensemble de bibliothèques intégrées, Java s’est positionné à cette époque comme le langage de référence pour le développement d’applications d’entreprises.

Bénéficiant du support de certains géants de l’IT, dont IBM, Java devient l’un des langages les plus utilisés dans le monde. Au fil des versions, il gagne en maturité et s’enrichit des nouvelles fonctionnalités importantes, tout en concevant ses aspects fondamentaux.

Java constitue aujourd'hui la colonne vertébrale d'une multitude de logiciels présents aussi bien dans notre vie personnelle que dans notre vie professionnelle. Il est le langage de programmation utilisé par 9 millions de développeurs et embarqué aujourd'hui dans 7 milliards d'appareils et objets, selon Oracle. Pour Mark Reinhold, architecte en chef du projet Java, l’autre atout de Java est sa lisibilité et sa simplicité.

Les développeurs d’applications d’entreprise peuvent choisir librement dans un écosystème de 30 implémentations compatibles des standards Java EE 6 et Java EE 7, proposées par 12 éditeurs différents. Plus de 125 millions d'appareils multimédias basés sur Java ont déjà été déployés, et plus de 10 milliards de cartes JavaCard ont été déployées depuis l'arrivée de Java.

« Java s'est développé pour devenir aujourd'hui l'une des technologies les plus importantes et les plus incontournables de notre industrie. Ceux qui ont choisi Java ont été maintes fois récompensés par l'amélioration constante de ses performances, de son évolutivité, de sa fiabilité, de sa compatibilité et de ses fonctionnalités, » déclare Georges Saab, Vice President of Development, Java Platform Group chez Oracle. « L'écosystème Java rassemble des quantités impressionnantes de bibliothèques, de frameworks et de ressources pour aider les programmeurs les plus novices aussi bien que les experts. Le développement de Java lui-même s'effectue de façon transparente dans le cadre de la communauté OpenJDK. Avec les investissements considérables réalisés par Oracle et d'autres acteurs de cette communauté, nous sommes impatients d'assister aux 20 prochaines années d'évolution et de croissance de Java. »

Suite au rachat de Sun, Java est passé sous l’égide d’Oracle. Sous la supervision de la firme, deux versions majeures de la plateforme ont vu le jour , Java 7 et Java 8.

Java 8 représente l’une des versions les plus importantes de la plateforme. Java 8 apporte la plus importante évolution du modèle de programmatique de Java depuis son lancement. Comme nouveautés phares, on note les expressions lambdas, les méthodes par défaut, les interfaces fonctionnelles, Profiles ou encore Streams.

Actuellement, Oracle et la communauté travaillent activement sur la prochaine version de Java. La nouveauté la plus attendue de Java 9 est la modularité avec le projet Jigsaw, qui rendra sa taille encore plus pertinente et évolutive sur une large gamme d'appareils. Jigsaw a entrainé de gros changements au JDK. Elle permettra de découper la bibliothèque d’exécution de base de Java en différents modules. Ainsi, une machine virtuelle Java (JVM) pourra fonctionner sans le support de certains packages de base.

Java 9 apportera également la console en ligne de commande Java Shell, un outil interactif permettant d'évaluer les bouts de code Java ; une nouvelle API HTTP-Client pour supporter HTTP/2 et les WebSockets ; un portage pour l'architecture ARM AArch64 sur Linux ; et de différentes mises à jour des API existantes ainsi que quelques améliorations importantes des performances.

D’après la feuille de route publiée par Oracle, Java 9 sortira en version stable le 22 septembre 2016. Le gel des fonctionnalités est prévu pour le 10 décembre 2015.

Pour commémorer les 20 ans de Java, Oracle Certification offre une remise de 20% sur tous les examens de certification Java. Cette offre est disponible dans le monde entier jusqu'au 31 décembre 2015. Les candidats doivent fournir le code promotionnel Java20 lors de leur inscription.

Oracle ne s’est pas contenté de faire évoluer le langage. Il a également créé des sueurs froides dans la communauté, en poursuivant en justice Google pour violation de ses brevets Java dans Android et sa machine virtuelle Davilk. Oracle soutient que « Les API Java peuvent être protégées par le droit d’auteur ». Cette affaire représente une menace importante pour le secteur de la technologie.

Néanmoins, Java demeure le langage de programmation de choix de nombreux développeurs et compte évoluer désormais plus rapidement, à une fréquence d’une nouvelle version majeure tous les deux ans.

En tant que communauté de développeurs, souhaitons un heureux anniversaire à Java et célébrons les 20 ans de la plateforme.


Rétrospective des événements qui ont marqué les 20 années de Java


Et vous ?

Que pensez-vous de l’évolution de Java ?

L'acquisition de Java par Oracle a-t-elle été une bonne chose pour le langage ?

[MikeRowSoft]

La dernière fois que j'ai vue les sites Internet d'Oracle et Java, j'ai surtout remarqué la large gamme d'outils. Distribution Linux, Solaris, SGDB, Java, EDI, etc... Le tous très ouvert aux autres systèmes. Java n'est à mon avis qu'un reflet de la volonté d'Oracle vis-à-vis de la définition de ce qu'est une information et du principe de base de comment elle doit être traité.

[Ph. Marechal]

La Java Bleue, j'aimais bien, surtout chantée par Fréhel, pour les reste...

[_skip]

Que pensez-vous de l’évolution de Java ?

Sur le plan du langage, elle a été lente mais globalement assez positive même si je fais partie des gens qui en attendaient un peu plus. Sur le plan spécifications/framework en revanche y'a vraiment eu de tout : les EJB2, JDO, JSF (<= ratage totalement inexcusable), heureusement que de nombreuses solutions tierces sont venues boucher les trous. Le client lourd a été abandonné, Swing et le projet swinglabs n'ont pas reçu l'attention nécessaire, puis l'épisode JavaFX qui devait marquer le tournant s'est avéré à la limite du foutage de gueule.

Plus sur la question langage, et sans ignorer les services que ça rend, on a la sacro sainte rétro-compatibilité qui empêche certaines évolutions. Parfois je me suis demandé si un moment ou à un autre on aurait pas profité d'un Java2 incompatible, mais lorsque je vois ce qui s'est passé avec python 2 et 3, il y a pas de réponse facile. Peut être que grâce aux build system sophistiqués qu'on utilise un peu partout et au bytecode, on aurait pu envisager de mixer du java1 et du java2 comme on le fait pour d'autres langages visant la JVM, mais dans tous les cas ça aurait été une entreprise périlleuse.

L'acquisition de Java par Oracle a-t-elle été une bonne chose pour le langage ?

Ce n'est peut être pas parfait sur le plan philosophique, mais au moins ça avance car la situation d'avant était totalement bloquée, on peut se rappeler de l'épisode Java7 pour s'en persuader.

[elijah509]

puis l'épisode JavaFX qui devait marquer le tournant s'est avéré à la limite du foutage de gueule.

Salut, pourquoi dis tu cela ?

[_skip]

Salut, pourquoi dis tu cela ?

JavaFX a très très mal commencé malgré des promesses intéressantes, binding bidirectionnel, rendu graphique accéléré, successeur "nécéssaire" de swing et réponse de SUN à l'explosion des RIA, mais les premières versions étaient désastreuses et incomplètes. Et ça a juste mis bien trop de temps avant d'arriver à stade où on pouvait imaginer lui trouver un usage en production. Il y a des gens qui maintiennent que toute la version 1.x était à jeter, la version 2.x totalement incompatible a beaucoup progressé mais faut se rendre à l'évidence : c'est là depuis 2008 maintenant, c'est resté une petite niche et ça ne semble pas sur le point de s'arranger.

Si on avait voulu n'en faire ne serait-ce que le successeur de swing, il aurait fallu 10 fois cet investissement, puis aussi en tant que développeurs qu'on sente qu'il y a du solide derrière.

[elijah509]

JavaFX a très très mal commencé malgré des promesses intéressantes, binding bidirectionnel, rendu graphique accéléré, successeur "nécéssaire" de swing et réponse de SUN à l'explosion des RIA, mais les premières versions étaient désastreuses et incomplètes. Et ça a juste mis bien trop de temps avant d'arriver à stade où on pouvait imaginer lui trouver un usage en production. Il y a des gens qui maintiennent que toute la version 1.x était à jeter, la version 2.x totalement incompatible a beaucoup progressé mais faut se rendre à l'évidence : c'est là depuis 2008 maintenant, c'est resté une petite niche et ça ne semble pas sur le point de s'arranger.

Si on avait voulu n'en faire ne serait-ce que le successeur de swing, il aurait fallu 10 fois cet investissement, puis aussi en tant que développeurs qu'on sente qu'il y a du solide derrière.

Merci pour tes éléments de réponses même si je n'ai rien compris à par peut être le binding et la partie sur les versions. C'est ballot car depuis que JavaFX est devenu l'outil officiel pour la réalisation de fenêtre graphique d'application Java, pour la version Java 8, j'y avais jeté un oeil grâce a une série de video de la chaine youtube : "thenewboston" et ca avait l'air super de mon point de vu "développeur en alternance depuis 2ans" ... en gros je me suis fait berné par le jolie CSS et le Scene Builder

[_skip]

Merci pour tes éléments de réponses même si je n'ai rien compris à par peut être le binding et la partie sur les versions. C'est ballot car depuis que JavaFX est devenu l'outil officiel pour la réalisation de fenêtre graphique d'application Java, pour la version Java 8, j'y avais jeté un oeil grâce a une série de video de la chaine youtube : "thenewboston" et ca avait l'air super de mon point de vu "développeur en alternance depuis 2ans" ... en gros je me suis fait berné par le jolie CSS et le Scene Builder

Super? Ca l'est peut être devenu depuis le temps, mais c'est incontestable que si c'est "super" c'est que ça revient de franchement loin. Je te conseille d'aller demander à Bouye sur le forum javaFX ce qu'il pense de l'usabilité en production de JavaFX pour avoir un avis actualisé plutôt que le mien qui se base sur une expérience assez ancienne. Sinon pour le reste, le fait que c'est sorti initialement dans un état inutilisable au point que tous se demandaient ce que c'était que cette mauvaise plaisanterie de SUN et que c'est resté un truc de niche après 7 ans d'existence, tout est vrai.

Quand tu parles de ratage totalement inexcusable, quel est le problème selon toi pour JSF ?

Là tu me pousses au troll ;-)
Le problème d'un standard java, soit arriver des années plus tard avec un framework une spécification largement inférieure à l'existant et pour seul argument le drapeau "it's a standard". J'arrive pas à imaginer que SUN se soit pointé avec cette chose en osant l'annoncer comme concurrent de ASP.net. JSF1 n'avait pas que son retard à déplorer, sa relation amour-haine avec JSP ou encore ses descripteurs en XML. Mais également sa complexité totalement surréaliste, tu ne trouvais pas un tutoriel de moins de 17 pages pour concevoir une simple application hello world avec 3 views et 2 formulaires. Tu voulais implémenter une identification login password avec des pages protégées? Fallait pour cela comprendre en détail les phaseListener et écrire du code de niveau gourou au point qu'on voyait recommander aux gens d'employer Spring Security (rien que ça!) ou des Filters Servlets. Envie de faire de la composition de page pour réutiliser ton layout entre les pages? Pas de bol ce n'est pas prévu, fallait attendre Facelets pour pouvoir faire ça. Ecrire des composants, avec des fonctionnalités ajax? Houla! Laisse ça aux experts.

En fait toutes les choses basiques étaient difficiles, à l'époque nous avons utilisé iceFaces pour éviter d'avoir à écrire trop de composants nous-mêmes car comme si ça suffisait pas, la palette de composants était super pauvre. On a fini par tout foutre à la poubelle et passer à Wicket parce lorsqu'on a compris que ça avait beau être standard, c'était indémerdable, on passait plus de temps sur les forums à chercher des solutions qu'à développer l'application, pour des besoins très simples on se perdait dans des considérations techniques dont on aurait jamais imaginé devoir se préoccuper. J'ai jamais de ma vie autant haï une techno web.

Tiens si t'en veux d'autres de ces récits de haine pure. Ca me vaudra peut être des votes négatifs, mais je persiste et signe que JSF était une dégueulasserie, que c'était jamais à la hauteur de ce qui se faisait à l'époque et même avant (Struts quelqu'un?). Jamais je n'ai vu quelque chose d'aussi complexe, incapable de résoudre le moindre problème récurrent du développement web (réutilisation de composants, composition de page, etc...) sans s'arracher les cheveux ou recourir à des extensions tierces.

[OButterlin]

Sur le plan spécifications/framework en revanche y'a vraiment eu de tout : les EJB2, JDO, JSF (<= ratage totalement inexcusable)

Quand tu parles de ratage totalement inexcusable, quel est le problème selon toi pour JSF ?

[JCB001]

Pour résumer ma pensée :
Java beau succès dans le monde du web avec tout un écosystème autour (Spring et autres)
Succès dans le monde mobile (Android)
Mais mauvais en application client lourd, quelle application grand publique est elle programmée en java ? aucun navigateur web par exemple. Ce serait bien si ça pouvait changer mais cela ne semble pas une priorité d'Oracle et le projet Swing de Sun n'a pas fait beaucoup d'émules.
(Je ne connais qu'une exception à un client lourd Java important : Eclipse)

=> OK avec Logan Mauzaize : Minecraft... si on peut dire que c'est une référence si on considère le nombre de joueurs

[Logan Mauzaize]

Clients lourds en Java : les RCP (Eclipse, Netbeans, la plupart des produits JetBrains), Sweet Home 3D (dont la réalisation est en partie présentée dans le livre "Les Cahiers du programmeur - Swing"), Minecraft (bon ok c'est peut-être pas une référence ), Client Lotus Notes (pas forcément une référence non plus ...), une grande partie des interfaces des box/TV (et autres "smart appliance").

Après je ne sais pas s'il y a des produits très connus basés sur JMonkeyEngine ou libGDX.

Java sait se faire oublier et les entreprises communiquent peu (pour des raisons de sécurité ?) sur les solutions technologiques qu'elles utilisent.

[Tr0n33]

Personnellement je code en Java depuis 1999 et je dirais que l'évolution est très positive et que malgré la peur du rachat par Oracle, leur boulot va dans le bon sens sur le langage (et je dis bien uniquement sur le langage). Ils restent encore quelques petits soucis (Je ne sais pas s'ils ont corrigés le problème de la création d'un Pattern Proxy avec l'usage des implémentations par défaut des interfaces qui fait qu'il existe un léger souci d'encapsulation). Bien que n'ayant pas codé depuis quelques mois, je dois avouer que j'avais été très enthousiaste sur les lambda et les streams. Un gain de temps et de lisibilité intéressant.

Pour l'ensemble des normes, standards, bibliothèques, implémentations, je ne rentrerais pas dans les polémiques. Globalement le travail est là, et je suis plutôt optimiste même sur les problématiques d'API propriétaire.

PS : Juste une ou deux pour la route.
- Pourquoi diantre fournir une implémentation par défaut de CDI typique dans Java SE ? Je me trompe (c'est possible), mais c'est du standard Java EE et donc le container de gestion du contexte applicatif dépend aussi de son traitement par le serveur d'application. Pourquoi diantre fournir une implémentation d'EE dans SE ?
- JSF, je valide, c'est dégueulasse (et sans arguments ! Ils ont déjà été évoqués).

[Gugelhupf]

- Pourquoi diantre fournir une implémentation par défaut de CDI typique dans Java SE ? Je me trompe (c'est possible), mais c'est du standard Java EE et donc le container de gestion du contexte applicatif dépend aussi de son traitement par le serveur d'application. Pourquoi diantre fournir une implémentation d'EE dans SE ?

Pourquoi diantre mettre la généricité dans un langage alors qu'on peut utiliser Object, pourquoi diantre mettre des annotations alors qu'on peut utiliser des fichiers XML ou utiliser des commentaires comme en PHP etc... le DI est concept assez pratique (ex: éviter le pattern Singleton) et comme Java est un langage de haut niveau je ne vois pas ce qui pourrait empêcher l'ajout d'un tel container pour gérer le DI.

- JSF, je valide, c'est dégueulasse (et sans arguments ! Ils ont déjà été évoqués).

C'est "dégueulasse" si on ne le connait pas, qu'on est trop habitué aux papi-frameworks orienté action comme Struts ou Spring.

[Tr0n33]

Pourquoi diantre mettre la généricité dans un langage alors qu'on peut utiliser Object, pourquoi diantre mettre des annotations alors qu'on peut utiliser des fichiers XML ou utiliser des commentaires comme en PHP etc... le DI est concept assez pratique (ex: éviter le pattern Singleton) et comme Java est un langage de haut niveau je ne vois pas ce qui pourrait empêcher l'ajout d'un tel container pour gérer le DI.

Je vous renvoie au pourquoi du principe de la généricité qui sert à mettre en oeuvre des subtilités sur l'accessibilité d'une interface ou de l'encapsulation. C'est un "plus" qui permet d'affiner des API justement pour respecter une certaine forme de standards. Les arguments sont légions sur le sujet. Mettre "Object" c'est autorisé tout et n'importe quoi : vous avez le droit de le faire, mais je ne vois pas en quoi l'ajout de concepts pour d'autres besoins vous dérange. De même pour les annotations, elles ne se limitent pas à une alternative du XML. Elles permettent des traitements intéressants à la compilation ou à l'exécution (les annotations processor qui permettent de générer du code sont plus intéressant que d'utiliser des programmes de génération à partir du XML). C'est une alternative qui est utile dans certains cas pour remplacer le XML (comme tout, il ne faut pas coller une adresse ip d'un environnement dans une méta donnée cantonné au code...).

Bref le débat n'est pas là. Je comprends votre besoin, et le besoin générale depuis la JSR 330. La volonté d'introduire l'injection de dépendance dans Java SE : ok. Et c'est fait sous la forme d'une API. Ce n'est pas au langage de décider de l'orientation prise par l'applicatif. L'API ne doit juste que garantir tout type de pojo est bien injecté, que c'est type safety, ouvert à l'aspect et tutti quanti. Pourquoi diable, devraient ils fournir une implémentation qui par essence deviendrait un standard puisqu'inclus dans Java "SE". Ce n'est pas l'objectif de Java SE. De même chaque contexte applicatif est propre à une application, le cycle de vie est propre aux variables. En quoi la standard devrait inclure une implémentation d'un container ? C'est le sens que vous mettez derrière que je ne comprends pas. Je suis parfaitement ouvert à la discussion sur ce sujet. Mais justement, je trouve que le langage Java a réussi à ne pas dévier de la volonté de mise en oeuvre des standards en 20 ans.

C'est "dégueulasse" si on ne le connait pas, qu'on est trop habitué aux papi-frameworks orienté action comme Struts ou Spring.

Comparons ce qui est comparable : JSF, GWT et AngularJS. Struts c'était bien en 2005, aujourd'hui, trollons un peu, c'est aussi dégueulasse.

Quant à réduire Spring à un papi-framework orienté action... Là. Je reste bouche bée.

Et pour finir je poserais une simple question, pourquoi Richfaces et Primefaces si JSF était si bien. Pour une framework orienté view-controller (et non pas action-controller), il est étonnant de devoir avoir de gentilles contributions pour des manques qui sont fondamentaux sur les vues. La confusion ferait limite penser à un troll

[Gugelhupf]

J'espère que tu ne m'as pas pris au sérieux lorsque j'ai "remis en cause" l'introduction de la généricité et des annotations en Java, c'était à prendre avec humour
Si ces deux concepts sont des "plus", le DI lui aussi est un plus non négligeable.

Comparons ce qui est comparable : JSF, GWT et AngularJS.

Ces 3 frameworks n'ont rien à voir. GWT c'est du AWT/Swing-like pour le web, AngularJS c'est du JavaScript. Par contre si tu prends l'exemple les frameworks RoR, Symfony, Struts, Spring c'est toujours le même schéma...

Quant à réduire Spring à un papi-framework orienté action... Là. Je reste bouche bée.

Oui, c'est parce que tu fais certainement du Spring et que tu aimes ton framework, mais si on regarde les dernières versions de la spécification JSP/Servlet, observe-t-on une grosse différence entre les deux ? Que peux-t-on faire de plus avec Spring qu'on ne peut pas avec les Servlet/JSP (peut-être à part la validation de formulaire et le DI).

Et pour finir je poserais une simple question, pourquoi Richfaces et Primefaces si JSF était si bien.

Parce que Richfaces et Primefaces sont des briques pour de la visualisation (courbes, barres, cercles etc). JSF c'est la Facelet qui injecte les attributs (avec potentiellement des annotations de contrainte de validation) du controller ayant lui-même son propre scope (Requête, Session etc). Concept compliqué à comprendre au début lorsqu'on est trop habitué aux outils traditionnels, mais d'une grande simplicité et efficacité par la suite.

[Tr0n33]

J'espère que tu ne m'as pas pris au sérieux lorsque j'ai "remis en cause" l'introduction de la généricité et des annotations en Java, c'était à prendre avec humour
Si ces deux concepts sont des "plus", le DI lui aussi est un plus non négligeable.

Mea culpa alors, je l'ai pris sans humour pour le coup

Ces 3 frameworks n'ont rien à voir. GWT c'est du AWT/Swing-like pour le web, AngularJS c'est du JavaScript. Par contre si tu prends l'exemple les frameworks RoR, Symfony, Struts, Spring c'est toujours le même schéma...

Oui et non. C'est totalement subjectif et discutable. Pour reprendre juste l'exemple de Spring car il a l'air de vous tenir à coeur, Spring Dynamic Module et DM Server ont une approche par composant (avec quelques difficultés sur l'environnement d'exécution). Les facelets sont une implémentation que je trouve moyenne par rapport aux nouveaux apports de certains frameworks dans le domaine. Spring n'est pas du tout qu'orienté "action" et justement grâce à son modèle de programmation orienté "aspect".

Oui, c'est parce que tu fais certainement du Spring et que tu aimes ton framework

Hum... Non. Je pars du principe d'utilisation d'un framework en fonction des besoins, des contraintes métiers et des contraintes clientes. Je n'ai aucun amour particulier pour Spring d'ailleurs (je ne vois pas pourquoi vous me ressortez en double cette argument). Je n'ai rien contre les technologies, je me fais juste mon opinion à l'utilisation. Et ce n'est pas parce que je dis que JSF est immonde, que Spring est le paradis ou l'apothéose des frameworks. Je suis tout aussi critique à l'égard de la nécessité constante de customiser l'ensemble des éléments fournis par défaut dans Spring.

mais si on regarde les dernières versions de la spécification JSP/Servlet, observe-t-on une grosse différence entre les deux ?Que peux-t-on faire de plus avec Spring qu'on ne peut pas avec les Servlet/JSP (peut-être à part la validation de formulaire et le DI).

- Gestion des transactions.
- AOP.
- Intégration générale (JMS, Webservice etc).
- D'autres modules spécifiques à JCA, JMX...

L'objectif n'est pas prouver quoi que ce soit sur Spring ou d'autres frameworks. Je vous ai dit dès le début que mon avis était purement subjectif sur JSF

Parce que Richfaces et Primefaces sont des briques pour de la visualisation (courbes, barres, cercles etc). JSF c'est la Facelet qui injecte les attributs (avec potentiellement des annotations de contrainte de validation) du controller ayant lui-même son propre scope (Requête, Session etc). Concept compliqué à comprendre au début lorsqu'on est trop habitué aux outils traditionnels, mais d'une grande simplicité et efficacité par la suite.

Je connais le principe et c'est bien pour cela que de mon point de vue, JSF n'a rien de "novateur" dans le domaine. Il reprend une part des principes du monde .NET (avec un décalage de technologie important) et ne fait pas beaucoup mieux que certains outils du monde Java. Ca n'a rien à voir avec une habitude aux outils traditionnels. D'ailleurs, JSF est en lui même très traditionnel si l'on connaît le monde .NET.

Bref, ça n'a plus trop à voir avec le débat. Si vous souhaitez continuer, je suis toujours ouvert à la discussion en privée (je ne répondrais plus pour ne pas polluer plus ce sujet).

A+