Discussion :

[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+