JAVA SUX ! - Page 2

Tu as essayé autre chose que javac ?

oui, ça a été pire. (JVC et SJ)

Demande a smeet (par email car il peut plus aller sur yn a partir du boulot). Il connait java je crois

Bon bah j'ai l'info que je cherchais : 64ko de constantes maxi.

sauf que ce batard compte les images comme des constantes...

faut pas des grosses images alors

256*256 maxi.

faudra trouver une solution miracle d'ici la fin du projet, mais ça sera pas moi qui m'en occuperais

putain c'est la fête

j'ai une fonction dont la conversion de l'en-tête fait 92ko à elle toute seule (SANS le code après on est d'accord) je fais comment pour qu'elle fasse moins de 64ko

Vous avez un code de bourrin quand meme...

Ben c'est un systeme de convertion automatique d'un truc pas tres oriente objet en java.
Ca m'etonne pas que ca se vautre completement

Sasume & PpHd > Le soucis c'est que dans des trasnactions client-serveur, faut bien plier-déplier les paramètres. Et le stub* correspondant au pliage de deux segments fait 90ko a lui tout seul.

En creusant j'ai trouvé que la méthode qui pose problème (java refuse de dire laquelle ça serait trop simple c'est pas pour rien que java sux) fait 137880octets, mais il m'a fallu installer le JRE 1.5 pour ça, JRE qui est encore en version béta...

(*) ça risque de faire revenir K² ça non ?

le 1.5 n'est plus en béta depuis au moins 3 mois.
Ils ont même sorti une version 1.5.0_01 recement

possible

toujours est il que JRE est pas foutu de me dire quelle méthode lui pose problème.

et dans le .CLASS qu'il m'indique, aucune entité ne dépasse les 64ko (le .class ne faisant que 224 malheureux ko)

vince :
perso ça me fout hors de moi de voir le temps que j'y ai perdu pour... ...rien

Les connaissances acquises dans l'apprentissage d'un langage ne sont jamais perdues (sauf peut être pour le COBOL - et je blague, bien sûr).

Java ne sucks pas vraiment. Je ne l'utiliserait pas pour coder une application système, pour des questions de performances (pas plus que je n'utiliserais le .net d'ailleurs), mais c'est un langage clean qui fait très bien le travail pour des applications du côté client.

vince :
(*) 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...

Dans mon livre de gestion (de m...) un projet de plus de 8.3333... années-personne est considéré comme un très grand projet. Cela dit, c'est un cours de m...

De toute façon, un .java de 15Mo c'est énorme. Décider de convertir un projet en Java en dumpant dans une seule classe tout le stuff, c'est pas très fort comme type de conversion. Je suis persuadé que ce convertisseur ne doit pas produire un code très lisible (lire impossible à maintenir).

Cependant, je trouve inaceptable qu'un compilateur impose une limite de la sorte, ça manque de sérieux. C'est une chose mauvaise.

tu te rends pas compte à quel point connaître le COBOL c'est utile de nos jours. Beaucoup d'entreprises recherchent cette compétence et quasiment plus aucun jeune ne l'a.

Crayon microbug, pascrayon quesoft.

15 années hommes, c'est "commun" dans le monde de l'info de gestion. un gros projet tournera dans 200-300 années hommes en général développé/maintenu un peu moins d'une dizaine d'année pour une équipe dont la moyenne tournait autour des 30-40 personnes...

j'ai rien appris en java de plus ce que je savais déjà, ça se résume en peu de mots : c'est de la merde.

les perf ne sont pas au rendez vous, ça c'est vrai, mais le travail coté client est loin d'être clean...

j'ai pas parlé de 15 mais de 3 Mo, ce qui suppose tapper une moyenne de 2 ou trois carac à la minute, ça reste humain...

ensuite un segment métier qui contient 80-100 variables, il faut que tu le transmette au serveur, on va compter environ 300 octet de java pour une variable (bah oui, dans les autres langages tu peux transférer une zone mémoire, mais en java spa possible, faut se le tapper variable par variable, idem quand tu veux réinit ton segment, là où un FILL suffisait tu te tappes N lignes, N=le nombre de variables), et hop, on a déjà, pour un seul segment métier, 30ko de code. Pour l'envoi, y'a la récupération après traitement serveur, rebelotte (à ce point on a déjà explosé les 64ko) mais faut le code applicatif derrière, et puis la fonction serveur qu'on appelle a sans doute besoin de plusieurs segments, cette taille est incompressible...

Le code du convertisseur, même moi qui n'y connais pas grand chose à java, je le comprends. il esdt indenté, commenté, structuré.

La limite est imposée par SUN (et autres équivalent) il n'y a que dans le runtime 1.5 que tu peux aller jusqu'à ~90ko (pour le binaire, la limite à 64ko de source reste présente) pour une méthode.

Microbug :
tu te rends pas compte à quel point connaître le COBOL c'est utile de nos jours. Beaucoup d'entreprises recherchent cette compétence et quasiment plus aucun jeune ne l'a.

Je suis bien placé pour le savoir, je travaille sur les mainframes. Fortran et PL/I manquent toujours à ma culture, mais, à l'instar de COBOL, c'est des trucs d'appl prog anyway. C'est justement mon point d'ailleurs : connaître un nouveau langage c'est toujours une bonne chose. Pour la connaissance du java, sachez que c'est aussi une compétance assez recherchée : les applets sont toujours aussi populaires sur les frontends web de nos BD.

vince :
Crayon microbug, pascrayon quesoft.

15 années hommes, c'est "commun" dans le monde de l'info de gestion. un gros projet tournera dans 200-300 années hommes en général développé/maintenu un peu moins d'une dizaine d'année pour une équipe dont la moyenne tournait autour des 30-40 personnes...

J'ai dit que c'était un cours de m... Je n'étudie pas en gestion.

vince :
ensuite un segment métier qui contient 80-100 variables, il faut que tu le transmette au serveur, on va compter environ 300 octet de java pour une variable (bah oui, dans les autres langages tu peux transférer une zone mémoire, mais en java spa possible, faut se le tapper variable par variable, idem quand tu veux réinit ton segment, là où un FILL suffisait tu te tappes N lignes, N=le nombre de variables), et hop, on a déjà, pour un seul segment métier, 30ko de code. Pour l'envoi, y'a la récupération après traitement serveur, rebelotte (à ce point on a déjà explosé les 64ko) mais faut le code applicatif derrière, et puis la fonction serveur qu'on appelle a sans doute besoin de plusieurs segments, cette taille est incompressible...

Je suis pas sûr d'avoir bien saisi : le segment métier, c'est les 'sets' de données qui vont du serveur au client ? En java, on peut envoyer des instances de classes par le biais de la sérialisation, donc pas besoin de déplacer les données une par une. Dans ton cas, j'avoue que c'est pas pratique, car le serveur à l'autre bout ne peut pas 'désérialiser' les objets.

vince :
Le code du convertisseur, même moi qui n'y connais pas grand chose à java, je le comprends. il esdt indenté, commenté, structuré.

Et le programme dans son ensemble, est-ce qu'il est compréhensible pour un programmeur ? (une question, pas un troll)

vince :
La limite est imposée par SUN (et autres équivalent) il n'y a que dans le runtime 1.5 que tu peux aller jusqu'à ~90ko (pour le binaire, la limite à 64ko de source reste présente) pour une méthode.

Comme je l'ai déjà dis, ça sucks en effet, s'ils n'ont pas de bonnes raisons.

Il y a une multitude de langages parce qu'il y a une multitude de besoins différents et qu'aucun langage ne peut les satisfaire tous.

Quand on fait du Java, il programmer de manière différente qu'en C. Entre autre, on doit exploiter le paradigme OO pour développer nos applications (un programme est un ensemble d'objets qui communiquent entre eux par l'envoi de messages et blablabla). Ensuite, ne on roule pas natif, ça entraîne des considérations différentes coté questions de rapidité d'exécution.

Erreur de post....

Perso j'ai fait un an de cobol en IUT, puis 4 mois en stage. Et j'aimerais bien en refaire au moins au début de ma carrière

Pour répondre à ton non-troll, à ceci près que c'est du java, ça reste clair.

Microbug :
Perso j'ai fait un an de cobol en IUT, puis 4 mois en stage. Et j'aimerais bien en refaire au moins au début de ma carrière

Tous les goûts sont dans la nature à ce que je vois. Quant à moi, j'ai vraiment détesté faire du COBOL à l'école (surtout quand on a été forcé d'utiliser le générateur de rapport), mais je ne suis pas mécontent de l'avoir appris.

vince :
Pour répondre à ton non-troll, à ceci près que c'est du java, ça reste clair.

Ok. Surprenant quand même

Franchement je voudrais pas faire mon troll mais un seul fichier .java de 3 Mo c'est débile sachant que java a une structure modulaire. Normalement faut une classe par fichier hein... me fais pas croire que c'est pas possible de diviser ton monstre en classes compilables

A moins que ce fichier unique soit une requête du client, le débile c'est l'auteur de la source, c'est pas le compilo

Juste par curiosité: une source de C de 3 Mo, GCC, il en fait quoi?
et justement gcc-java, t'as essayé? (pas tout lu les posts kilométriques x_x)

ensuite un segment métier qui contient 80-100 variables, il faut que tu le transmette au serveur, on va compter environ 300 octet de java pour une variable (bah oui, dans les autres langages tu peux transférer une zone mémoire, mais en java spa possible, faut se le tapper variable par variable, idem quand tu veux réinit ton segment, là où un FILL suffisait tu te tappes N lignes, N=le nombre de variables), et hop, on a déjà, pour un seul segment métier, 30ko de code. Pour l'envoi, y'a la récupération après traitement serveur, rebelotte (à ce point on a déjà explosé les 64ko) mais faut le code applicatif derrière, et puis la fonction serveur qu'on appelle a sans doute besoin de plusieurs segments, cette taille est incompressible...

et la sérialisation, tu connais?

Note: ynReplace(all, -débile +pastrèsmalin)

squalyl^2
:(pas tout lu les posts kilométriques x_x)

cf posts ~ ./21 et plus

squalyl^2 : si t'avais lu tu saurais que je n'ai pas la main sur le JAVA qui est généré à la volée, et non les classes ne sont pas divisibles...

En effet il faudrait rennomer ton topic en "générateur de code bourrin sux"

ok et merci pour la précision. désolé d'avoir fait le boulay

Uther :
En effet il faudrait rennomer ton topic en "générateur de code bourrin sux"

non plus...

faudrait un smiley #lisez bordel de merde#

Je le dis haut et fort, tout le reste pu, il n'y a que JAVA de vrai (Non, non ce n'est pas ironique!)

Faut juste avoir un minimum de connaissances en java pour savoir que le compilo de Java n'est pas fait pour compiler 1 fichier de 70000 lignes quoique je trouve ca tres bizarre, puisque je compile sans problème un fichier de 10000 lignes avec eclipse sans que ca me prenne plus d'une seconde! sur un P4 2ghz et 1go de RAM.

Je n'ai jamais vu d'IDE qui arrive à la cheville d'eclipse au passage (je ne parle pas du RAD Visual Editor puisque je trouve qu'un RAD ca ne sert à rien...)


Puis faut le dire NCL2Java te converti du code en java, mais as-tu jeté un coup d'oeil pour voir ce qu'il te génère?!
Le langage Java est fait pour développer des projets composés de classes multiples non pas d'un gros fichier.

Le projet sur lequel je travaille est composé 800 fichiers donc au moins autant de classes, et un équivalant de 120 000 lignes de code (9 mois de travail pour arriver à ça, soit 180 jours, je suis le seul développeur sur ce projet), et pour être clair pour recompiler tout le projet après un nettoyage des fichiers classes, ca met 5 à 10 secondes (Je dis ca parce que la compilation incrémentielle d'eclipse permet de ne meme pas avoir à besoin de lancer de compilation manuellement...), donc je ne trouve pas ca lent!

Si java se trouve aujourd'hui dans 100% des entreprises du CAC40, soit ils sont vraiment con, soit il y a une bonne raison.

PS: Si tu veux voir de gros projets déployés en Java, vas voir cette page: http://weblogs.java.net/blog/hansmuller/archive/2005/06/javaone_desktop.html

alexis :
Je n'ai jamais vu d'IDE qui arrive à la cheville d'eclipse au passage (je ne parle pas du RAD Visual Editor puisque je trouve qu'un RAD ca ne sert à rien...)

Netbeans 4.1 ? (eclipse j'avais pas accroché)

Ouais enfin eclipse est ptet bien mais sans plugins c'est tout de suite beaucoup moins bien hein...

ensuite j'ai jamais vu un autre ide partir en live sans raison (genre il se met à chier l'auto correction à priori c'est un bug connu lié +/- directement à la compil incrémentale)...

squalyl^2
:

alexis :
Je n'ai jamais vu d'IDE qui arrive à la cheville d'eclipse au passage (je ne parle pas du RAD Visual Editor puisque je trouve qu'un RAD ca ne sert à rien...)

Netbeans 4.1 ? (eclipse j'avais pas accroché)

Clairement, 1000 fois mieux pour du J2EE ou J2ME. Sont plus gros problème est que ça rame (Swing ne peut pas suivre SWT sur lequel est basé Eclipse).