Petite question sur Java

[KouKaVaniLLa]

Salut

Quand je consulte les offres d'emploi (belgique) je vois que les dev. Java sont fort demandés ....

Bon c'est surement une mode qui changera encore .

Pourquoi le Java est il si demandé alors qu'une application développée en Java est lourde et lente ?

merci

[tsubasaleguedin]

Salut

Quand je consulte les offres d'emploi (belgique) je vois que les dev. Java sont fort demandés ....

Bon c'est surement une mode qui changera encore .

Pourquoi le Java est il si demandé alors qu'une application développée en Java est lourde et lente ?

merci

Oui java c'est mou du genou et c'est lourd, mais en génie logiciel (prise en compte du taux de réussite du projet et de son evolution) je pense que Java est un langage qui en terme de contrainte rempli le plus sont role vis a vis des DSI ( deploiement, test unitaire, UML, abstraction matériel/OS, cout). Et comme c'est les DSI qui decide ....

Perso j'ai bcps de mal avec le vocabulaire Java ( leur beans, netbeans, appliquette etc ...). D'ailleurs moi ce qui me fait marrer c'est les téléphones sous java qui plante et qui met 5 minute a s'allumer, c'est paradoxale pour un langage qui est sensé etre le plus approprié et integré en terme de test unitaire etc..

Car le génie logiciel c'est bien beau et c'est bien jolie d'avoir un langage qui s'en apporche le plus pour diminuer le temps d'etude de faisabilité d'un projet mais a quoi ca sert avec un langage aussi lourd et bloated ? C'est la question que je me pose a chaque programme Java que je vois qui est lent et de plus plantogene si ta pas LA J2RE qui va bien pour le logiciel.

[KouKaVaniLLa]

C'est vrai que de plus en plus on rencontre Java sur les portables alors que c'est lourd et lent ....

C'est probablement le cout qui explique cela, si celui ci est faible .

[Sentinel]

"Java c'est mou et lent" c'est une idée reçue qui a la vie dure...

D'ailleurs je suis sûr que tu ne sais même pas d'où te vient cette "information" ?

Java en lui-même n'est absolument pas lent. La version 1.4 a amené les perfs quasiment au niveau du C++, et Java5 est bien meilleur, notamment en gestion mémoire.

L'origine de cette légende urbaine de lenteur vient des premières versions de Swing, la librairie graphique officielle de Java. Beaucoup de développeurs n'avaient pas compris comment programmer Swing efficacement, et le résultat était des interfaces poussives, lentes, frustrantes. Cela a bien changé depuis. Le langage a beaucuop évolué, ry les développeurs ont appris à en tirer le meilleur parti.

Maintenant, Java est un langage qui a beaucoup d'atouts :

- Rapide

- Propre (pas de constructions ambiguës comme l'héritage multiple)

- Fonctionne de manière identique sur toutes les plateformes, sans recompilation ni adaptation

- Fonctionne sur des ordinateurs, sur des machines portables (J2ME), dans des browsers (applets), etc...

- Possède des librairies de qualité industrielle pour à peu près TOUT (connexions aux BDD, webapps, réseau, webservices, mail, etc...)

- Extrêmement bien supporté par les acteurs majeurs du marché (IBM, BEA, Oracle...)

- Communauté énorme (Apache, Codehaus, etc)

- Documentation d'excellente qualité (essayez de trouver une info dans MSDN vous comprendrez la différence...)

Donc, si on veut bien se débarrasser de cette idée reçue de lenteur qui lui colle à la peau depuis java 1.2, on comprend vite pourquoi ce langage est si demandé et si utilisé !

[tsubasaleguedin]

"Java c'est mou et lent" c'est une idée reçue qui a la vie dure...

D'ailleurs je suis sûr que tu ne sais même pas d'où te vient cette "information" ?

Java en lui-même n'est absolument pas lent. La version 1.4 a amené les perfs quasiment au niveau du C++, et Java5 est bien meilleur, notamment en gestion mémoire.

L'origine de cette légende urbaine de lenteur vient des premières versions de Swing, la librairie graphique officielle de Java. Beaucoup de développeurs n'avaient pas compris comment programmer Swing efficacement, et le résultat était des interfaces poussives, lentes, frustrantes. Cela a bien changé depuis. Le langage a beaucuop évolué, ry les développeurs ont appris à en tirer le meilleur parti.

Maintenant, Java est un langage qui a beaucoup d'atouts :

- Rapide

- Propre (pas de constructions ambiguës comme l'héritage multiple)

- Fonctionne de manière identique sur toutes les plateformes, sans recompilation ni adaptation

- Fonctionne sur des ordinateurs, sur des machines portables (J2ME), dans des browsers (applets), etc...

- Possède des librairies de qualité industrielle pour à peu près TOUT (connexions aux BDD, webapps, réseau, webservices, mail, etc...)

- Extrêmement bien supporté par les acteurs majeurs du marché (IBM, BEA, Oracle...)

- Communauté énorme (Apache, Codehaus, etc)

- Documentation d'excellente qualité (essayez de trouver une info dans MSDN vous comprendrez la différence...)

Donc, si on veut bien se débarrasser de cette idée reçue de lenteur qui lui colle à la peau depuis java 1.2, on comprend vite pourquoi ce langage est si demandé et si utilisé !

Donc tu insinue que eclipse est programmé avec des pieds ? Car essaye eclipse sur un athlon 2000+ tu va comprendre que pour moi c'est pas une idée recu la lenteur de java. Et les téléphone java qui mette 5 minute a sinitialiser ... Enfin bon j'etaisur que tu aller repondre contre etant specialiste Java et fanboy java .

Moi j'ai rien contre java, mais toute les demonstration que j'ai vu etait lente et je parle meme pas des pilotes bdd qui sont horriblement lente (du au langage ?) comparer a par exemple a un pilote ADS.

Moi je demande que ca que tu me fasse une demo d'un programme java qui me scierai pas par sa lenteur, en tout cas c'est pas eclipse qui me prouvera le contraire etant totalement inutilisable ( scrolling qui rame sur des codes sources de plus de 50 lignes ....) sur un athlon 2000 +.

Pour moi le seul succés de Java est du a son rapprochement tres intimes avec les méthodes courantes de génie logiciels, qui permette de reduire les couts d'etude/faisabilité/contraintes/deploiements du logiciel, ce qui aujourd'hui charme les DSI qui s'oriente la dessus. Mais en aucun cas ce choix est porté parceque Java est un langage rapide d'execution.

Les fameux (fumeux) benchmark sont généralement des benchmark qui ne prenne pas en compte le coldstart de l'application et ni sa consommation mémoire ( JVM incluse ), si tu me montre des benchs qui prouve que java est aussi rapide que du C en coldstart je veux bien... Si c'est pour un enieme benchmark qui montre que une boucle while est aussi rapide on s'en fou et heureusement que c'est aussi rapide ...

PS: le coldstart inclus le temps de demarrage de l'application + l'algo de benching + extinction de l'application

[Sentinel]

Bencher sur un temps de démarrage, c'est totalement stupide... Même si les applications mettaient une heure à démarrer, cela n'aurait toujours aucune sorte d'importance. Les grosses applications d'entreprise ne sont pas lancées souvent, elles sont même prévues pour au contraire offrir un uptime maximal (temps de fonctionnement sans arrêt).

Il est vrai que la JVM consomme pas mal de mémoire, mais il est tout à fait possible de régler ce paramètre. Quand bien même, c'est encore une fois un faux problème : un SI peut facilement augmenter la taille mémoire de ses serveurs, le prix de la barrette est totalement insignifiant par rapport aux enjeux.

Concernant la rapidité, Java5 surpasse le C pour tous les problèmes d'allocation mémoire. Le nombre de cycles nécessaires pour allouer une zone mémoire est inférieur, grâce à la façon dont elle est gérée. Il est même possible de travailler sur des applications temps-réel (javolution). Encore une fois, la réputation de lenteur vient des premiers temps de Java, et plus particulièrement du toolkit graphique Swing.

Tu remarqueras d'ailleurs que tous les acteurs majeurs sont passés aux langages semi-compilés : Java, .Net, Python... Preuve que les technologies et algorithmes autour des machines virtuelles ont largement progressé au fil du temps.

Tu me diras : je peux trouver une application en C qui ira plus vite qu'une application Java. Oui, sans aucun doute. Mais une application industrielle n'est pas un jeu. On ne cherche pas à afficher des milliards de polygones à la seconde sur un PC lambda, mais plutôt à offrir des services sûrs et stables sur des gros systèmes.

Dans ce genre d'application, le goulet d'étranglement se situe presque toujours au niveau de la base de données. Et je ne parle même pas des applications en mode client léger (applications web), où l'application passe 95% de son temps à attendre que l'utilisateur lise l'affichage et saisisse des informations dans les formulaires...

On ne demande pas à une application d'être incroyablement rapide. On lui demande d'être suffisamment rapide, et surtout d'être facile à développer et maintenir.

Une fois qu'on a compris cela, on se penche sur ce qui compte réellement : support des grands éditeurs, facilité de développement, sécurité du langage... Ce qui explique grandement son succès.

Son support multiplateformes, notamment les OS type *Nix, considérés comme plus sûrs en production, est également un atout énorme en entreprise. Là où j'interviens en ce moment, nous développons sous Windows/Eclipse, et les applications sont ensuite déployées sur des lames sous Solaris. Seul Java permet cette souplesse.

PS : personnellement (et je dis ça sans mauvaise foi), j'ai longtemps développé sur mon Pentium2 233, puis sur mon Athlon 700 avec Eclipse. Je n'ai jamais eu de problème d'affichage ou de scrolling... Le fait que je tourne sous Linux, qui gère différemment la mémoire, explique peut-être aussi cette performance.

De toute façon, Eclipse utilise le toolkit graphique natif (win32 sous windows, GTK sous linux, etc), donc son affichage est aussi rapide que n'importe quelle autre application. Vérifie quand même tes pilotes graphiques ?

PS 2 : Un bench qui prend en compte le temps de boot de la JVM : http://java.sys-con.com/read/45250.htm?CFI...DA111FE3A94B222

[tsubasaleguedin]

PS : personnellement (et je dis ça sans mauvaise foi), j'ai longtemps développé sur mon Pentium2 233, puis sur mon Athlon 700 avec Eclipse. Je n'ai jamais eu de problème d'affichage ou de scrolling... Le fait que je tourne sous Linux, qui gère différemment la mémoire, explique peut-être aussi cette performance.

De toute façon, Eclipse utilise le toolkit graphique natif (win32 sous windows, GTK sous linux, etc), donc son affichage est aussi rapide que n'importe quelle autre application. Vérifie quand même tes pilotes graphiques ?

PS 2 : Un bench qui prend en compte le temps de boot de la JVM : http://java.sys-con.com/read/45250.htm?CFI...DA111FE3A94B222

Ba moi aussi j'ai personnellement testé eclipse 3.2 sur linux avec un athlon 2000+ avec un projet importer dans CDT, c'etait inutilisable ... De plus au deuxieme lancement de eclipse CDT afficher une erreur sur le panel de droite qui l'empecher d'afficher l'arborescence. Pour ce qui est de la consommation mémoire, je ne suis pas d'accord il est quand meme important de ne pas avoir une appli qui bouffe 250 mo au lieu d'en faire 15.

J'attend toujours une démonstration d'une application rapide/legere et stable.

[lorinc]

la rapidité de dev. java est beaucoup plus rapide à développer que 95% des autres langages d'une part par sa syntaxe très scolaire, et d'autre part par la lib de base qui est extrêmement complète. ça d'un point de vue génie logiciel, ça tue tout.

Après, en terme de perfs, tous les langages se valent quand il s'agit de faire des applis industrielles. Et encore. Perso, je fais mes simulations (calcul scientifque - la vitesse compte beaucoup, donc) en java, et je ne vois pas la différence avec le C++. Cela dit, c'est (encore) vrai que java consomme beaucoup de mémoire.

Java gourmand, oui, mais lent, carément pas...

tu prends l'exemple d'eclipse, fais un petit bench perso : eclipse est intégralement compilable avec gcj (en natif, donc), essaye la version native et la version interprêtée. Si tu vois une différence, tu m'appelles

pour moi, java n'a qu'un seul gros inconvéniant (et de taille), c'est pas ouvert... mais peut-être que ça va changer

[Sentinel]

De toute façon, chaque langage a ses points forts et ses points faibles...

Heureusement, sinon on n'aurait plus qu'un seul et unique langage, ce serait bien triste

Le tout est donc de choisir le bon langage pour la bonne application.

Pour ce qui est des offres d'emploi, Java et .Net sont des valeurs sûres pour l'informatique de gestion, et PHP pour le web, mais il existe des marchés pour des technologies plus confidentielles comme Python, Perl, et même le Cobol.

L'important est donc d'être bon dans son domaine, quel qu'il soit, et il y aura toujours du boulot :)

[KouKaVaniLLa]

Pensez vous que n'ayant jamais programmé, Java soit un bon point de départ ou dois je passer par autre chose ?

Puis qu'il semble que le code soit "scolaire" ?

Et python ? qu'en est il ?

merci

[tsubasaleguedin]

Pensez vous que n'ayant jamais programmé, Java soit un bon point de départ ou dois je passer par autre chose ?

Puis qu'il semble que le code soit "scolaire" ?

Et python ? qu'en est il ?

merci

Python monte pas mal, perso je prefere l'approche objet python

[Sentinel]

Python, excellent langage mais un peu spécial.

Quoi qu'il en soit, si tu choisis Python, apprends aussi Zope.

C'est de plus en plus demandé, certaines boîtes en font même une spécialité.

[lorinc]

en fait, quand je dis "scolaire", je veux dire que ça ressemble au C et que tout le monde apprend le C à l'école...

python est à mon avis un très bon choix pour commencer à apprendre à programmer, car ça t'oblige à faire du code lisible

[KouKaVaniLLa]

Python semble donc abordable pour débuter ....

Est ce multiplateforme ?

[Wooden]

Python semble donc abordable pour débuter ....

Est ce multiplateforme ?

etant interpreté ou semi-interpreté, en principe oui. Pour des platformes exotiques tu peu toujouyrs trouver des ports, il me semble qu'il existe meme une version pour PSP.

Pour ce qui est du Java je ne trouve pas que ça soit si lent que ça surtout vu la vitesse à laquel on peut devel/deployer.

[fabien29200]

Ba moi aussi j'ai personnellement testé eclipse 3.2 sur linux avec un athlon 2000+ avec un projet importer dans CDT, c'etait inutilisable ...

J'ai Eclipse 3.1 sur mon portable Gentoo, 1.3 Ghz, 768 Mo de RAM.

Ca rame pas.

Après Eclipse est logiciel qui marche par plugins ... Si tu installes 2000 plugins qui tournent en même temps, ça va ramer grave !

Mais les avantages de Java viennent en 1er lieu du temps de développement. Un seul fichier de code (et non pas un .c et un .h ), pas d'allocation ni de libération mémoire, pas de gestion de pointeur.

Un grand nombre de frameworks opensources existants pour diminuer le codage (Hibernate ...).

Java est aussi multi environnements. Exemple, tu as une appli de calculs pour les retraites. Tu peux t'en servir aussi bien pour une appli client riche Java et pour le site web. Tu n'auras pas à recoder ton moteur de calcul 2 fois.

Bref, quand tu développes en Java, tu vas vite. Après si pour toi, Java est lent parce que Eclipse rame et un téléphone rame, c'est extrêment léger comme test.

[jromang]

Pour ce qui est des qualités du langage ; le la facilité de developpement, de la robostesse, de la portabilité, c'est clair : java a énormément d'atouts !

Mais (je ne veux pas nourrir le troll) mais quand on parle de *vraies* performances, Java n'a pas sa place. Les arguments du style "java est assez rapide pour une application qui n'a pas besoin de vitesse" vont d'ailleurs en ce sens

Perso, je fais mes simulations (calcul scientifque - la vitesse compte beaucoup, donc) en java, et je ne vois pas la différence avec le C++.

Tu passes a coté de beaucoup d'optimisations en utilisant Java : aucun controle sur la memoire cache, aucun accès aux instructions vectorielles (qui pourraient t'etre d'un grand secours pour du calcul scientifique),... Existe-t-il des outils de profiling en Java ?

Enfin bon : java c'est bien, mais pas pour tout

[uzak]

Pour commencer à programmer, je conseillerais plutôt le C. J'ai appris là dessus et j'en suis plutôt content.

De là à dire pourquoi... je vais essayer.

Tout d'abord, comme le disait lorinc en disant que la syntaxe en java était scolaire, il entendait qu'elle était proche du C, le C est un langage de référence que tout le monde connait. Ensuite, c'est un langage qui colle énormement à l'algorithme. Son côté procédural fait que tu contrôles ton processus. Puis tu as toute la gestion mémoire que tu n'as pas forcément dans d'autres langages, et où tu n'as pas le droit a l'erreur. (que celui qui n'a jamais eu d'erreur de segmentation me jette la bière)

[Baldurien]

PS : personnellement (et je dis ça sans mauvaise foi), j'ai longtemps développé sur mon Pentium2 233, puis sur mon Athlon 700 avec Eclipse. Je n'ai jamais eu de problème d'affichage ou de scrolling... Le fait que je tourne sous Linux, qui gère différemment la mémoire, explique peut-être aussi cette performance.

De toute façon, Eclipse utilise le toolkit graphique natif (win32 sous windows, GTK sous linux, etc), donc son affichage est aussi rapide que n'importe quelle autre application. Vérifie quand même tes pilotes graphiques ?

PS 2 : Un bench qui prend en compte le temps de boot de la JVM : http://java.sys-con.com/read/45250.htm?CFI...DA111FE3A94B222

Ba moi aussi j'ai personnellement testé eclipse 3.2 sur linux avec un athlon 2000+ avec un projet importer dans CDT, c'etait inutilisable ... De plus au deuxieme lancement de eclipse CDT afficher une erreur sur le panel de droite qui l'empecher d'afficher l'arborescence. Pour ce qui est de la consommation mémoire, je ne suis pas d'accord il est quand meme important de ne pas avoir une appli qui bouffe 250 mo au lieu d'en faire 15.

J'attend toujours une démonstration d'une application rapide/legere et stable.

Non. Cherche pas le plugin CDT (si c'est bien le plugin pour faire du C) est lourd. C'est la principale raison pour laquelle je fais du C/C++ sous jEdit (éditeur en java aussi).

Quand on parle de Java, c'est pas significativement moins lent que du C. Même pire : c'est plus rapide.

Lorsqu'elle lit le code, la VM optimise la rapidité. Ce qui rend certaines opérations plus légères. De plus, le mécanisme d'exception est plus léger qu'en C++ (pas besoin de faire un setjmp, etc).

Un des rares défauts de Java est la non prise en charge de l'héritage multiple (je demande pas non plus de l'héritage en diamant, juste de ne pas avoir à réécrire du code, ou passer par un object intermédiaire pour faire ce qui requis par une interface alors que j'hérite déjà d'une clase).

L'autre serait le manque de template (j'aime bien les generics, mais faire une liste d'entiers, revient à faire une liste d'Integer, ce qui n'est pas forcèment très propre) et le manque de typedef (j'aime pas A<? extends C<? extends B>> :))

Pour le reste, la gestion mémoire de Java, même si elle est semble plus rapide est carrément plus lourde que la gestion mémoire du C, surtout quand la VM passe derrière pour essayer de libérer de la RAM sur un programme swappé (ce qui est fun:D)

J'aime bien Java, au niveau objet car il y a de bons trucs (et pas que), mais pas sur tout. Swing sux des ours (autant le dire), les Layout Manager de Swing sux autant des ours, mais surtout la prise mémoire est souvent trop énorme :/ (c'est ce que j'aime le moins, même si j'apprécie le fait de ne pas me soucier de la libération).

Je sais que c'est normal, vu que le gc de Sun cherche des cycles, etc, mais j'aimerai bien pouvoir affiner ça/éviter les lourdeurs. 'fin bref. Par contre : faire des classes anonymes = le pied.

J'aime bien le C, et le C++, car j'apprécie (aime) les templates, la redéfinition d'opérateur, la surcharge prenant en compte le type de retour, et surtout le contrôle de la mémoire.

Bref :)

De toute façon, seul l'assembleur vaut le coup ! :))

[Le Saigneur Sombre]

Pour commencer à programmer, je conseillerais plutôt le C.

Je ne suis pas du tout d'accord. Et pour plusieurs raisons.

Premièrement le C n'oblige pas le programmeur à écrire du code propre :

for(; { if (a=b) break; a--;b--;}

a==0?goto ok:goto erreur;

Deuxièmement C ne contient pas la programmation orienté objet. C++ oui.

Troisièmement, le passage de parametre dans les fonctions ne sont pas particulèrement clair dans le cas de tableau.

void function T (int t[]) { t[0]=123; }

void main() {

int t[2];

t[0]=987;

T(t);

}

La valeur t[0] devrait contenir 987 car le paramètre t est passé par valeur ( pas de pointeur ou de reference). mais t[0] contient 123 car tous les tableaux sont passé par référence.

Et les cast, la déclaration de variable en plein milieu du code...

Pour moi, le meilleur langage pour apprendre a programmer est le PASCAL. Il est objet, strict (pas de cast), défini parfaitement les paramètres des fonctions, la déclaration de variables, etc...

Maintenant, je préfère programmer en C++. C'est un très bon langage, et on peut ecrire des programmes propres avec. Mais rien ne l'oblige...

Pour en revenir au Java, La syntaxe est proche du C++ et les avantages/inconvénients ont été évoqués. Je resterai plus nuancé sur l'héritage multiple. Certes le fait ne pas l'avoir génère du code plus clair, mais oblige à recopier le code.

Je crée 2 classes VehiculeTerrestre et VehiculeMaritime héritant de Véhicule. Je veux crée une troisième classe VehiculeAmphibie (Roulant a la fois sur terre et sur eau). En C++, je peux hériter de VehiculeTerrestre et VehiculeMaritime.

En Java, soit j'herite de Vehicule, soit de VehiculeTerrestre, soit de VehiculeMaritime. Dans tous les cas, recopie de code...

[lorinc]

ratay...

tu créé une classe Vehicule, une interface Terrestre et une interface Maritime.

ta classe VehiculeTerrestre hérite de Vehicule et implements Terrestre et ta classe VehiculeMaritime hérite de Vehicule et implements Maritime.

Quant-à ta classe VehiculeAmphibie, elle hérite bien sûr de Vehicule, mais implements Terrestre, Maritime.

Ne passez pas par la case départ, ne touchez pas 20.000 francs...

java caybien, faut juste apprendre à le maîtriser

[Le Saigneur Sombre]

Certes, les interfaces permettent de palier au manque de l'héritage multiple. Mais par contre, ca oblige bien à redefinir du code dans VehiculeAmphibie que tu as déja écrit pour implementer Terrestre ou implenter Maritime dans les classes associées.

Java c'est bien, mais c'est pas parfait. Pour autant, que l'héritage multiple soit parfait...ce que je ne pense pas.

[Baldurien]

Heu pour le goto en C : n'empêche que pour gérer les cas d'erreurs, ça reste un bon moyen de palier au manque du throw... (ceci étant, fin de ma parenthèse)