Discussion :

[Idelways]

Java est-il un choix coûteux pour les entreprises ?
Oui, d'après un expert qui recommande de capitaliser à bon escient sur les briques open-source




Quinze ans après l’émergence de Java, David Duquenne, Directeur Génétal du groupe Open Wide Technologies (spécialiste de l'intégration et des l'exploitation des logiciels en France) fait un bilan du langage, qu'il trouve plutôt mitigé.
Un avis plutôt polémique.

Selon lui, Java n'aurait pas tenu ses promesses. Les projets réalisés à l'aide de ce langage auraient la réputation d'être « trop subtils pour les développeurs (sic), coûteux à réaliser et complexes à maintenir».

Le point de vue des Directions des Systèmes d'Information (DSI) serait, pour David Duquenne, sans appel : « prise en main longue et compliquée », « des compétences et une expertise coûteuses », des « architectes apprentis sorciers », un « écosystème technologique étourdissant ».

Bref, un constat qui ferait d'après lui regretter aux DSI les « bons vieux langages [...] complètement dépassés dans certains domaines, mais tellement plus productifs » et les pousserait à expérimenter des langages plus récents ou à explorer de nouveaux paradigmes tels que l'approche par modélisation (MDA) ou la programmation fonctionnelle dédiée.

Des solutions cependant pas suffisamment matures, toujours selon l'analyste, pour être industrialisées sur des projets stratégiques.

Sa solution ? Capitaliser sur des briques open-source proposant des réponses aux problématiques les plus courantes dans le développement d'applications.

« À condition toutefois d'éviter certains écueils » met en garde Duquenne, qui propose des conseils pour faire face aux défis de l'intégration Java comme la gestion du foisonnement de l'Open Source, la versatilité des composants, l'exploitation de la richesse ou l'évacuation de la complexité.

Les DSI qui préfèrent miser sur l'existant plutôt que d'investir dans leur propre « framework maison » seront ainsi confrontés à l’embarras du choix entre les milliers frameworks techniques Java et les dizaines de milliers de modules fonctionnels open source.

Leur but serait d'aboutir à un socle applicatif de qualité industrielle.

Ce socle souhaité par David Duquenne peut être créé avec des composants sélectionnés et être l'assemblage des interactions d'interfaces de programmation hétérogènes. Une phase coûteuse qui risque de durer entre 3 à 18 mois pour le développements techniques et nécessiter une équipe de 3 à 10 experts.

Autre solution, les entreprises peuvent s'essayer aux socles applicatifs fournis clef en main, qui peuvent être adaptés au contexte spécifique des projets de l'entreprise. Ces socles sont des distributions de composants Open Source intégrées dans une architecture applicative couvrant un périmètre plus ou moins important.

Les DSI doivent selon David Duquenne s'assurer de l'existence d'un support professionnel sur la totalité du socle applicatif afin de sécuriser la réalisation, la maintenance et l'exploitation des applications les plus critiques.

Le coût de ce support, mutualisé entre les entreprises utilisatrices du socle « restera plus économique que la maintenance d’un socle applicatif maison », affirme-t-il.

Le deuxième challenge serait de maintenir ce socle pour les 5, 10 ou 15 prochaines années au milieu d'un écosystème Java en constante évolution.

Cette évolution permet aux composants de devenir constamment plus pertinents et plus robustes et motiver l'apparition de nouveaux composants encore plus performants et innovants. Mais mal gérée, cette évolution peut aussi générer une versatilité désastreuses pour les systèmes d'information.

De plus, le rythme de ces évolutions est imprévisible et diffère pour chaque composant du socle applicatif.

Un composant peut aussi être abandonné, mais rester accessible sur Internet, devenant une sorte de bombe à retardement pour les applications. Ces composants doivent être en permanence remplacés ou maintenus par la société elle-même.

Duquenne met également en garde contre les ruptures technologiques introduites par une évolution majeure ou par le changement brutal d'une licence.

Pour se prémunir, le seul moyen serait d'anticiper ces risques par une veille technologique permanente et sensibiliser les directions sur les coûts (souvent mal vécus) de cette activité de veille sans rapport avec les enrichissements fonctionnels et métiers attendus par l’entreprise.

Un autre challenge, encore plus délicat selon Duquenne, est de survivre au départ de l'architecte, souvent un prestataire de haut vol intervenant de façon limitée, le temps de stabiliser ce socle applicatif.

Les bons architectes sont souvent difficiles à retenir dans la durée, car ils puisent leurs motivations dans la résolution de nouveaux challenges techniques leur permettant d’améliorer leur expertise.

Ce départ doit donc être anticipé en organisant un transfert de compétences au sein d’un contrat de maintien en condition opérationnel pour éviter la perte de la maîtrise du socle, ou pire encore, le désengagement technique des partenaires qui ne voudront plus travailler sur une plate-forme obsolète ou non supportée

La verbosité qui fait de Java un langage très structurant (garantissant la qualité et la portabilité des applications) rebute souvent les développeurs expérimentés sur d'autres langages et complique le recrutement et les budgets.

Duquenne recommande des solutions qui peuvent évacuer la complexité du Java et de son environnement comme le cadrage structurant les méthodes de développement, l’utilisation de Frameworks, l'intégration continue ou encore le recours aux approches agiles de gestion de projet favorisant les échanges d'informations et limitant la dépendance aux personnes clefs du projet.

Pour se faire, des socles applicatifs communautaires peuvent compléter les plates-formes avec une surcouche simplifiant le codage des applications, des générateurs de code et un cadre méthodologique.



Le discours de David Duquenne n'est cependant pas un plaidoyer anti-Java, au contraire :

« La complexité du monde Java est réelle mais ses qualités, son ouverture et sa standardisation poussent à son adoption malgré les difficultés à bâtir et à maintenir son environnement technologique », conclue-t-il. « Pour bénéficier des avantages de cet environnement, particulièrement bien adapté aux technologies de l'information, il est indispensable de capitaliser sur le savoir-faire et les retours d’expérience des composants Open Source qui le peuplent. Au delà de l’économie d’échelle induite par l’approche communautaire, celle-ci vous permet de bénéficier d’une constante évolution gage de fiabilité, d’interopérabilité et de respect des derniers standards […] L'émergence d'éditeurs Open Source dans ce domaine est un signe encourageant de la maturité des socles applicatifs et une réponse adaptée aux DSI qui souhaitent investir sur leur métier plutôt que sur la technologie qui les sous-tend ».

Source : Communiqué de presse : Open Wide Technologies

Et vous ?

Qu'en pensez-vous ?

[CAML]

C'est pas parce que des personnes n'utilisent pas les "bonnes méthodes" que l'outil est mauvais.
Cet article revient à dire : y a pas de mauvais language, mais des mauvais programmeurs/analyste/etc...

[Gog077]

De toute manière le langage parfait adapté à toutes les situations n'existe pas. Je ne pense pas que ce soit un problème de Java ou pas. On pourrait faire le même discours sur le C# ou d'autres langages encore.

[willard]

Java couteux ? Je ne dirais pas ça .. c'est peut etre un langage trop verbeux mais je trouve que c'est ce qui fait sa force. Investir la dedans est clairement plus rentable que d'investir dans un langage bas niveau ou pire dans un autee paradigme.

[BugFactory]

Je ne vois pas ce que l'article de M. Duquenne apporte de neuf. Les atouts et travers de Java qu'il dénonce sont bien connus.

On va m'accuser de manquer d'impartialité étant donné mon investissement personnel dans Java. Néanmoins, ce même investissement me permet d'affirmer qu'aucune entreprise aujourd'hui ne se lance dans Java sans choisir soigneusement les frameworks à utiliser. Ces frameworks deviennent par la suite le standard de l'entreprise.

Si la majeur partie du texte me semble relever de l'évidence, d'autres me font bondir. Notamment ce qu'il dit sur les socles applicatifs.

Pour réaliser un socle applicatif de qualité industrielle (c-à-d complété par des générateurs de code, une approche méthodologique et un processus structurant de développement), il est raisonnable de prévoir une phase d'une durée de 3 à 18 mois de développements techniques avec une équipe de 3 à 10 experts selon vos besoins : niveau d'intégration dans votre système d'information, simplicité de prise en main par vos développeurs, productivité et qualité attendue pour la réalisation de vos projets, criticité des applications pour votre entreprise…

Très exagéré. A en croire cet extrait, créer un socle applicatif prendrait de 9 à 180 mois hommes! Le pire des cas reviendrait à 15 ans de travail avant même de commencer à programmer l'application elle-même. Hors on peut avoir un socle applicatif décent en assemblant Struts + Swing + Hibernate en quelques jours.

Une fois le socle applicatif terminé et livré, se pose alors la question de sa maintenance pour les 5, 10 ou 15 prochaines années (soit la durée des applications de votre SI).

Manque de clarté. Maintenir les applications réalisées aujourd'hui à l'aide de ce socle applicatif pendant quinze ans : bien sûr. Mais je doute que dans quinze ans, on souhaite commencer de nouvelles applications avec ce même socle.

En revanche, là où je suis entièrement d'accord, c'est sur la nécessité de ne pas devenir trop dépendant de son architecte. Ceci d'une façon très simple : prévoir deux jours pour que l'architecte forme l'équipe, et écrire un dossier d'architecture. Dans la pratique, même dans le cas où l'architecte est encore dans l'entreprise, je constate que l'équipe ne connaît pas l'architecture!

EDIT:
Le paragraphe précédent a été écrit avant même que Rei Ichido n'écrive :

La question réside souvent dans le passage de connaissance, en effet, qui peut être singulièrement allégé si on produit une doc explicite en amont (comprenant aussi des commentaires dans le code). Les basiques, quoi. Et ce n'est pas comme si c'était spécifique à Java.

Comme quoi...

[Traroth2]

Bonjour les évidences ! Miser sur les briques open-source ? Il était temps qu'il découvre ça, en 2011, le gars ! IDE le plus populaire : Eclipse. Conteneur de servlet : Tomcat. Conteneur d'EJB : JBoss. Sans parler de Spring, Hibernate, etc. Et juste après, il parle du problème posé par le foisonnement de briques open-source, justement. Un peu contradictoire, non ?

Personnellement, je pense que ce foisonnement est justement une des très grandes forces de Java, ce qui en fait un langage avec lequel on peut (presque) tout faire ! Et c'est ce qui le rend aussi difficile à remplacer, aussi, comme on le voit maintenant avec les problèmes posés par l'arrivée d'Oracle aux manettes...

[Rei Ichido]

Ce socle souhaité par David Duquenne peut être créé avec des composants sélectionnés et être l'assemblage des interactions d'interfaces de programmation hétérogènes. Une phase coûteuse qui risque de durer entre 3 à 18 mois pour le développements techniques et nécessiter une équipe de 3 à 10 experts.

Il faudrait détailler le "souhaité". L'émergence de beaucoup de frameworks est due aussi à la multiplicité des besoins ; est-ce qu'il propose une solution unique ?

Un autre challenge, encore plus délicat selon Duquenne, est de survivre au départ de l'architecte, souvent un prestataire de haut vol intervenant de façon limitée, le temps de stabiliser ce socle applicatif.

Les bons architectes sont souvent difficiles à retenir dans la durée, car ils puisent leurs motivations dans la résolution de nouveaux challenges techniques leur permettant d’améliorer leur expertise.

Honnêtement, quel techno ne subit pas ce problème récurrent du départ de celui-qui-sait ?

La question réside souvent dans le passage de connaissance, en effet, qui peut être singulièrement allégé si on produit une doc explicite en amont (comprenant aussi des commentaires dans le code). Les basiques, quoi. Et ce n'est pas comme si c'était spécifique à Java.

[Killing Joke]

Je suis plutôt d'accord sur certains constats que ce Monsieur fait, mais pas sur le fond.
Pour les constats, oui, l'écosystème Java est parfois devenu un peu trop riche, trop verbeux, trop redondant (tant de librairies pour un même sujet mais pas une seule bien finie jusqu'au bout, etc.), même si çà dénote une forte implication de beaucoups d'acteurs.

Par contre dire que Java n'est pas productif en entreprise, là je suis scié. Il y a peu, dans ma boîte, on maintenait encore de vieilles applications en C, remplacées aujourd'hui par du J2EE. En terme de maintenance et de déploiement, il n'y a pas photo : les applications en C étaient une plaie niveau compilations, dépendances inter-modules, divergences entre plateformes, links avec les .so système ... tout un tas de sujet sur lesquels on a bien galéré (il y a encore pas si longtemps !), alors qu'on était quand même équipé, et qui ont totalement disparu avec Java (ouf).

[Traroth2]

(tant de librairies pour un même sujet mais pas une seule bien finie jusqu'au bout, etc.)

Ah oui ? Tu connais un seul domaine où des bibliothèques Java sont pléthoriques mais où aucune ne s'est dégagée comme meilleure, bien finie, un genre de standard de fait ? Moi pas.

On pourrait être tenté de répondre "les frameworks web", mais justement, s'ils sont nombreux, beaucoup sont de qualité (Struts, Stripes, Wicket, ZK, DWR...), et il semble clair que JSF et GWT se détachent aujourd'hui du lot...

[Traroth2]

"Il y a deux sortes de langages de programmation : ceux que tout le monde critique et ceux que personne n'utilise", Bjarne Stroustrup

A méditer...

[hwoarang]

J'apporte mon avis de non initié à tous ces frameworks pour dire que c'est vrai qu'il est assez compliqué de s'y retrouver. A force d'entendre parler de ces technos (pour ne prendre qu'un exemple : Struts) j'ai essayé de me renseigner. Résultat : on rentre beaucoup trop vite dans le detail et je trouve qu'il est difficile de se faire une opinion sur l'interet d'utiliser un framework sans y avoir consacré 1 semaine a essayer de comprendre à quoi il sert (pour peut etre se rendre compte qu'il n'est pas adapté à ce qu'on veut faire).

C'est d'ailleurs une idée d'article qui pourrait etre interessant. Essayer de resumer en 5 lignes à quoi sert chaque framework (enfin une liste aussi exhaustive que possible) et dans quel cas il est judicieux de les utiliser.

Pour reprendre l'exemple de Struts, j'ai lu qu'il etait utile pour des projets assez gros, qu'il facilite l'IHM en permettant de créer des fichiers xml qui permettent de definir l'interface attendue et c'est tout ce que j'ai retenu (une fois encore, je n'ai pas pris le temps de chercher des exemples et de bien voir les possibilitées de l'outil).

Mais bon, je ne pense pas que ce probleme soit spécifique à Java. Je fais egalement du developpement web avec .NET et il n'y a qu'à voir le nombre de questions et d'articles concernant le viewstate, par exemple, pour se rendre compte à quel point c'est pas clair dans la tete de beaucoup de monde (et c'est vrai que c'est pas simple). Et comme pour Java, il existe une multitude de composants/addon qui sont pour certains interessants mais il est difficile de savoir avant d'y avoir consacré pas mal de temps s'il sont utiles/adaptés pour l'application en cours de dev...

[tchize_]

Résultat : on rentre beaucoup trop vite dans le detail et je trouve qu'il est difficile de se faire une opinion sur l'interet d'utiliser un framework sans y avoir consacré 1 semaine a essayer de comprendre à quoi il sert (pour peut etre se rendre compte qu'il n'est pas adapté à ce qu'on veut faire).

Un principe que j'ai tendance à appliquer ici, et qui marche pas mal. Je donne au développeur (en fait c'est tout l'équipe qui décide de donner, pas moi) qui propose un techno deux jour ou trois pour prouver par prototype qu'elle peux rentrer dans la base de code et apporter quelque chose. Si c'est plus long, c'est probablement que le gain et ou la courbe d'apprentissage de cette techno n'est pas pour le moment avantageuse. (Il peux très bien retenter de démontrer l'intérer 2 mois plus tard si il estime que la donne a changé). C'est ainsi que dans notre projet actuel spring a eu son ticket d'entrée mais pas CDI/Weld Mais rien ne dit que sur un autre projet, on ne fera pas l'inverse.

[tchize_]

java a souffert, et souffre toujours d'ailleurs, a mon avis d'un gros problème d'architecture. Ho ce n'est pas vraiment le language qui est en cause. Ce sont les architectes. Petit retour en arrière. Retour à l'époque des premiers EJB. La plateforme java, et sun, met en avant les EJB les architecture N-tiers (je déteste ce mot), et commence à sortir des certification du style architecte certifié J2EE. Des gens dont le job est de prendre les besoins du client, l'analyse de l'analyste, si elle existe, et de déterminer que l'application fera autant de couche, et comment on va dialoguer entre toutes ces couches et quelles techno ont va bourrer dedans. Et le résultat, avant même de commencer le codage, a souvent été le même. Les programmeurs héritaient d'un monstre tentaculaire où tout avait été prévu par l'architecte, mais dont la plupart des trucs étaient inutilisable. Ce genre de mentalité a malheureusement amené beaucoup de projet "enterprise" (parce que ce mot fait bien) à se casser la gueule en utilisant des technologies dont ils n'avaient pas besoin. Ainsi, beaucoup de gens à l'époque ont appris à leur dépend, une règle fondamentale avec les premiers EJB: a n'utiliser qu'en cas d'extrême nécessité, tellement c'est lourd

Depuis que sun a pris un tournant en se rendant compte que c'est pas parce qu'elle est "enterprise" qu'une api doit être compliquée et lourde, la plateforme java enterprise, à mes yeux, a vraiment évolué. Pour ceux qui étaient là, la démonstration a été faite à la devoxxx 2010, on peux faire une application de gestion de données, avec ses interfaces JSF son stockage EJB et tout qui fonctionne ensemble, en moins de deux heures


PS: je vais pas faire la comparaison avec .net, puisque je n'ai jamais fait de .net. Je fais du java pour une raison tout conne, je suis dans un environnement avec des mainframe de type unix/linux, donc des applis en .net là, impossible.

[B.AF]

Je trouve cette vision très juste. J'ai bossé sur une appli basée sur EJB 2 et finalement, tout était possible dixit le "technical lead", mais jamais rien ne sortait propre.

Finalement, l'application a fini en client / serveur C++; en 6 mois et est super robuste.

Et la faute n'est certainement pas à Java.

[B.AF]

En même temps tout ça c'est bien vrai. Mais c'est valable pour toutes les technologies.

Le problème de l'architecture, ce sont les profils. Moi quand je lis une personne qui me dit qu'une architecture technique c'est quelques jours en spring/hibernate/strut, je me dis surtout que si Java à introduit une notion, c'est le dogme architectural.
Spring, c'est une des librairies les plus crades du marché, hibernate c'est probablement le framework le plus mal employé de la planéte et qui pose le plus de problèmes de perfs, et strut je ne commente même pas.
Je ne compte plus le nombre de développeur que j'ai vu se prendre les pieds dans le tapis avec la session hibernate, les select n+1, les mappings, les locks de thread sur les singleton spring, les transactions,les jar hell, les fichiers xml partout, ou la submission multiple en strut, la config de strut....

Oui une archi technique même en Java peut prendre du temps et couter cher.
Et il n'y a ni évidence, ni facilité. La plus grande erreur étant celle de prendre des composants open source (pour ne pas payer les outils) en se disant qu'ils font, sans maitriser le sujet qu'ils traitent (pour ne pas payer la formation)

Si les frameworks open source étaient si faciles à mettre en oeuvre et répondaient tant aux besoins fonctionnels, alors beaucoup de boites, dont spring et dont jboss ne gagneraient pas leur vie.

[bugsan]

Spring, c'est une des librairies les plus crades du marché

Wow...

[DarkVenoM]

Et dire que ce monsieur a une "solide" experience Java...
Ils nous conseille quoi au juste ? De faire les SI en ASP 3 ? En Ruby ? En PHP ? En C++ ? Et pourquoi pas en LISP ?

Je ne vois aujourd'hui quel langage de programmation permet de développer un SI avec plus de productivité que Java. C# rivalise mais c'est au prix d'un tarif salé et d'un choix de frameworks plus restreint. Justement, les choix des frameworks parlons en... Ils trouvent que le nombre de cadriciels en Java est étourdissant, et bien moi je me réjouit d'avoir du choix, je préfère passer du temps a choisir un bon framework plutôt que de me voir imposer une mauvaise solution sous prétexte qu'elle est unique. Ainsi en Java (pour faire la comparaison avec .NET, mais on pourrait le faire avec d'autres plateformes) , j'ai plus de choix en terme de serveurs, d'orm, de framework IHM, de framework d'IOC etc.... Java est peut être un choix coûteux pour les entreprises, mais ses alternatives le sont bien plus encore, et bien souvent elles laissent moins de latitudes aux dévelopeurs pour leurs propres choix techniques. Cette latitude permet aux développeurs d'avoir plus de chance de coller aux attentes du client en terme de coûts, de sécurité et de qualité.

[B.AF]

Et dire que ce monsieur a une "solide" experience Java...
Ils nous conseille quoi au juste ? De faire les SI en ASP 3 ? En Ruby ? En PHP ? En C++ ? Et pourquoi pas en LISP ?

Je ne vois aujourd'hui quel langage de programmation permet de développer un SI avec plus de productivité que Java. C# rivalise mais c'est au prix d'un tarif salé et d'un choix de frameworks plus restreint.

C'est vraiment un commentaire inutile. Java est de fait non productif. La comparaison avec certains L4G, beaucoup de projets de migration ont mis le doigt dessus : on ne peut pas empiler framework, technologies et principes et améliorer la productivité. La qualité, oui clairement, mais pas la vitesse.
Il suffit de regarder le code à déployer juste pour faire une application de CRUD en JSF pour comprendre que le principe de Java n'est pas la productivité. Et au final, .Net coûte moins (en dehors de la souscription MSDN; le RAD est meilleur en productivité). Faut parler de ce que l'on connait. Des projets de migration j'en ai vécu plusieurs et oui Java n'est pas une technologie productive. Et ce n'est pas un mal; tant qu'elle est fiable et permet de faire des architectures testables (ce qui est un gain plus important dans le temps que de faire des économies de jours de dev).

Quant à Spring, je n'invente rien, la plupart des orateurs Spring trouvaient drôle de dire au début de leur meeting "Ca fonctionne, mais ne regardez pas le code source". Là encore, avoir du succès et des fonctionnalités n'a jamais signifié exemplarité du code source et de la qualité. Et oui ! C'est aussi ça l'histoire. Et ce n'est pas mieux pour ceux qui se souviennent des releases JBoss qui pouvaient prendre un peu de temps avant de se "stabiliser".

[bugsan]

Faut parler de ce que l'on connait.

puis

"Ca fonctionne, mais ne regardez pas le code source". Là encore, avoir du succès et des fonctionnalités n'a jamais signifié exemplarité du code source et de la qualité.

Je ne sais pas où tu as été sortir ça, d'une brochure marketing .NET ?
Applique tes propos à toi même et avoue nous que 1) Tu n'as jamais vraiment utilisé Spring et 2) Tu n'as jamais été voir le code source.


C'est un des codes sources les plus clean/lisible que j'ai pu voir dans le monde Java, tout projet Apache, Jboss, Codehaus compris.
Et franchement c'est vraiment n'importe quoi de lire ça, et sur developpez.com en plus de la part "d'Experts". Affligeant.

[B.AF]

1 - J'utilise Spring
2 - J'ai plus que regardé le code source.

C'est loin d'être un exemple. Un exemple de code source super clean; c'est quantlib. Pas Spring.

Mais peu importe, de toutes façons, il y a tellement peu de mesure ici que critiquer un framework java me transforme en fanboy microsoft. Et peut être simplement que nous n'avons pas la même notion de propre.

Pour les projets Apache, là encore, va jeter un oeil dans le code de Velocity et dis moi que c'est clean, voir dans Strut.

Du code clean : Guice est clean.

Bref, dans le fonds, je ne suis pas d'intérêt à partir dans les critiques personnelles, je n'ai pas grand chose à prouver.
J'écris ce que je pense : dire que pour faire une archi java il faut juste quelques jours, et spring, hibernate et strut, c'est faux.

Typiquement, la surabondance de Framework ORM (même si là encore il y a des merveilles et de la créativité) à obfusqué la qualité même de Jdbc et de sa conception.

Moi ce qui me dérange, c'est que Java meurt de tous ces poncifs, et si pour faire du java il faut obligatoirement utiliser Spring, hibernate et strut, ben ça rendra Java juste chiant et lourd.

C'est mon avis, et ce n'est pas une comparaison avec .Net.

Je ne suis pas d'accord avec cet article : avoir des frameworks techniques n'a jamais amélioré le SI.