Discussion :

[bugsan]

Par exemple, pour Spring, il faut vraiment s'interroger sur son utilité, de manière générale pour tout framework, il faut regarder sa véritable plus-value

Parfois je fais de petite appli et j'utilise quand même un ApplicationContext spring pour la porter. Je ne trouve pas ça lourd, au contraire, ca va tellement vite à faire ! Et ca structure le code : on s'habitue à écrire des services sous forme de pojo configurable et à penser l'application comme un réseau de beans.


Un autre exemple au hasard : Si je ne devais pas utiliser Spring dans mes applications, je recoderais un mini JdbcTemplate, en utilisant le même pattern avec les Callbacks. On peut en faire un en 10 min si on veut et en 30 lignes. Je le ferai tout simplement parce que je serais débarrassé une fois pour toute des dataSource.getConnection() et connection.close(), et que le pattern avec les callbacks permet de n'écrire qu'une fois la gestion des exceptions.
Il n'y a pas meilleure solution que ce pattern en ce qui concerne JDBC. Donc pourquoi s'en passer ?


Il faudrait pouvoir juger sur des exemples de code concret écrit en utilisant différents frameworks. Je suis aussi curieux de voir les patterns qui sont utilisés dans .NET, car cela peut inspirer et être reproduit dans le monde Java.


J'ajouterai pour terminer que j'ai été témoins de projets utilisant Spring et qui étaient écrit en plat de spaghetti (tout en méthode static ... et un seul <bean>). Mais on comprend très vite la cause : des responsables qui pensent que l'on peut faire une appli niquel avec des stagiaires sans aucune formation et un bon framework. Tant qu'il y aura les même causes, il y aura les même conséquences.

[Rei Ichido]

Mais on comprend très vite la cause : des responsables qui pensent que l'on peut faire une appli niquel avec des stagiaires sans aucune formation et un bon framework. Tant qu'il y aura les même causes, il y aura les même conséquences.

Oh que c'est vrai.
D'une manière générale, la tendance à avoir un architecte qui pond sur le papier un design très joli, mais sans rien implémenter (il coûte trop cher), et ensuite on confie ça à des débutants complets ...
Et là aussi je parle de vécu, et pas sur des petits projets (>3000jh).

Alors qu'il suffirait de choper un Expert Technique qui entame les dévs pour faire une base puis encadre les débutants. Surcoût initial léger, énorme gain à l'arrivée, que ça soit en respect des délais, en productivité ou en évolutivité ...


Le problème ne vient ni de Java, ni de l'architecte qui peut avoir parfaitement raison sur le choix des frameworks (encore que certains soient souvent agités devant le client pour faire genre, ça je le reconnais volontiers). Il vient surtout des managers / commerciaux qui veulent un gain immédiat et refusent de dépenser un peu plus au début pour structurer.

Je suppose qu'on peut aussi voir ça comme une confiance aveugle dans l'architecte et dans les débutants ...

[ego]

my 2 cents...

Le Monsieur de l'article, il a pas tout à fait tord, mais personnellement, j'accuserai plus la communauté informatique en général qu'un langage en particulier.
D'une manière générale, on trouve pleins de frameworks pour faire des trucs techniques et ça c'est un bon point. Maintenant, la profusion de solutions est forcément de nature à brouiller la vision d'une personne qui aimerait voir quelque chose de plus simple et clair qu'avant.
"Avant", on avait que notre C ou Cobol et puis c'est tout. Sous une apparence simple, un simple langage à sa disposition, on avait pleins de choses à faire soi-même mais bon ce n'était pas grave, chacun maitrisait son "bébé" et il était plus difficile d'accuser un simple langage qui finalement faisait bien ce que l'on attendait de lui (et on en attendait pas grand chose).
Avec un langage (enfin une plate-forme, une communauté) comme Java, c'est quand même bien moins clair.

Alors pourquoi je parle de la communauté informatique en général ?

Et bien c'est parce que je reste persuadé qu'il n'y a pas encore assez d'efforts réalisés autour de l'outillage pour aider les développeurs et c'est peut être à cause de cela que le Monsieur y dit que c'est compliqué et pas productif.
Avec tous les frameworks que l'on a, il serait vraiment souhaitable que l'on retrouve des L4G comme avant mais s'appuyant sur des solutions ouvertes. De mon point de vue il y a un réel manque de solutions "de bout en bout" outillées (de l'IHM à la base en passant par la couche "services/métier"). De plus des problématiques "éternelles" ne sont toujours pas correctements résolues, prenons un exemple simple :

- La validation des données depuis l'IHM jusqu'à la base de données en ne définissant qu'une fois les choses. Et ne me parlez pas de Seams (encore qu'un effort ait été fait) ou de la JSR "Bean Validation". Quand je dis une fois, je veux dire par exemple que si une données est stockée en VARCHAR(32) dans ma base de données (bon donc on a dit 32 qq part à un seul endroit), je veux avoir par défaut une validation de la longueur de la donnée au niveau de ma couche métier et idem dans la zone graphique de saisie. Et bien entendu si je dois générer un .xsd pour mon WebService, une contrainte "max 32" sera codée automatiquement.

Mais pour avoir cette vision de bout en bout, il faut faire des choix de frameworks et bâtir une solution qui fera forcément des choix d'utilisation de ces frameworks. Et tout le monde dira que c'est du "propriétaire" sauf que l'on devrait quand même arriver un qq chose de plus productif, enfin j'espère.


Bon je m'arrête là, je pars écrire un bouquin sur le futur de l'informatique

[damien.charpentier]

my 2 cents...

- La validation des données depuis l'IHM jusqu'à la base de données en ne définissant qu'une fois les choses. Et ne me parlez pas de Seams (encore qu'un effort ait été fait) ou de la JSR "Bean Validation". Quand je dis une fois, je veux dire par exemple que si une données est stockée en VARCHAR(32) dans ma base de données (bon donc on a dit 32 qq part à un seul endroit), je veux avoir par défaut une validation de la longueur de la donnée au niveau de ma couche métier et idem dans la zone graphique de saisie. Et bien entendu si je dois générer un .xsd pour mon WebService, une contrainte "max 32" sera codée automatiquement.

Mais pour avoir cette vision de bout en bout, il faut faire des choix de frameworks et bâtir une solution qui fera forcément des choix d'utilisation de ces frameworks. Et tout le monde dira que c'est du "propriétaire" sauf que l'on devrait quand même arriver un qq chose de plus productif, enfin j'espère.


Bon je m'arrête là, je pars écrire un bouquin sur le futur de l'informatique

la JSR 303 defini un standard pour une application en Java (de la couche presentation jusqu'au DAO). Ce n'est pas de la responsabilite de cette specification de gerer des technologies completement differentes (comme une base de donnees). Il faudrait se tourner vers des editeurs qui fournissent ce genre de support. JSF 2 supporte la Bean Validation pour verifier la bonne saisie des champs.

[ego]

la JSR 303 defini un standard pour une application en Java (de la couche presentation jusqu'au DAO). Ce n'est pas de la responsabilite de cette specification de gerer des technologies completement differentes (comme une base de donnees). Il faudrait se tourner vers des editeurs qui fournissent ce genre de support. JSF 2 supporte la Bean Validation pour verifier la bonne saisie des champs.

Tu vois damien, c'est un peu ça le problème de l'informatique. J'ai simplement donné un exemple pour illustrer mon propos et toi (mais tu n'es pas le seul) tu me parles de détails et du fait que ce n'est pas le rôle de l'un mais de l'autre.
Il est justement là le problème, c'est à dire l'approche globale.

Encore une fois, prenons un exemple avec les WebServices. On, je veux dire la communauté informatique, c'est empressé de développer cet aspect alors que l'on avait déjà des trucs comme les EJBs. Pourquoi avoir dépensé beaucoup d'énergie à inventer encore une technique de communication au lieu de tenter de résoudre des problèmes plus globaux comme le lien IHM-Métier-BDD ? Encore une fois, la profusion de technos est peut être un point intéressant mais au lieu de développer 50 solutions pour résoudre la même problématique, on pourrait essayer de consolider 2 ou 3 solutions et surtout aborder des problématiques que personne ne veut aborder.

Et vous savez que c'est là que réside la force de Microsoft = ils proposent une solution globale, outillée. Avec eux, on ne se fait pas de noeuds au cerveau et la formation des développeurs est "plus simple" car on sait ce qu'ils vont devoir utiliser.
Pour information, je suis du monde Java et ne connait pas les technos Microsoft. Cependant, je me rend compte que la profusion nuit forcément à la clareté.

[hwoarang]

- La validation des données depuis l'IHM jusqu'à la base de données en ne définissant qu'une fois les choses. Et ne me parlez pas de Seams (encore qu'un effort ait été fait) ou de la JSR "Bean Validation". Quand je dis une fois, je veux dire par exemple que si une données est stockée en VARCHAR(32) dans ma base de données (bon donc on a dit 32 qq part à un seul endroit), je veux avoir par défaut une validation de la longueur de la donnée au niveau de ma couche métier et idem dans la zone graphique de saisie. Et bien entendu si je dois générer un .xsd pour mon WebService, une contrainte "max 32" sera codée automatiquement.

Sauf que pour aller au bout, il faut qu'en cas de modif de la bdd, le programme change sa validation. Autrement dit, une simple requete SQL peut necessiter une recompilation. A moins de faire une verification dynamique à chaque demarrage. Mais deja que les applis actuelles sont plutot lentes à demarrer...

[lequebecois79]

Ce mec ne sort pas grand chose de nouveau....

Java a permis de faire de grosses économies de temps en terme de développement, après si aucun suivi n'est fait au niveau de la qualité, c'est à se demander ce que fait le DSI, chargé de projet et architecte...

Qu'une entreprise décide de faire son propre framework, ça prendra beaucoup de temps quel que soit le langage.

La très grande diversité de Java démontre qu'il n'y a pas une seul réponse à un problème.
Lorsqu'un choix est fait au niveau d'un IDE, librairie ou framework, il faut un minimum se renseigner, voir ses possibilités et non les prendre car ils sont à la mode.... Faut voir si on a intérêt à les employer...

Je crois que cette étape est très souvent négligée.... après il y a blâme... faut que les DSI commencent à assumer leurs responsabilités.

[algabow]

Bonjour,
Je suis entrain d'apprendre Spring ( un autre framework sa aurait été pareil ), et je dois avouer que c'est titanesque.
Mais pas dans le bon sens ... Java est le pire langage sur plusieurs points :
- Ecosystème inexistant ( plein d'outils un peu partout sans vrai lien, un foutoir pas possible )
- Idem pour les tutoriels, chacun fait son pti truc un peu partout, et la plus part du temps ils sont bien trop compliquer, incomplet voir bugé
- Pour réaliser le moindre truc c'est long, très long, et pour résoudre les bugs j'en parle même pas, jme retrouver bloquer sur des conneries et rien sur internet, jme demande comment les gens font pour faire des sites Oo

C'est la que l'expression "Sans maitrise la puissance n'est rien" prend tout son sens, il faut des années d'études pour faire le moindre truc en Java, c'est frustrant que les outils sois tous plus mal concu les 1 que les autres :-\

[thelvin]

- Idem pour les tutoriels, chacun fait son pti truc un peu partout, et la plus part du temps ils sont bien trop compliquer, incomplet voir bugé

Certes, mais ça me semble être l'état de l'art. Je serais curieux de connaître un langage/environnement dont c'est pas le cas.

[tchize_]

Spring n'est pas un mais un ensemble de framework. Quand on a un peu d'expérience derrière soi, un framework (spring ou autre) se prend en main très rapidement. J'ai une équipe de 3 dev, aucun n'avais jamais utilisé spring, mais tous avaient une bonne expérience en javaSE et en java2EE. Ca faisait 4 ans qu'on faisait du dev java orienté web. On a eu besoin de spring pour faire de l'injection dans un projet. C'est passé comme sur des roulettes. Les exceptions de springs sont claires, la documentation progressive. Je n'au vu aucun obstacle à son utilisation.

Pour le reste, quelque soit le language, t'aura toujours un écosystème hors du controle du constructeur. Et on peut effectivement reprocher à java que l'ecosystème sous le controle d'oracle est trop petit par rapport, par exemple, à celui de microsoft sous dot net, ce qui implique plus de tiers.

[algabow]

Enfaite j'ai décider me mettre au JEE directe avec spring, sa ma compliquer la vie j'avoue, se que je remet en cause c'est pas le faite qu'on puisse pas faire les choses facilement avec java, mais d'apprendre les choses facilement.

Il faudrait vraiment un site officiel, avec des tutoriels qui permettent de faire de A à Z toute un gros projet ( pas des echantillon partout ), en recommandant tel ou tel outils.
Certe il ne faut pas fermer Java, mais fermer un peu l'apprentissage, svp pour nous qui avons soif d'apprendre de notre plein gré ^^

[OButterlin]

C'est la que l'expression "Sans maitrise la puissance n'est rien" prend tout son sens, il faut des années d'études pour faire le moindre truc en Java, c'est frustrant que les outils sois tous plus mal concu les 1 que les autres :-\

je ne sais pas de quels outils tu parles mais tes propos me semblent totalement disproportionnés, la frustration se sent...
Un ide comme Eclipse est absolument suffisant pour développer une application digne de ce nom, maintenant, si tu t'attends à faire du drag & drop pour construire une application web, c'est sûr que ça va être plus restreint.

[ThomasEscolan]

C'est un fait que l'écosphère Java souffre actuellement d'une offre pléthorique (Struts/Stripes, Tapestry, JSF, Spring MVC, GWT, JavaFX... j'ai la tête qui tourne) et redondante (cf. débats actuels Java EE 6 vs. Spring 3.x ou la foule des portails apparus). Il est vrai aussi que 1/ les débutants sont mal formés 2/ les développeurs expérimentés s'épuisent à passer d'un framework à l'autre. Sans parler des projets tellement évolutifs qu'ils embarquent plusieurs technologies Web Services en même temps...

En Java, les standards évoluent tellement lentement qu'on leur préfère des solutions alternatives à forte obsolescence. On en est là. Avouez que c'est quand même dommage de faire preuve d'immaturité à cet âge ! De mon temps les bonnes idées étaient simplement reprises et transcendées au sein de la "meilleure" communauté créée.

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

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

[Invité]

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é !

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

[ner0lph]

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

Java est Open Source, non ? À 95 %, il me semble.

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

Et même maintenant !

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é !

+1

[B.AF]

Java est Open Source, non ? À 95 %, il me semble.

Troll velu détecté !!!!

Si tu achétes Microsoft Access pour 190€, pour 10 personnes, soit 2000€ qu'en quatre jours à 500 € par jour tu réalises le développement nécessaire pour ces 10 personnes (10 tables, 4 formulaires; 2 rapports). Tu reprends les données d'un tableur Excel. (1 journée)
On peut donc dire :
2000 € de "techno" (troll velu)
2500 € de ressource humaine
Soit 4500 € de prix pour livrer une appli utile à 10 personnes.

[Je précise pour éviter de faire fanboy microsoft que le fait d'utiliser les équivalents .NET ne ferait pas mieux à architecture équivalente]
Tu prends Eclipse, le JDK, Hibernate, Spring, et strut et PostGre / MySql / Firebird. C'est gratuit. Tu l'installes en local. Tu résouds les dépendances. Tu cherche tes plugins, tu fais tes tests. Ca fait 1 petite journée
Tu achétes un serveur d'application linux. 3000 €; linux est "gratuit".
Tu payes une license pour virtualiser (serveur de prod; serveur de test). 500 €
Tu achétes un serveur Linux pour mettre un SVN. 1500 €.
Ca fait 1 semaine pour la commande; 3 jours pour l'installation.
Tu installes Tomcat. Avec la sécurité et toukivabien et tu te donnes du temps pour tester la sécurité. 2 jours
Tu commences à développer ton dal avec hibernate. Ca fonctionne. Mais tu veux des tests. Tu implémentes tes test depuis les règles du tableur Excel. Au passage, tu fais la reprise Excel vers le SGBD et un script SQL. Tu fais un dev pour reprendre les données proprement avec POI (2 jours); et tu mets en place Quartz pour mettre à jour tes données tous les soirs (1/2 jour) et une réplication prod --> test (1/2 jour). Tu décides d'utiliser Jenkins pour faire l'intégration continue. 2 jours.
Tu commences alors à développer des écrans. Tu fais du strut. 4 jours.
Tu te demandes comment faire les rapports ? Tu prends Jasper. Gratuit. Tu le fais fonctionner avec Eclipse et ton modéle hibernate. 2 jours. Tu fais tes rapports (2 jours). Tu fais l'inclusion Web de tes rapports et du lancement. (2 jours).
tu mets en prod (2 jours).

Mis bout à bout, ton application deux, utilisant des technologies exclusivement gratuite voir libres, te coûte ...28 jours; et 5000 € de matériel et
14 000 € de développement.

Soit 400 % plus chére à produire et quasiment 4 fois plus longue.

Mon exemple est exagéré, je pense que le vrai ratio serait dans les 3, mais l'erreur, c'est celui qui choisi la techno.

[tchize_]

ce que je trouve amusant dans l'histoire ce que tu compare la création en access d'une application desktop pour 10 personnes à la création en java d'une application web pour 500 utilisateurs Donc j'aurais tendance à dire, 4 fois plus chere pour 50 fois plus d'utilisateur, donc 12 fois moins cher / poste.

Tu prends Eclipse, le JDK, Hibernate, Spring, et strut et PostGre / MySql / Firebird. totalement inutile et déplacé pour une si petite application.
Tu résouds les dépendances. Tu cherche tes plugins -> plus besoin cf ci-dessus
Si t'es rodé, tu prend 5 minutes pour installer un plugin maven. Voilà, t'es paré à travailler en 20 minutes. Pour la db, si t'as besoin d'un db pour ça, un H2 embedded et ça roule.
Tu achétes un serveur d'application linux. 3000 €; linux est "gratuit". Si t'achète un serveur linux, la comparaison aurait voulue que tu acheter un serveur windows de l'autre coté. Donc pas de serveur, c'est une application desktop, c'est gratuit
Tu payes une license pour virtualiser (serveur de prod; serveur de test). 500 € Pas de serveur, pas de virtualisation, toutjours 0€
Tu achètes un serveur Linux pour mettre un SVN. 1500 €.Quand bien même tu en aurais eu besoin -> c'est un investissement unique pour toute ta SISI pendant des années, ca nécessite peu de matos, et de toutes façons, tu ne l'a pas mis plus haut, donc retiré de la comparaison, 0€
Ca fait 1 semaine pour la commande; 3 jours pour l'installation. Rien à commander, rien de compliqué à installer, on est à 30 minutes de temps de dev pour le moment
Tu installes Tomcat. Avec la sécurité et toukivabien et tu te donnes du temps pour tester la sécurité. 2 jours N'existe pas-> 0 minutes.(Et un tomcat s'installe en 20 minutes, (juste à dézipper et c'est prêt), seule ton application devra éventuellement être sécurisée)
Mais tu veux des tests. .... 2 jours ->T'as pas mis de test automatisé dans ta version access. Si tu peux travailler comme un cochon, moi aussi-> 0 jours.
Tu commences alors à développer des écrans. Tu fais du strut. 4 jours. Tu fais une appli destkop, 4 formulaires. Si le client est pas chipoteur sur la position des champs, un formulaire se dessine en 2 heures avec matisse + 2 heure pour faire les requetes JDBC derrière. -> 2 jours (et pour info, des formulaires JSF sur des EJB3, c'est pas plus long quand tu connais)
Tu te demandes comment faire les rapports ? Je prend jodreport, je prend le template que m'a envoyé le client en .doc, et j'y met les instructions d'insertion. 1 jour par rapport parce que je suis spépieu. Au passage je rend les odt au client, comme ça, si il veux, il peux les changer n'importe quand sans avoir besoin de moi.


Maintenant, si nous reprenons l'exemple access: tu peux facilement me compter 3 à 4 jours par formulaire personnellement. Et le même pour les rapport. Non Obstant l'utilisation de technos inutile dans ton exemple, je suppose que les temps que tu donne sont fonction des tes connaissance en java. Les formulaire et la config hibernate / test / JSF et autres, ca va beaucoup plus vite quand tu l'a déjà fait quelque fois. Et struts / JSF c'est pas comparable, tu va facilement 2 à 4 fois plus vite avec JSF


Bref, si on dois comparer, comparons des choses comparables à compétence équivalentes. T'es surement capable de réaliser ça en 4 à 5 jours sous access, je suis tout à fait capable de tenir les même délais en java