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

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

[_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]

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

[_skip]

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.

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

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.

[adiGuba]

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

[OButterlin]

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

[Gugelhupf]

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.

[Logan Mauzaize]

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.

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

[OButterlin]

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)

[Logan Mauzaize]

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.

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.

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 ?

[_skip]

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.

[OButterlin]

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)