Java a 20 ans

Version imprimable

23/05/2015, 21h52
Hinault Romaric

Java a 20 ans

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.

http://www.developpez.com/public/images/news/java20.jpg

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.

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

Et vous ?

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

:fleche: L'acquisition de Java par Oracle a-t-elle été une bonne chose pour le langage ?
23/05/2015, 23h30
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é.
25/05/2015, 14h47
Ph. Marechal

La Java Bleue, j'aimais bien, surtout chantée par Fréhel, pour les reste... :roll:
27/05/2015, 10h21
_skip

Citation:

Envoyé par Hinault Romaric

:fleche: 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.

Citation:

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.
27/05/2015, 19h31
elijah509

Citation:

Envoyé par _skip

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

Salut, pourquoi dis tu cela ?
28/05/2015, 08h20
_skip

Citation:

Envoyé par elijah509

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.
28/05/2015, 09h07
elijah509

Citation:

Envoyé par _skip

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 :roll:
28/05/2015, 10h33
OButterlin

Citation:

Envoyé par _skip

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 ?
28/05/2015, 12h26
_skip

Citation:

Envoyé par elijah509

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 :roll:

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.

Citation:

Envoyé par OButterlin

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.
28/05/2015, 14h10
OButterlin

Non, pas de troll, c'était pour avoir la raison du commentaire ;)

Historiquement, je suis d'accord avec toi, avant la version 2, l'intérêt était... inexistant... surtout qu'un assemblage struts1 / struts-layout / tiles fonctionne super bien...

Depuis la version 2, je dirais que ça s'arrange bien, même si j'hallucine de voir qu'il y a toujours des problèmes avec les scopes (surtout avec du binding de composants) 8O
Ce qui est certain, c'est que si on faisait un rapport emmerdements/fonctionnalités, ça ne volerait peut-être pas bien haut...
Et pourtant, j'aime bien le couple JSF2/Primefaces pour faire des applications RIA, mais ça ne correspond pas à tous les développements web.
S'il y avait une contrainte importante au niveau des utilisateurs connectés simultanément, ce ne serait pas vraiment ma solution privilégiée :mrgreen:
28/05/2015, 15h32
_skip

Citation:

Envoyé par OButterlin

Non, pas de troll, c'était pour avoir la raison du commentaire ;)
Historiquement, je suis d'accord avec toi, avant la version 2, l'intérêt était... inexistant... surtout qu'un assemblage struts1 / struts-layout / tiles fonctionne super bien...

Surtout que ce qui me dégoûte, c'est qu'ils n'étaient pas pionniers dans ce milieu. Il existait déjà des frameworks assez réussis desquels ils auraient pu s'inspirer dans le monde Java. Ou même reprendre les bons points d'ASP.net qui était une recette de framework par composant plutôt correcte? Mais non ils sortent cette horreur qui place le technique avant le fonctionnel et qui reprend tout le cake qui rendait java notorieusement complexe à mettre en oeuvre (Servlets, JSP) pour les sites web, je dis pas que java avait vocation à devenir RubyOnRails mais quand même.

Citation:

Depuis la version 2, je dirais que ça s'arrange bien, même si j'hallucine de voir qu'il y a toujours des problèmes avec les scopes (surtout avec du binding de composants) 8O
Ce qui est certain, c'est que si on faisait un rapport emmerdements/fonctionnalités, ça ne volerait peut-être pas bien haut...
Et pourtant, j'aime bien le couple JSF2/Primefaces pour faire des applications RIA, mais ça ne correspond pas à tous les développements web.
S'il y avait une contrainte importante au niveau des utilisateurs connectés simultanément, ce ne serait pas vraiment ma solution privilégiée :mrgreen:

On a eu la même chose avec JPA, les premières versions c'était l'intersection entre hibernate et toplink. JavaFX mentionné plus haut pareil, inutile avant sa version 2 (et ça correspond à plusieurs années d'attente hein). J'aurai personnellement toujours préféré que SUN ou Oracle restent en dehors du monde du framework et s'occupent plus du langage.

Pour ce qui est de JSF2 et Primefaces, je suis un peu revenu de l'approche par composant. Après avoir essayé tour à tour JSF, Gwt, Vaadin j'ai l'impression que si ces solutions ont le mérite d'épargner de bonnes doses de javascript, elles me laissent toujours le sentiment de faire à peu près ce que tu cherches mais jamais exactement ce que tu veux. Pour cela je suis revenu à du Play/Grails, TypeScript et Angular pour mes RIA, plus de couches à gérer mais au moins je maîtrise mieux ce que ça fait et ce que ça ne fait pas.
28/05/2015, 19h28
adiGuba

Citation:

Envoyé par _skip

J'aurai personnellement toujours préféré que SUN ou Oracle restent en dehors du monde du framework et s'occupent plus du langage.

Gros +1

Pour les frameworks et autres il y a déjà plein de solution existantes, qui évoluent sans cesses.
Inutile de définir des "standards officiel" imbitable quand il y a déjà des solutions "standard de fait"...

Les deux gros principaux points pour moi c'est l'évolution du langage (vivement les values-type du projet valhalla, même si ce n'est pas pour tout de suite), et de l'API de base qui a quelques lacunes et quelques trucs un peu obsolètes (HttpURLConnection pas très pratique, pas de support de JSON, et certaines API qui pourraient encore bénéficier des Generics/enum/lambda)

a++
29/05/2015, 09h48
OButterlin

Citation:

Envoyé par _skip

Pour ce qui est de JSF2 et Primefaces, je suis un peu revenu de l'approche par composant. Après avoir essayé tour à tour JSF, Gwt, Vaadin j'ai l'impression que si ces solutions ont le mérite d'épargner de bonnes doses de javascript, elles me laissent toujours le sentiment de faire à peu près ce que tu cherches mais jamais exactement ce que tu veux. Pour cela je suis revenu à du Play/Grails, TypeScript et Angular pour mes RIA, plus de couches à gérer mais au moins je maîtrise mieux ce que ça fait et ce que ça ne fait pas.

C'est vrai pour tous ces outils, plutôt que de vouloir faire un outil qui couvre tous les aspects du développement, il serait préférable d'avoir un bon socle et d'utiliser des briques de bases bien faites.
On est en pleine régression, avec des développeurs qui ne veulent plus qu'avoir à maitriser un seul langage...
01/06/2015, 14h09
Gugelhupf

Citation:

Envoyé par adiGuba

vivement les values-type du projet valhalla

S'ils pouvaient intégrer un container CDI dans la JVM pour qu'on puisse faire de l'injection de dépendance sans passer par une couche comme Spring dans les applications Java SE là ce serait vraiment topissime.

Je ne sais pas vous mais je trouve que le framework JSF2 est vraiment cool sur le principe, après je ne dis pas que c'est "parfait" car la génération de la vue (Facelet) est entièrement laissée au framework, mais le fait d'injecter des beans avec un scope spécifique dans la vue c'est juste énorme, ça simplifie tellement de choses, j'ai l'impression que les autres frameworks (comme Symfony2 en PHP par exemple) remontent à l'époque de Struts d'il y a 15 ans.
01/06/2015, 14h55
Logan Mauzaize

Citation:

Envoyé par Gugelhupf

S'ils pouvaient intégrer un container CDI dans la JVM pour qu'on puisse faire de l'injection de dépendance sans passer par une couche comme Spring dans les applications Java SE là ce serait vraiment topissime.

Comme dit précédemment à quoi bon dessiner un standard s'il y a déjà des bibliothèques pour faire le travail ?
Quelle différence d'avoir un JAR supplémentaire dans ton appli ou des packages supplémentaires dans ton JRE ?

Sinon il y a déjà un standard pour CDI, d'ailleurs Spring l'implémente. Et si Spring te convient pas, il en existe d'autres : Dagger, Guice, Weld, etc.
01/06/2015, 15h58
Gugelhupf
Je connais un peu Spring IoC pour l'avoir expérimenté, ce qui ne me convient pas :
1. JAR hell
2. L'utilisation d'un fichier XML pour définir le scope des packages où le DI est présent
3. Avoir un 1er point d'entrée pour récupérer un bean contenant une DI (cf: ApplicationContext) pour ensuite pouvoir utiliser les autres classes avec DI.
01/06/2015, 15h59
OButterlin

Citation:

Envoyé par Logan Mauzaize

Comme dit précédemment à quoi bon dessiner un standard s'il y a déjà des bibliothèques pour faire le travail ?
Quelle différence d'avoir un JAR supplémentaire dans ton appli ou des packages supplémentaires dans ton JRE ?

Sinon il y a déjà un standard pour CDI, d'ailleurs Spring l'implémente. Et si Spring te convient pas, il en existe d'autres : Dagger, Guice, Weld, etc.

S'il n'y a pas UN standard, il n'y a presque aucune chance de fédérer les développeurs sur une façon de faire.
Personnellement, je suis pour les standards, et qu'ils se basent de préférence sur ce qu'il y a de meilleur au moment de le faire (comme JPA par exemple qui s'est appuyé largement sur Hibernate)
01/06/2015, 16h20
Logan Mauzaize
Citation:
Envoyé par Gugelhupf

Je connais un peu Spring IoC pour l'avoir expérimenté, ce qui ne me convient pas :

JAR hell
L'utilisation d'un fichier XML pour définir le scope des packages où le DI est présent
Avoir un 1er point d'entrée pour récupérer un bean contenant une DI (cf: ApplicationContext) pour ensuite pouvoir utiliser les autres classes avec DI.
Je dirai Spring 4 (même si Java Config a été introduit avec Spring 3).
Pour ce qui est JAR hell, va falloir arrêté de faire du Java alors ^^ Sinon les systèmes de gestion de dépendance (Maven, Ivy, Gradle, etc.) aide bien.

Citation:

Envoyé par OButterlin

S'il n'y a pas UN standard, il n'y a presque aucune chance de fédérer les développeurs sur une façon de faire.
Personnellement, je suis pour les standards, et qu'ils se basent de préférence sur ce qu'il y a de meilleur au moment de le faire (comme JPA par exemple qui s'est appuyé largement sur Hibernate)

C'est un débat très houleux et je suis tout à fait conscient des intérêts d'une approche "standard". En revanche, il faut clairement avoir besoin des avantages de cette approche !
J'ai jamais vu un projet qui n'utilise pas une annotation/configuration spécifique à Hibernate/EclipseLink. Et c'est bien le problème du standard, il essaye de fédérer et de prendre le minimum commun, sacrifiant ainsi les fonctionnalités les plus fines et les plus puissantes. Celles qui font vraiment la différence.
Après c'est aussi la politique choisie pour réaliser le standard à partir de l'existant qui peut être remis en cause. Doit-on prendre le minimum commun pour avoir une adoption rapide ou prendre un ensemble plus grand pour forcer les APIs existantes à offrir le meilleur ?
02/06/2015, 07h42
_skip

Citation:

Envoyé par OButterlin

S'il n'y a pas UN standard, il n'y a presque aucune chance de fédérer les développeurs sur une façon de faire.
Personnellement, je suis pour les standards, et qu'ils se basent de préférence sur ce qu'il y a de meilleur au moment de le faire (comme JPA par exemple qui s'est appuyé largement sur Hibernate)

Plus mitigé ici...
Je trouve que ça fait du sens de standardiser les briques communes, comme les API Xml (même si ça aurait pu être beaucoup mieux fait que ça), les servlets, JDBC et, dans le futur, Json. Par contre, prendre un framework complet et le spécifier ça pose certains problèmes. Pour commencer le fait que c'est un choix d'opinion et que les membres du JCP peuvent faire le mauvais choix, voire être tentés de voter une techno en standard juste pour sécuriser leurs propres investissements. Ensuite, face à l'existant il y a de bonnes chances que l'existant gagne comme le dit Logan, souvent on prend l'intersection de plusieurs frameworks comme on l'a fait avec Hibernate et Toplink pour faire JPA et ça donne une solution en demi-teinte où on peine à ne pas recourir à un moment ou à un autre à des spécificités de l'implémentation. La nécessité par ailleurs de fournir soi-même les JAR (pour Jpa, JSR303) finit d'achever totalement le concept.

C'est devenu difficile de figer un framework pour plusieurs années, on voit bien que les projets open source en bonne santé reçoivent beaucoup d'updates, voire plusieurs versions majeurs dans un laps de temps qui correspond à un seul cycle d'évolution java. Par ailleurs, contrairement au monde Dotnet, ça n'a jamais empêché la "jungle des frameworks". Du côté des standards qui font ou auraient fait du sens selon moi, il y aurait un système de configuration avancé style typesafe-config ou le yaml utilisé par Spring, Joda time (super c'est là e 8), OSGI s'il n'y avait pas eu Jigsaw et éventuellement de meilleurs processeurs d'annotations.
02/06/2015, 08h33
OButterlin

Citation:

Envoyé par Logan Mauzaize

J'ai jamais vu un projet qui n'utilise pas une annotation/configuration spécifique à Hibernate/EclipseLink. Et c'est bien le problème du standard, il essaye de fédérer et de prendre le minimum commun, sacrifiant ainsi les fonctionnalités les plus fines et les plus puissantes. Celles qui font vraiment la différence.

99,9% de nos projets n'utilisent aucune annotation spécifique, et encore, on aurait put s'en sortir en modifiant la paramétrage du serveur (il s'agit juste pour 2 programmes lourds d'augmenter la durée de la transaction)
02/06/2015, 15h06
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
02/06/2015, 16h11
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 :D), 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.
16/06/2015, 11h36
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).
17/06/2015, 10h19
Gugelhupf

Citation:

Envoyé par Tr0n33

- 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.

Citation:

Envoyé par Tr0n33

- 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.
17/06/2015, 11h22
Tr0n33

Citation:

Envoyé par Gugelhupf

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.

Citation:

Envoyé par Gugelhupf

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 :aie:
17/06/2015, 12h46
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 :roll:
Si ces deux concepts sont des "plus", le DI lui aussi est un plus non négligeable.

Citation:

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...

Citation:

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).

Citation:

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.
17/06/2015, 15h12
Tr0n33

Citation:

Envoyé par 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 :roll:
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 :)

Citation:

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".

Citation:

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.

Citation:

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 :aie:

Citation:

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+