Discussion :

[Tarul]

Par contre, la prise de tête en Java pour déployer le moindre programme... surtout si tu ne connais pas l'architecture Java.

Je ne suis pas d'accord. Un programme java sous forme de jar est facile à déployer. Un simple zip(les scripts batchs sont devenus inutiles), un installeur en java ou un java web start rend cette opération très simple.

Pour les applications plus complexes genre une application web avec ou sans EJB, il y a des tâche ant dédiés au déploiement. Maven simplifie aussi ce genre d'opération. Parfois un simple déploiement à chaud par l'interface web du serveur d'application ou du conteneur.

[Mat.M]

Java, c'est facile à coder, mais l'enfer à développer.

D'accord mais peux-tu plus développer ?

[FloMo]

Incroyable : java c'est dur a déployer quand on sait pas comment ca marche.
Ben oui c'est la même chose pour tout, quand on connait pas on galère

Non : un binaire, c'est un binaire. Tu le mets avec les bibliothèques qui vont bien éventuellement et c'est tout. Au pire, tu crées un installeur.

Tu n'as pas les contraintes de machine virtuelle voir d'environnement au niveau de l'OS ( Gtk+ par exemple sous Linux ) . C'est d'ailleurs pour ça, je pense, que la démo du browser cross-plateform JDIC ne fonctionne pas sur mon Linux alors que Mozilla est installé dans la bonne version, comme requis, et que Java est configuré pour le web.

[FloMo]

D'accord mais peux-tu plus développer ?

Oui : le langage en lui-même est très simple. C'est d'ailleurs son but à la base : créé facilement des petites applets pour s'amuser.

Le problème, c'est que ça devient vite une usine à gaz car on est totalement prisonnier du modèle objet. D'un point de vue conceptuel, c'est sympa, c'est carré. Mais d'un point de vue productivité, c'est très moyen.

Pour passer une application C++ entière en UTF-8 par exemple, c'est 2 appels maximum ( un pour l'interface, un pour les flux de données, après c'est de la customisation au cas par cas ). En Java, c'est une autre paire de manche.

Dans le même esprit, la dépendance entre Java et le GUI ( Gtk+ sous Linux ) peut rapidement poser des problèmes. Pour le GUI toujours, si on veut personnaliser le moindre élément, c'est la croix et la bannière : il faut déjà penser optimisation. En C++, tu as l'embarras du choix : attaquer le moteur de rendu, mettre une feuille de style, ... de toutes façon, l'optimisation est en très grande partie le travail du compilateur ( hormis l'aspect SQL & co, bien entendu ), donc la seul limite est l'imagination.

Au niveau cross-plateforme, c'est le même topo :
- un moteur web rigoureux et performant ? WebKit,
- un moteur multimédia ? Phonon, VLC,
- de la 3D ? OpenGL,
- ...

Concrètement, j'ai eu à réaliser une application au niveau réseau récemment : à faire fonctionner sous Linux, Windows, SCO avec des performances accrues. C et autotools : du vrai cross-plateforme. C'est vrai, une bibliothèque autre que la standard m'aurait aidé, mais bon. Un seul source pour 3 plateformes, fuites mémoires contrôlées ( en majeure partie, personne n'a le contrôle total ) grâce à Valgrind : ça tourne depuis un moment et on n'a pas besoin de revenir dessus.

Pour avoir travaillé avec les 2 environnements, je constate que Java est de la poudre aux yeux : c'est bien uniquement dans les cas académiques.

[FloMo]

Je ne suis pas d'accord. Un programme java sous forme de jar est facile à déployer. Un simple zip(les scripts batchs sont devenus inutiles), un installeur en java ou un java web start rend cette opération très simple.

Pour les applications plus complexes genre une application web avec ou sans EJB, il y a des tâche ant dédiés au déploiement. Maven simplifie aussi ce genre d'opération. Parfois un simple déploiement à chaud par l'interface web du serveur d'application ou du conteneur.

Pour les binaires :

- Installation :
Windows : suivant, suivant, suivant, terminer.
Linux ( Fedora pour l'exemple ) : yum update ( ou double-clique sur le RPM si on n'a que le RPM )

- Génération des installeurs :
Windows : 1 script NSIS
Linux : 1 fichier SPEC ( ou debian )

[millie]

Pour avoir travaillé avec les 2 environnements, je constate que Java est de la poudre aux yeux : c'est bien uniquement dans les cas académiques.

Quel genre de projet as tu fait avec Java ? Car dans le monde industriel c'est surtout utilisé pour faire du Java EE ce qui est loin d'être un cas académique. (comme c'est du Java EE, le déploiement n'est pas compliqué car il suffit de déposer l'EAR ou le war sur le serveur d'application)

Oui : le langage en lui-même est très simple. C'est d'ailleurs son but à la base : créé facilement des petites applets pour s'amuser.

C'est rarement utilisé pour faire des applets en fait. Le but de base de Java, c'est surtout d'offrir un compilateur compilant vers un bytecode multiplateforme et une machine virtuelle sachant l'exécuter.

[FloMo]

Quel genre de projet as tu fait avec Java ? Car dans le monde industriel c'est surtout utilisé pour faire du Java EE ce qui est loin d'être un cas académique. (comme c'est du Java EE, le déploiement n'est pas compliqué car il suffit de déposer l'EAR ou le war sur le serveur d'application)

Création d'applications multimédia multi-plateformes ( à la AIR, mais il y a 2 ans ) . Côté GUI en fait. Ca marchait bien sur une plateforme : on essaye sur l'autre et là ça tombe. Optimisation était le maître mot.
Côté serveur, je connais moins vu que j'ai surtout fait du PHP de ce côté-là. J'ai juste eu des démos lors de séminaires pour le côté serveur ( démos relativement lentes, mais je mettrai ça sur le dos du manque d'optimisation des développeurs ) .
Mais mon expérience a clairement été orientée GUI.

C'est rarement utilisé pour faire des applets en fait. Le but de base de Java, c'est surtout d'offrir un compilateur compilant vers un bytecode multiplateforme et une machine virtuelle sachant l'exécuter.

De ce que j'ai pu constater, d'un point de vue GUI, c'est pas ça du tout. Ca va pour des applications demandant le minimum niveau interface, mais on sent très vite les limites de l'outil.

Par exemple, pour égailler rapidement une application, je met une feuille de style sur un widget avec une image de fond, le texte en couleur : 2 lignes et le résultat est nickel. Pas besoin de tout redessiner, sous réserve que ça fonctionne ou non.

Enfin, je n'ai testé que jusqu'à Java 6. Peut-être que le 7 est meilleur de ce côté-là.

Je trouve que ça passe pour des applications internes, mais pas pour une application à diffuser ( qui demande une interface travaillée et une indépendance entre l'utilisateur et le technicien ) .

[kpouer]

Non : un binaire, c'est un binaire. Tu le mets avec les bibliothèques qui vont bien éventuellement et c'est tout. Au pire, tu crées un installeur.

Tu n'as pas les contraintes de machine virtuelle voir d'environnement au niveau de l'OS ( Gtk+ par exemple sous Linux ) . C'est d'ailleurs pour ça, je pense, que la démo du browser cross-plateform JDIC ne fonctionne pas sur mon Linux alors que Mozilla est installé dans la bonne version, comme requis, et que Java est configuré pour le web.

Ben tu vas compiler ton binaire en 32 bits, il va marcher nickel, un jour un mec va l'installer sur sa plateforme 64 bits, et là ben par malchance il a les libs qui te sont nécéssaires, mais en version 64 bits seulement. Il faut donc qu'il installe en plus les versions 32 bits de ces mêmes libs, ou alors que toi tu recompile en 64 bits, a condition d'avoir la machine pour.
Si après ca tu trouves que installer une JVM (c'est a dire double click sur un exe sous windows, ou ./jrexxxxx sous linux) c'est dur, alors là je vais me poser des questions.

[Tarul]

Création d'applications multimédia multi-plateformes ( à la AIR, mais il y a 2 ans ) . Côté GUI en fait. Ca marchait bien sur une plateforme : on essaye sur l'autre et là ça tombe. Optimisation était le maître mot.
Côté serveur, je connais moins vu que j'ai surtout fait du PHP de ce côté-là. J'ai juste eu des démos lors de séminaires pour le côté serveur ( démos relativement lentes, mais je mettrai ça sur le dos du manque d'optimisation des développeurs ) .
Mais mon expérience a clairement été orientée GUI.

C'est un gros défaut de java. Le Gui peut être améliorer et est toujours en cours d'amélioration. Je comprends que l'on puisse garder un mauvais souvenir.

Par exemple, pour égailler rapidement une application, je met une feuille de style sur un widget avec une image de fond, le texte en couleur : 2 lignes et le résultat est nickel. Pas besoin de tout redessiner, sous réserve que ça fonctionne ou non.

Il y a outils qui émerge afin de faciliter ce genre de personnalisation. La JSR296 permet d'injecter les resources depuis des fichiers properties au chargement d'une application swing. Là c'est le framework qui faut le boulot de personnalisation, il ne te reste qu'à choisir les couleurs et les images.
Au fait avec quel bibliothèque fais-tu cette personnalisation dont tu parles. Avec Qt?

Enfin, je n'ai testé que jusqu'à Java 6. Peut-être que le 7 est meilleur de ce côté-là.

Peut être, mais java 7 étant en cours de dev, mieux vaut ne pas l'utiliser en environnement de production.

L'ouverture des sources de la jvm permettra peut être d'améliorer swing pour GTK+ et lui permettre de supporter un environnement kde/qt.

[gokud-o-matic]

ce qui est certain, c'est que FloMo n'aide pas a la bonne ambience du debat avec son ton provocateur.
je n'aime pas C, ni C++, mais je ne vais pas le descendre pour autant au rang de phenomene de foire.

Par ailleurs, FloMo, vu ton experience java tres tourne vers le GUI, qu'as-tu utilise comme librairie graphique de base? Swing? SWT? autre chose?

je cite egalement :

Le problème, c'est que ça devient vite une usine à gaz car on est totalement prisonnier du modèle objet. D'un point de vue conceptuel, c'est sympa, c'est carré. Mais d'un point de vue productivité, c'est très moyen.

ton approche n'est peut-etre simplement pas la bonne pour java, ou l'oriente objet(surtout apres avoir lu qu'un codeur C++ bosse mieux en java qu'un codeur java en C++). Par exemple, beaucoup de developpeurs ne savent pas utiliser correctement les threads dans Swing, ce qui a eu pour consequence des interfaces graphiques de pietre qualite. Tu as egalement cite des problemes d'optimisation pour customizer des composants graphiques. Pourtant la aussi il y a du choix: look&feel, attaquer directement les listeners (pour le canvas ou les par exemple), reimplementer une partie de swing...
bien sur, si c'est swt qui est utilise, le probleme est que du jni est utilise. forcement, swt souffre d'un manque de personnalisation a cause de ca.

[FloMo]

Ben tu vas compiler ton binaire en 32 bits, il va marcher nickel, un jour un mec va l'installer sur sa plateforme 64 bits, et là ben par malchance il a les libs qui te sont nécéssaires, mais en version 64 bits seulement. Il faut donc qu'il installe en plus les versions 32 bits de ces mêmes libs, ou alors que toi tu recompile en 64 bits, a condition d'avoir la machine pour.
Si après ca tu trouves que installer une JVM (c'est a dire double click sur un exe sous windows, ou ./jrexxxxx sous linux) c'est dur, alors là je vais me poser des questions.

Bah tu fais une version 64 bits et une version 32 bits, tout simplement. Je vois pas le problème.

[FloMo]

Il y a outils qui émerge afin de faciliter ce genre de personnalisation. La JSR296 permet d'injecter les resources depuis des fichiers properties au chargement d'une application swing. Là c'est le framework qui faut le boulot de personnalisation, il ne te reste qu'à choisir les couleurs et les images.
Au fait avec quel bibliothèque fais-tu cette personnalisation dont tu parles. Avec Qt?

En effet, je fais ça avec Qt, soit dans le designer, soit dans le code, soit dans les directives de dessin. Après, on peut aller très loin en dessinant les widgets dans les canvas ( cf. QtDemo de Qt4.4 avec les sous-fenêtres déformées ) .

Peut être, mais java 7 étant en cours de dev, mieux vaut ne pas l'utiliser en environnement de production.

Je suis bien d'accord.

L'ouverture des sources de la jvm permettra peut être d'améliorer swing pour GTK+ et lui permettre de supporter un environnement kde/qt.

Pour Qt, il y a Jambi. Mais bon, mixer les frameworks, je ne trouve pas ça top.

[FloMo]

ce qui est certain, c'est que FloMo n'aide pas a la bonne ambience du debat avec son ton provocateur.
je n'aime pas C, ni C++, mais je ne vais pas le descendre pour autant au rang de phenomene de foire.

C'est juste un débat d'idées. Concrètement, je m'en fous : pour moi, Java ou C++ c'est vert chou et chou vert. Mais je trouve que c'est l'idéal pour vraiment connaître points forts et faiblesses de chacun des outils.

Par ailleurs, FloMo, vu ton experience java tres tourne vers le GUI, qu'as-tu utilise comme librairie graphique de base? Swing? SWT? autre chose?

Swing, à l'époque où GFX faisait des trucs vraiment sympas ( je ne sais pas où s'en est aujourd'hui ) .

ton approche n'est peut-etre simplement pas la bonne pour java, ou l'oriente objet(surtout apres avoir lu qu'un codeur C++ bosse mieux en java qu'un codeur java en C++).

Je disais ça dans le sens où un codeur Java ignore ce qu'est un pointeur bien souvent. Pas d'un point de vue conceptuel.

Par exemple, beaucoup de developpeurs ne savent pas utiliser correctement les threads dans Swing, ce qui a eu pour consequence des interfaces graphiques de pietre qualite. Tu as egalement cite des problemes d'optimisation pour customizer des composants graphiques. Pourtant la aussi il y a du choix: look&feel, attaquer directement les listeners (pour le canvas ou les par exemple), reimplementer une partie de swing...
bien sur, si c'est swt qui est utilise, le probleme est que du jni est utilise. forcement, swt souffre d'un manque de personnalisation a cause de ca.

J'ai utilisé swing et ai suivi les conseils de développeurs Java pour bien utiliser les threads. Après, j'attaquais directement les listeners mais je trouvais vraiment que je codais plus que nécessaire juste pour avoir un rendu fluide alors que j'utilisais justement Java pour coder efficacement.

Je pense qu'on peut pas tout faire avec Java ( tout comme on ne peut pas tout faire en C++ ) . C'est très pratique en applications internes ( Eclipse RCP par exemple ) mais faut pas trop gratter. Cela ne remet pas en cause les capacités hors GUI.

[kpouer]

Bah tu fais une version 64 bits et une version 32 bits, tout simplement. Je vois pas le problème.

Le problème est qu'une version 64 bits n'apporterai rien, et que la 32 bit tournerait sur un OS 64 bits si les libs étaient installées. Enfin bref tout ca pour dire que que ce soit en c++ comme en java des problèmes d'installation peuvent se présenter

[FloMo]

Le problème est qu'une version 64 bits n'apporterai rien, et que la 32 bit tournerait sur un OS 64 bits si les libs étaient installées. Enfin bref tout ca pour dire que que ce soit en c++ comme en java des problèmes d'installation peuvent se présenter

Oui, c'est vrai. Après, faut s'adapter au contexte.

[Mat.M]

Oui : le langage en lui-même est très simple. C'est d'ailleurs son but à la base : créé facilement des petites applets pour s'amuser.

Pour passer une application C++ entière en UTF-8 par exemple, c'est 2 appels maximum ( un pour l'interface, un pour les flux de données, après c'est de la customisation au cas par cas ). En Java, c'est une autre paire de manche.
.

Comme on l'aura remarqué je suis pro C/C++ et pas très fana de Java ( et autres C# sharp machin ) .
Ceci dit Java et consorts comme C# c'est sensé "améliorer la productivité et réduire les lignes de code" , non ?
En C/C++ pour déclarer une chaine et l'affecter il faut utiliser strcpy en faisant gaffe aux débordements de tableaux .
Remarque il y a std::string et CString pour MFC,String pour la VCL

C'est curieux concernant ton exemple de chaine de caractere avec Utf8 cela devrait être plus simple en Java, il ya des classes pour ça ? ( je ne suis pas assez calé sur Java )

Le problème, c'est que ça devient vite une usine à gaz car on est totalement prisonnier du modèle objet. D'un point de vue conceptuel, c'est sympa, c'est carré. Mais d'un point de vue productivité, c'est très moyen.

C'est vrai en Java et autres langages avec GC comme VB.NET et C# on ne peut pas faire un code source "hétéroclite" et déclarer des fonctions que j'appelle dans le vide c.a.d. du genre _cdecl c.a.d. non encapsulée dans une classe

[LLB]

Ceci dit Java et consorts comme C# c'est sensé "améliorer la productivité et réduire les lignes de code" , non ?

Ils apportent surtout une vision plus "haut-niveau". Ce n'est pas forcément un avantage et ça dépend des besoins. Cette vision "haut-niveau" vient d'une couche supplémentaire (la VM) et offre un certain nombre de fonctionnalités (introspection et compagnie).

L'évolution des langages s'accompagne souvent d'une réduction du nombre de lignes. En moyenne, je trouve que C# et Java sont très verbeux. Mais, de ce que j'ai vu, C# l'est en effet (légèrement) moins que C++

C'est curieux concernant ton exemple de chaine de caractere avec Utf8 cela devrait être plus simple en Java, il ya des classes pour ça ? ( je ne suis pas assez calé sur Java )

C'est plus une question de bibliothèque que de langage. C'est peut-être plus simple pour faire ça avec Java (je ne sais pas), mais tu devrais pouvoir obtenir quelque chose de similaire avec C++.

C'est vrai en Java et autres langages avec GC comme VB.NET et C# on ne peut pas faire un code source "hétéroclite" et déclarer des fonctions que j'appelle dans le vide c.a.d. du genre _cdecl c.a.d. non encapsulée dans une classe

Il n'y a aucun rapport avec le GC. Java et C# ont choisi d'imposer le modèle objet. Je trouve ça dommage d'imposer ce paradigme, mais tu peux toujours faire des méthodes statiques (il y a alors peu de différences avec une fonction "dans le vide").

on parle de C++ là, strcpy c'est du C.

... qui est incluse dans C++. Mais je crois que Mat.M est au courant.

[bountykiler]

Ils apportent surtout une vision plus "haut-niveau". Ce n'est pas forcément un avantage et ça dépend des besoins. Cette vision "haut-niveau" vient d'une couche supplémentaire (la VM) et offre un certain nombre de fonctionnalités (introspection et compagnie).

L'évolution des langages s'accompagne souvent d'une réduction du nombre de lignes. En moyenne, je trouve que C# et Java sont très verbeux. Mais, de ce que j'ai vu, C# l'est en effet (légèrement) moins que C++

En utilisant les templates, cela peut dans certains cas être l'inverse. Mais cela demande aussi un peu plus de reflexion.

C'est plus une question de bibliothèque que de langage. C'est peut-être plus simple pour faire ça avec Java (je ne sais pas), mais tu devrais pouvoir obtenir quelque chose de similaire avec C++.

Tout à fait d'accord (d'une manière générale, les gens ont par ailleurs souvent tendance à comparer les API plutot que les langages en eux-même, je trouve).

Il n'y a aucun rapport avec le GC. Java et C# ont choisi d'imposer le modèle objet. Je trouve ça dommage d'imposer ce paradigme, mais tu peux toujours faire des méthodes statiques (il y a alors peu de différences avec une fonction "dans le vide").

Tout à fait d'accord ici aussi.

... qui est incluse dans C++. Mais je crois que Mat.M est au courant.

En même temps, je ne crois pas que l'on peut encore raisonnablement parler de fonction en C quand on fait du C++. Le C++ et a été conçu de sorte à reprendre la syntaxe du C et d'être compatible avec celui-ci (dans le sens je peux utiliser mes fonctions C en C++). Mais ça s'arete là. (Ce n'est pas pou rien que développez a décider des scinder les sections C et C++ ;-) )

Sinon autre chose, on parle souvent de l'introspection dans ce débat en disant que celui-ci est plus avancé en java qu'en C++. Cela est plus que probablement vrai (j'connais assez mal java, mais je sais que C++ n'est pas super avancé en la matière), mais je pense aussi que l'utilisation, certes intensive, de templates peut limiter en grande partie ce besoin, car il permettent de connaitre au moment de la compilation le type précis d'une variable, ce que ne permettent pas toujours de faire les types générics en java (enfin il me semble).

[kpouer]

Tout à fait d'accord (d'une manière générale, les gens ont par ailleurs souvent tendance à comparer les API plutot que les langages en eux-même, je trouve).

Effectivement mais en java comme en C# d'ailleurs l'api fait partie intégrante du langage et est probablement une raison important pour laquelle on peut choisir ces langages plutot qu'un autre : on a accès a énormément de choses de manière standard.
Evidemment ce n'est pas impossible d'avoir des api équivalentes en c++, mais leur cohérence ne sera pas la même.
Je ne suis pas un grand expert en c++ donc je peux me tromper mais par exemple en java une api décrit les parseurs xml. Ainsi on peut avoir plusieurs implémentation des parseurs xml et en changer en gardant la compatibilité des sources. C'est tout de même assez pratique

[LLB]

Sinon autre chose, on parle souvent de l'introspection dans ce débat en disant que celui-ci est plus avancé en java qu'en C++. Cela est plus que probablement vrai (j'connais assez mal java, mais je sais que C++ n'est pas super avancé en la matière), mais je pense aussi que l'utilisation, certes intensive, de templates peut limiter en grande partie ce besoin, car il permettent de connaitre au moment de la compilation le type précis d'une variable, ce que ne permettent pas toujours de faire les types générics en java (enfin il me semble).

Oui, les templates sont bien plus puissants que les generics. Peut-être des gens utilisent-ils l'introspection pour pallier les limitations du langage, c'est possible, mais ce n'est pas vraiment le but à la base.

L'introspection (je parle de façon générale, j'ai très peu d'expérience en Java) permet d'apporter un dynamisme qui n'est pas possible sans. Cela apporte une partie des fonctionnalités des langages de script (comme tout ce qui est dynamique, on réduit alors un peu la sûreté).

Cela peut être très utile dans des bibliothèques (qui peuvent alors récupérer automatiquement des informations sur le reste). Par exemple, la (dé)sérialisation automatique. Par exemple, l'accès à des méthodes dont on ne connait le nom qu'à l'exécution. Par exemple, je sais que l'interfaçage de Lua avec .NET est grandement simplifié par introspection (le code Lua peut accéder à certaines méthodes du code). Etc.