JAVA SUX ! - Page 1

J'en ai raz la casquette des gens qui me disent que java ça pewtr tout ça...

Java c'est bon à faire un hello world et point barre.

Au taff, je bosse sur un proto web (spectras l'a déjà vu) d'une appli anciennement en client lourd. Le proto représent 6 à 7% de l'appli totale, grand maximum. Après avoir fait le proto en mode activex, le client a demandé une génération en java du proto. Eh bah ça marche pas, et après avoir cherché dans tous les sens on a trouvé. Le code, y'en a trop pour le pov ti chéri de compilo de merde de java. Y'a un fichier (un seul...) .JAVA qui fait 3Mo et ça y'est c'est fini c'est incompilable. Y'a un total de ~15Mo de sources .JAVA à compiler, et le compilo y arrive pas, c'est trop gros.

Ca fait chier bordel !

Pour info, la techno "source" (celle utilisée pour le client lourd) autorise des trucs bien plus déments que ça... (On voit fréquement des projets avec plus de 300Mo de source de code et ça pose pas de problème à la génération) mais là pour un pov proto qui fait 9,5Mo dans le langage propriétaire (15Mo une fois converti en java) le compilo java veut rien savoir parcque c'est trop gros pour lui...

JAVA, une nouvelle techno, pour les machines du futur, avec des projets de la taille de ceux qu'on a vu au début de l'ère informatique...

(parcqu'en plus ça rame et les performances des applis générées sont détérioriées)

voilà c'était mon cdg contre java

si l'un d'entre vous reprends java à son compte, de grâce qu'il fasse en sorte qu'on puisse générer les applis professionnelles.

dire que je vais peut être devoir apprendre ça l'année prochaine

bah saches que ce langage est limité et c'en est pathétique.
perso ça me fout hors de moi de voir le temps que j'y ai perdu pour... ...rien

-

boah ... moi j'm bien l'esprit de java ... par contre c kel compilo ?

javac

Orion_ :
ouééééééé java suxxxxxxx !!!!!!!!!

euh tes trolls pourris tu tes le carre au cul, à moins que t'aies des arguments pour en causer...

-

Euh c'est une limitation de l'implémentation que tu utilises ça, pas de Java lui-même... ou alors j'ai rien compris à ce que tu dis

moi, tout ce que je peux dire c'est que chaque fois que j'ai eu à utiliser ce compilo (celui de sun) je l'ai trouvé assez lent
mais je n'ai jamais eu de problème de ce type, faut dire que le plus gros truc que j'ai écrit c'était genre 50ko de sources

par contre cgd contre ce langage et cette api que je trouve trop confus pour un système si répandu, de plus les perfs sont extrèmement inégales suivant la plateforme (genre java2d qui raaame sous linux, meme avec une bonne config)
(des trucs qu'on peut admettre pour ocaml ou d'autres langages peu répandus ou académiques mais vu le nombre d'utilisateurs de java >_<)

sinon, si tu veux expérimenter un compilateur + langage et syntaxe infames pour comparer, regarde du coté de ada+gnat

Je trouve que le langage Java est plutôt bien foutu.
À part quelques trucs dont j'ai l'impression qu'ils sont sales : par exemple le fait que certaines classes (Throwable, String, ...) sont traitées différemment par le langage lui-même alors qu'elles sont implémentées sur ce langage (je ne sais pas si c'est très clair : c'est comme si un compilo C++ traitait différemment la classe std::string).

vince
: Y'a un fichier (un seul...) .JAVA qui fait 3Mo

mais il fait combien de ligne de code ce fichier ?
Ca a l'air vraiment bourrin...

Java ça poutre, car plus besoin de ce faire chier avec des pointeurs à la con qui envoie dans le décor la plupart des programmes et qui font des buges à retardement. De mon expérience, je passe au moins deux fois moins de temps à débugger un programme java qu'un programme C.

Le seul inconvénient que je vois à Java, c'est que c'est hyper lent............

le fichier fait environ 58000 lignes

en fait il était plus gros avant mais une misfeature de l'interpréteur nous empêche de débugger les fichiers de plus de 64635 lignes.

pas mal "misfeature" comme terme

c'est pas un bug, c'est une limitation dérangeante...

vince :
le fichier fait environ 58000 lignes

en fait il était plus gros avant mais une misfeature de l'interpréteur nous empêche de débugger les fichiers de plus de 64635 lignes.

ca me parait vraiment énorme.... j'ai pas beaucoup d'expérience de codeur, mais même si il n'y a que la moitié de ligne de vraie code, comment peut-on s'y retrouver ? Y'aurait pas un pb de conception à la base, de modularité ?

Et si il l'autre moitié correspond aux commentaires, c'est pas dans la source qu'il fallait mettre tout ca, mais dans une espece de "rapport d'implémentation"...

hibOu :
plus besoin de ce faire chier avec des pointeurs à la con qui envoie dans le décor la plupart des programmes et qui font des buges à retardement.

le ramasse-miettes, l'allocation et tout j'aime bien

Pour le .java de 3Mo, je me demande si tu n'as pas programmé avec des habitudes du C (je veux dire peu de subdivision (enfin c'est ce que je crois ), un peu contraire aux "principes" du java)

Pour la lenteur, j'en fais depuis trop peu de temps, je n'ai pas encore vu.

Par contre ce qui me déplait un peu, c'est que ce soit une société en particulier qui le fasse et qui force tous les compilateurs externes à suivre _leur_ norme (qui peut changer), enfin quoique c'est peut-être normal

11> que veux-tu dire ? que toString() est automatiquement appelé en cas de besoin par exemple ?

Dans le code d'origine (qui n'est pas en java mais dans un langage appelé NCL), y'a environ 8Mo de Code pur, 1,5Mo de commentaires.

Le compilo NCL2JAVA génère les sources java à partir du référentiel d'origine (ce qui a pour effet de le faire enfler jusqu'à ~15Mo, à peu près la même chose que si on prends une cible activex compilée avec NCL2C puis MSVC6) et est ensuite compilée avec javac, lequel se vautre minablement.

un référentiel de 9Mo c'est petit, c'est pas pour rien que ce projet n'est qu'un proto*. la plupart de nos client ont des référentiels qui se mesurent en centaines de Mo. sauf que la génération en java, vu que personne n'y croyait, personne n'utilisait..

(*) comme dit dans mes précédents posts, le code de l'appli complète est de 12 à 15 fois plus gros, et le développement d'origine en client lourd ne représentait pas plus de 12-15 années hommes...

nTOME
: Par contre ce qui me déplait un peu, c'est que ce soit une société en particulier qui le fasse et qui force tous les compilateurs externes à suivre _leur_ norme (qui peut changer), enfin quoique c'est peut-être normal

C'est pas aussi simple que ca. Sun n'a pas un assez grande emprise pour se la jouer à la Microsoft. Sun laisse un peu de controle (pas tout bien sûr, pas fous non plus) sur Java par l'intermédiare des JCP. Voir aussi les JSR sur le site de Sun.

vince :
Dans le code d'origine (qui n'est pas en java mais dans un langage appelé NCL), y'a environ 8Mo de Code pur, 1,5Mo de commentaires.

Le compilo NCL2JAVA génère les sources java à partir du référentiel d'origine (ce qui a pour effet de le faire enfler jusqu'à ~15Mo, à peu près la même chose que si on prends une cible activex compilée avec NCL2C puis MSVC6) et est ensuite compilée avec javac, lequel se vautre minablement.

un référentiel de 9Mo c'est petit, c'est pas pour rien que ce projet n'est qu'un proto*. la plupart de nos client ont des référentiels qui se mesurent en centaines de Mo. sauf que la génération en java, vu que personne n'y croyait, personne n'utilisait..

(*) comme dit dans mes précédents posts, le code de l'appli complète est de 12 à 15 fois plus gros, et le développement d'origine en client lourd ne représentait pas plus de 12-15 années hommes...

certes, mais il y a une différence entre le total des sources qui fait 100 Mo (tout à fait concevable pour un grosse appli, j'avais même entendu que pour les sources de Windows on parlait en Go), et un seul fichier source qui approche les 10Mo...

y'a pas de notion de fichier source en ncl en fait. c'est un référentiel, contenu dans une espèce de bdd, multiutilisateur multimachines... y'a qu'au moment de la génération puis de la compilation que des fichiers sont créés. Mais il sont des choses qui sont indivisibles. Exemple simple, (en client serveur avec applet), ton applet doit afficher des données, il faut bien les récupérer en base, pour cela tu fais un appel remote pour exécuter 1 requète sql (1/4 de requète sql n'ayant pas de sens, c'est donc bien indivisble) bon et bien si ta requète fait à elle toute seule dans les 15-20ko, le corps de ta fonction remote fera au minimum cette taille, c'est incompressible. Ensuite (et c'est surtout vrai pour les éléments d'architecture) certains éléments DOIVENT être dans la même librairie, exemple simple là encore, ta fenêtre CUA et sa barre d'outils se doivent d'être à proximité, les éloigner augmenterait le volume de code pour la liaison (on pense par exemple au bouton quitter qui se trouve dans la barre d'outils et qui est censé appeler les événements de cloture sur la fen^tre mère)

etc etc...

ok, en fait ces sources n'ont pas été concues pour la techno objet à la Java puisqu'elles ont été faites en ncl.
effectivement, c'est balo que javac se vautre...

Mais Java ca poutre quand même !

enfin c'est quand même des classes avec des variables des méthodes de l'héritage... t'as une gestion avancée et simplifiée des sgbd, tu peux aussi gérer tes scénarii coder avec des modèles, des triggers, éditer tes écrans en wywsiwyg... l'interface fait peut-être un peu vieillote mais t'as plus de fonctionalités que éclipse (par exemple)

je as p-e raison, je connais pas du tout ncl...
D'apres ce que tu me racontes, je vois juste que le code est "découpé" différement suivant ncl et Java. Pour Java l'idée est une classe (objet) par fichier, et ncl c'est..... ben cf le post 21.

si un jour tu viens à un open, n'hésite pas à demander une démo

ok, merci

ça me tente bien aussi, mais un open ...

espèce d'orion !!!


pour info : javac -J"-mx512m" foo.java
permet d'aller un peu plus loin.

Bon remerde, si qqn sait comment résoudre ce problème : "too many constants"

Il n'y en a que 900 dans la classe qu'il ne veut pas compiler c'est pas la mort non plus...