Discussion :

[Logan Mauzaize]

Juste mais il y a plusieurs raisons qui peuvent obliger à passer par du client lourd, l'accès au système (les disques, tout ce qui est rs232, encore très courant dans l'industrie électronique, lecteurs RFID, lecteurs de carte à puce, appareils de mesure, balances industrielles, pilotage de machine etc...) en bref tout ce qui doit sortir du navigateur web.

Je pense qu'il vaut mieux passer au C++ dans ce cas !

Personnellement, je préfère une solution jasperreport, de préférence développée sous linux parce qu'il est plus facile de passer de linux à windows que l'inverse.
Après, il est vrai qu'on a également eu des problèmes avec les imprimantes Linux, c'est vraiment over chiant par moment... surtout pour trouver les drivers qui vont bien...

Même soucis avec une imprimante en réseau

Autre truc qu'on a découvert à nos dépend, le java linux (openjdk) ne fonctionnait pas là où la version sun fonctionnait, bonjour la "portabilité"

Changer de JVM est toujours risquer, malgré le fameux kit de test.
D'ailleurs on avait des problèmes de performance sur une application qui consomme beaucoup de CPU, de mémoire et d'accès disque. On a testé la JVM JRockit, c'était dix fois pire que n'importe quelles mauvaises utilisations des paramètres de la JVM standard

Après, client lourd ou client web, c'est un autre débat, tout dépend de l'application qu'on développe. Je ne me vois pas faire une application de synoptiques en web

Même pas joueur

[OButterlin]

J
Même pas joueur

C'est vrai, ça y ressemble

Il y aurait bien l'applet pour le faire, pourquoi pas... mais les temps de réponse risquent de ne pas être à la hauteur des espérances des clients...

[_skip]

Je pense qu'il vaut mieux passer au C++ dans ce cas !

Et bien tu te trompes.

Non sérieusement, ce genre d'application a aussi souvent une UI riche, une BDD, un système de reporting... Bref tout un aspect gestion (pense à une bête caisse enregistreuse). Et C++ pour ça c'est bien gentil mais ce n'est que rarement le choix le plus judicieux pour tout ce qui est fortement data-centric.

[Logan Mauzaize]

A condition d'avoir le JNI/JNA, écrit en C++ pour s'interfacer avec ces périphériques !

D'un point de vue technique, tu peux pas te passer de t'interfacer avec ces périphériques ésotériques (en matière de bureautique) mais tu peux facilement faire communiquer deux programmes.

Cependant si tu as accès directement à ces périphériques, je t'accordes que je prends dix fois Java avant le C++. Mais c'est seulement parce que je ne sais pas bien faire du C++ ! Et mes collègues encore moins.

[OButterlin]

ben moi, je prends C++ (avec un C++ Builder par exemple) plutôt 2 fois qu'une parce que JNI, c'est bien pénible

[_skip]

A condition d'avoir le JNI/JNA, écrit en C++ pour s'interfacer avec ces périphériques !

D'un point de vue technique, tu peux pas te passer de t'interfacer avec ces périphériques ésotériques (en matière de bureautique) mais tu peux facilement faire communiquer deux programmes.

J'ai utilisé JNI dernièrement pour interfacer un code en C, ok c'est cool si tu as juste une façade très simple et très propre avec des int et des double (le cas qui va bien avec JNA) mais sitôt que tu commences à te balader des pointeurs sur des objets natifs et des chaînes C qu'il faut convertir dans les 2 sens en chaîne java, tu commences vite à avoir envie de te pendre.

Faut s'y prendre à 10 fois pour compiler une lib en la rendant JNI friendly, c'est à dire sans name mangling ni rien, ensuite il faut générer les stubs en ligne de commande (comprends s'y reprendre minimum 10 fois avant d'avoir son interface JNI prête à l'implémentation), et en cas de changement de l'interface tu peux tout recommencer. J'ai eu pas mal de peine et je suis assez loin d'être un débutant en C++.

Pour ce qui est de faire communiquer 2 programmes, il faut que ce soit bidirectionnels, la solution "simple" sous windows c'est de poster un évènement custom au handle de l'application mais c'est pas si trivial.

Cependant si tu as accès directement à ces périphériques, je t'accordes que je prends dix fois Java avant le C++. Mais c'est seulement parce que je ne sais pas bien faire du C++ ! Et mes collègues encore moins.

Ou alors tu achètes la librairie payante sur http://serialio.com car tu sais que l'API officielle de SUN (java communications API) n'est disponible que pour linux, qu'elle ne fonctionne pas avec JWS car tu dois trafiquer le jdk de la machine du client pour t'en servir (en bref l'auteur de ce truc mériterait d'être frit dans l'huile bouillante).
L'alternative open source (rxtx) est moins nulle mais peu maintenue, assez buguée et le code est un bordel sans nom!

Toutefois malgré ça, il peut rester très intéressant de continuer en pur java, même si tu dois payer 300 USD de librairies. En tout cas personnellement je trouve que 300 dollars pour profiter de son IDE préféré et de tout l'écosystème java ça vaut très largement la peine si l'application finale est de taille conséquente et nécessite passablement de BDD et de reporting.
Une simple caisse enregistreuse multi-OS par exemple, je la ferai sûrement en java malgré les difficultés d'interfaçage bien avant d'envisager C++ (bien que certaines librairies C++ comme Qt soient étonnantes de qualité).

(Ou peut être en python qui sait?)

[larry57]

Bonjour,

Je concède que les applications web java ou autres sont jolies, mais quelle lenteur.... Rien ne vaut les vieilles technologies (mainframe ou system i) à partir du moment oû l'on souhaite faire du volume et ou les coûts de maintenance sont bien inférieur.

Larry57

[Logan Mauzaize]

Je concède que les applications web java ou autres sont jolies, mais quelle lenteur.... Rien ne vaut les vieilles technologies (mainframe ou system i) à partir du moment oû l'on souhaite faire du volume et ou les coûts de maintenance sont bien inférieur.

Concernant le volume, il coûte moins cher d'acheter une équipe de bras cassé qui se dit faire du Java et de s'acheter une ferme de serveur PC qu'une seule machine de test IBM ^^ Sans compter les compétences spécifiques pour l'installation/administration/maintenance de la partie système.
Ensuite je n'ai jamais vu de comparaison entre une même application batch sous IBM et sous un PC. Quand je travaillais dans le mainframe, on traitait des millions de lignes de données mais on en avait pour la semaine pour certains traitements.

Concernant le coût, d'un côté tu as des compétences rares, recherchées et qui tendent à disparaître pour gros système et de l'autre une pléthore de débutants Java auto-formés. Ensuite d'un côté tu as des logiciels relativement simples (si a je fais ça, si b je fais autre chose) et vieux (pas d'évolution et d'autres plus complexes et immatures.
Donc je vois pas trop le côté "moins cher" du gros système.
Si tu devais faire la même chose sur des gros systèmes, la complexité serait exponentielle.

[tchize_]

Je rajoute qu'en ce qui me concerne, en Général, je n'ai pas le choix sur l'architecture, je n'ai de choix que sur mes language. Quand on a pas de mainframe, on fait sans mainframe
Je crois que beaucoup de sociétés sont comme ça. L'architecture est existante, le besoin lui est nouveau. Au codeur de lier les deux.

[larry57]

Concernant le volume, il coûte moins cher d'acheter une équipe de bras cassé qui se dit faire du Java et de s'acheter une ferme de serveur PC qu'une seule machine de test IBM

Effectivement, je concède que les tarifs d'IBM sont excéssifs. Mais tu as les mêmes problèmes si tu utilises WAS où le coût de la licence est prohibitif.
Pour ce qui est de la programmation java, il y a autant de méthode de programmer que de développeur. Et cela, je l'ai souvent constaté.

Si tu devais faire la même chose sur des gros systèmes, la complexité serait exponentielle.

Pas d'accord, prenons l'exemple du system i, les dernières versions de l'os permettent de faire du java, de l'xml... La partie logiciel évolue encore.

Larry57

[Logan Mauzaize]

Effectivement, je concède que les tarifs d'IBM sont excéssifs. Mais tu as les mêmes problèmes si tu utilises WAS où le coût de la licence est prohibitif.

Normal c'est IBM :p

Pour ce qui est de la programmation java, il y a autant de méthode de programmer que de développeur. Et cela, je l'ai souvent constaté.

C'est le problème des débutant et/ou auto-formés. Tout bon développeur devrait s'adapter à l'environnement dans lequel il travaille.

Pas d'accord, prenons l'exemple du system i, les dernières versions de l'os permettent de faire du java, de l'xml... La partie logiciel évolue encore.

Bien vu ! Tous les gros systèmes que j'avais vu fonctionnait sous C/COBOL, je pensais qu'ils en étaient restés là.

[OButterlin]

il y a aussi RPG sur les gros systèmes IBM, extrêmement robuste, fiable, performant... le seul problème est de trouver les compétences sur ces vieux langages...
Pour bien connaître les 2 mondes, force est de constater que c'est beaucoup plus fiable de faire tourner un programme RPG que l'équivalent java au travers des couches EJB/JPA/JTA etc...
mais bon, d'un point de vue coût...

[larry57]

il y a aussi RPG sur les gros systèmes IBM, extrêmement robuste, fiable, performant... le seul problème est de trouver les compétences sur ces vieux langages...

Celui qui fait ses courses dans la grande distribution ou encore chez les leader en vente d'électro-ménagers constaterons qu'il y a toujours un écran noir et vert (AS/400) lors des saisies... Idem pour les grandes banques (au moins pour la compta).
Il est claire que les profils deviennent rares. A 37 ans, je suis un jeune :p

Pour ma part, le meilleur compromis est DB et batch sur mainframe ou as/400 et affichage web en java/php.

Larry57

[OButterlin]

Celui qui fait ses courses dans la grande distribution ou encore chez les leader en vente d'électro-ménagers constaterons qu'il y a toujours un écran noir et vert (AS/400) lors des saisies...

Il y a la FNAC aussi...

Blague à part, je travaille sur des applications web sur un serveur JBoss, la base de données est sur un AS/400 ou iSeries.
Il est clair que lorsqu'on fait des traitements complexes, on fait un programme RPG, c'est 10x plus rapide

[thelvin]

Celui qui fait ses courses dans la grande distribution ou encore chez les leader en vente d'électro-ménagers constaterons qu'il y a toujours un écran noir et vert (AS/400) lors des saisies... Idem pour les grandes banques (au moins pour la compta).

Euh, oui, mais là les compétences, c'est de les trouver, les porter et les brancher...

Par ailleurs, j'en voyais encore il y a quelques années, mais maintenant je vois des écrans plats tactiles, dont j'ignore tout de l'interface graphique, à part ses jolis boutons carrés à coins arrondis.

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