Discussion :

[xelab]

Enfin en 10 ans d'expérience sur la conception et le développement de projets Java, c'est la première fois que j'entends quelqu'un avouer ce qui est peu avouable, les projets Java coûtent très très chers aux clients mais aussi aux prestataires.

Et ce n'est pas au moment du développement du projet que cela coute mais bien après ! C'est à dire lorsque l'application va vivre sa vie, va devoir être maintenue et donc subir des opérations de maintenance mais aussi des évolutions voir des refontes radicales.

Pourtant j'adore ce langage et j'apprécie toute la "Java Sphere" qui l'entoure sa grande force par rapport à d'autres langages plus pauvres et plus fermés de ce point de vue là. Mais je dois dire que même après 10 ans passé dans ce monde captivant on n'en fini toujours pas de réinventer la roue et cette pratique est très pénalisante pour les projets. On aboutie inévitablement à du code plus où moins fiable, plus ou moins performant et surtout plus où moins lisible et évolutif surtout lorsqu'il est implémenté dans 95% des cas par de jeunes ingénieurs fraîchement sorti de l'école et qui ont appris le langage sur le tas au moment de la réalisation du projet !

Dans les 10 euros du coût d'un projet Java, 50 centimes sont généreusement investi dans le développement initial et 9.50 euros seront encore investi pour tenter d'assurer sa maintenance tant bien que mal jusqu'au moment où 6 mois après une nouvelle direction décide de faire table rase pour arrêter la surchauffe des coûts et tout recommencer ... et ce dans les mêmes conditions.

Merci panda31 pour cette citation très à propos:

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."
John F. Woods

Source: http://groups.google.com/group/comp....b64e464aed84a0

Mais est-ce vraiment lié à Java? J'ai l'impression d'avoir déjà entendu ça à propos d'autres technos (et payantes)... Le problème de base, c'est peut-être penser que java, c'est "gratuit".

[Patriarch24]

On aboutie inévitablement à du code plus où moins fiable, plus ou moins performant et surtout plus où moins lisible et évolutif surtout lorsqu'il est implémenté dans 95% des cas par de jeunes ingénieurs fraîchement sorti de l'école et qui ont appris le langage sur le tas au moment de la réalisation du projet !

En quoi cela serait différent avec .NET ou python ou autre ?

L'avantage de dotnet, c'est qu'il y a les briques de microsoft et ça suffit,

Les briques standards Java suffisent aussi : JSF + EJB + JPA.

avoir des frameworks techniques n'a jamais amélioré le SI.

+1.

Java est de fait non productif.

Je ne suis pas tout à fait d'accord. Cela demande une certaine maitrise des bons outils pour être productif, mais on arrive à être productif avec Java. Par contre je suis d'accord sur le fait que ça ne coule pas de source.

on passe encore autant de temps à parler d'Eclipse alors que j'ai l'impresson de perdre le mien à chasser à travers tous ses projets de plugins, à gérer des dépendances hasardeuses parfois et une prise en main toute relative par les équipes. Je demande un bon outil de modélisation uml ou merise et je ne trouve rien dans le catalogue cet IDE qui soit probant

Là encore, je pense qu'il ne faut pas confondre "valeur d'un outil" et "compétence pour l'utiliser".

Une bonne architecture est maintenable quel que soit le langage utilisé. Dire que le coût est supérieur car on utilise Java / C# / (langage de votre choix ici) et tel ou tel framework est une ineptie ; le problème n'est pas tant de mettre en place une solution technique que de la comprendre et surtout la maitriser : utiliser Struts / Spring / Hibernate sans savoir pourquoi, c'est ça qui coûte cher !

[B.AF]

Je suis très d'accord avec le fait que le problème ne soit pas Java ou un autres langage mais son usage.

C'est un problème de gestion globale : techno open source = gratuit, développeurs juniors = bas prix.

A tout gérer par le coût direct le plus petit, faut pas s'étonner des défauts. Mais ça n'a rien à voir avec l'open source ou le Java. Ca peut arriver avec du C++ et du closed source.

Le problème de fonds, c'est qu'à force d'enseigner n'importe quoi, n'importe qui fait n'importe quoi n'importe où.

[Patriarch24]

Entièrement d'accord B.AF.

[freddyboy]

« prise en main longue et compliquée », « des compétences et une expertise coûteuses », des « architectes apprentis sorciers », un « écosystème technologique étourdissant »

Exactement le constat que je fais dans ma société actuelle...
Sans rentrer dans les détails ni dans la guerre des technologies, pour moi il est clair et net que .NET/C# permettent plus de productivité, de résultat et de retour sur investissement...concernant les coups je suis d'accord avec ALCINA, les projets coutent moins chers en .NET...

[hedes]

Pour ma part, la plateforme JAVA a souffert de tatonnements de la part de certains concepteurs et du foisonnement de technologies ce qui amène ce constat cruël mais très réaliste.
Paradoxalement, c'est maintenant je trouve la plateforme mature: les EJB 3 sont simples à utiliser et pour tout ce qui internet, les framework EXT/GWT/VAADIN sont en bonne voie ( il leur faut cependant encore améliorer pas mal de choses), il existe des solutions simples à mettre en place pour les caches distribués (allez faire un tour du côté d'Hazelcast).
J'utilise toutes ces technos en ce moment et je dois dire que je suis assez statisfait de la rapidité de mise en oeuvre. Au niveau langage, il reste pas mal de petites choses à améliorer pour être à la hauteur de C#. Mais je ne me fais guèere de soucis, car très vite, ce dernier va devenir trop riche pour être facilement maintenable ;-).

[gagaches]

moi, perso, ce qui me fait rire, ce sont vos commentaires ...

vous restez tous dans vos carcans d'archi n-tiers Java/C++/C# (python, ruby,...)

je ne veux pas dire "à l'époque", mais le COBOL ça marchait pas si mal.

Et j'ai sous le coude 3 gros projets conséquents de grands comptes qui ont fortement perdu en productivité/performance en passant de mainframe à J2EE.

Mais c'est sûr, J2EE, c'est tellement

Pb de gestion globale : choisir une nouvelle techno sans proto, sans budget, sans suivi, sans investissement dans la formation, et en prenant des frameworks "qui font le café" mais qui sont pas adaptés et tout ça en 40jours, hophop, c'est forcément

Au niveau transactionnel, des langages comme COBOL sont bien plus rapides & productifs qu'un équivalent en couche métier Java.

=> un langage web pour la présentation (web services), un langage transactionnel pour la couche métier, ... c'est trop demandé ?
ie utiliser chaque langage dans ce pour quoi il est adapté plutôt que de vouloir tout faire en un seul langage inadapté !

[Grimly_old]

J'ai vu tant de choses. Même des langages complètement inconnus qui peuvent faire des miracles.

Un langage n'a aucun coût (hormis une licence pour certains). Le plus grand coût viens clairement des ingénieurs et techniciens qui réalisent les différents projets. Si un langage particulier deviens "cher", c'est un problème de ressources humaines et non de technologie.

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

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

[tchize_]

=> un langage web pour la présentation (web services), un langage transactionnel pour la couche métier, ... c'est trop demandé ?

Tu souffre déjà pas mal en tant que recruteur si tu dois trouver quelqu'un de compétent dans un language (j'ai vu défile plein de gens sur des poste java, dont 90% étaient refoulé au premier test de connaissance basique du language), si t'a besoin d'un type qui fait à la fois du COBOL pour sa couche data, du java pour sa couche buisness et du .net pour sa couche web..... Ben pour 2500€ net par moi, je veux bien venir chez toi poru t'aider à chercher

Maintenant je suis d'accord avec toi. Utiliser le bon outil pour le bon besoin, dans la mesure des compétences dont vous disposez.

[DarkVenoM]

L'avantage de dotnet, c'est qu'il y a les briques de microsoft et ça suffit,
DAL => entity, couche de communication => WCF, validation => dataannoration, presentation => xaml/asp/mvc, analyse => reporting services, repository => TFS.
Et c'est tout, du coup n'importe quel archi utilise les même outil ce qui n'est pas vrai pour java.
Et dotnet n'est au final pas plus cher, maintenance plus facile, dev moins cher cf prix du marché.
Les couts d'infrastructure son identique, aucune grossr entreprise prends une distribution linux gratuite, trop de risque.
Les couts d'infra de windows ou de ibm, sun, red hat, sont relativement identique.
Au final un projet dotnet coutera moins cher qu'il soit de 1500/10000/100000 jour/homme.
En dessous les entreprises prennent php.

En quoi un projet .NET utilisant spring.NET, Nunit, NHibernate serait moin cher qu'un projet Java utilisant Spring, Junit et hibernate ?


Tout dépend des frameworks que tu utilises, et pour avoir fait du .NET et du Java, les trucs bien que je peux faire en .NET, je peux aussi les faire (avec le même niveau de productivité et de qualité) en Java, mais l'inverse n'est hélas pas toujours vrai. Par exemple, je cherche encore des frameworks IHM en .NET qui me permettent la même productivité que GWT... Je cherche encore des équivalent à Maven en .NET (réelement utilisés...)... etc..

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

[hwoarang]

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.

Ouais c'est bien pour un gros projet. Mais dans mon cas, je cherche plutot à me documenter à titre personnel (le projet sur lequel je bosse est trop avancé pour s'amuser à tout recommencer pour integrer une architecture lourde). Et je trouve que passer 3 jours à plein temps pour quelqu'un qui connait (puisque c'est lui qui propose la techno on peut imaginer qu'il la connait) ca me parait beaucoup. Et si c'est moi qui cherchait, ce serait sur mon temps perso donc ca fait encore plus

Mais bon, c'est pas Java qui est en cause, je pense plutot que c'est ceux qui font les frameworks qui ne les mettent pas assez en avant en expliquant en quelques phrases l'interet et les cas ou le framework est adapté...

[william44290]

Ce débat me rassure et me conforte dans mes choix.
Finalement le juste ce qu'il faut quand il faut me convient bien.
IL sera toujours temps de rechercher une techno particulière lorsque le besoin s'en fera sentir.

[tchize_]

Ouais c'est bien pour un gros projet. Mais dans mon cas, je cherche plutot à me documenter à titre personnel (le projet sur lequel je bosse est trop avancé pour s'amuser à tout recommencer pour integrer une architecture lourde).

Gros HS pour y répondre

Ben le principe ici donc c'est dire que cette techno ne t'es pas utile pour ce projet

En général, ce genre de proposition dans l'équipe ne va pas dans le sens de "on va virer X pour mettre Y à la place". Ca pourrait, mais alors faut démontrer que ca peux se changer facilement et que ça apporte quelque chose. Ce genre de proposition c'est souvent uniquement bon quand X n'est pas beaucoup utiliser. On travaille plutot sur base du client qui dit "je veux savoir faire machin" et là t'as un dev qui dit "ha ben, pour machin, j'ai vu un article sur Z, j'ai jamais utilisé, mais ça a l'air de le faire"

En général, c'est comme ça chez nous que les dev apprennent des nouvelles apis, en les intégrant au projet. Dans notre projet actuel, l'interface est faite entièrement avec vaadin. Alors qu'au départ, personne ne l'avait jamais utilisé et on avait aucune compétence en interne. Il nous fallait une interface graphique, on est tombé sur un article qui en parlait concisement, on a fait une petite interface à la con. Ca marchait, facile à prendre en main, on avait pas besoin de faire de test de charge vu qu'il n'y a pas de charge prévue sur l'interface (max 5 utilisateur simultanés), donc on s'est lancé dedans

[benzoben]

Pour paraphraser bon nombre de post, ce n'est pas Java en tant que langage qui est en cause. En même temps c'est peut être Java en tant que langage qui est en cause!
Java a simplifié pas mal de choses. Je développe depuis longtemps avec ce langage donc peut être que mon regard n'est pas objectif, mais objectivement, développer une appli en Java est beaucoup plus simple qu'en C/C++ (probabilité troll 85%) : pas de pointeur, pas de virtual, pas de destructeur ou de malloc...
En plus, le monde Java (et pas Java, la différence est importante) a apporté de la doc, standardisée, des normes. Que de boulot prémaché (je ne critique pas au contraire)! Plus besoin de formation, un bouquin à la fnac et je suis architecte JEE! Java a permis a plein de boites de se monter en recrutant du pas cher, du copier coller sur internet, de l'offshore (ah l'offshore).
En revanche, la gestion de projet, les budgets, les formations ça ne se code pas en Java!
Une dernière remarque : si .NET était si bien, ce débat n'aurait pas lieu vu qu'on bosserait tous dessus!