Non, P90 avec 32Mb de RAM, sous Win98 en plus. C'est du vécu, j'ai fait tourner une GUI au dessus d'une DB Oracle qui se constituait à partir d'un fichier de description en XML. Il est actuellement impossible d'en faire autant en Java, même si j'aurai préféré utiliser JDBC pour développer ce truc.
> je sais pas si t'es au courrant mais le langage on s'en fout un peu
Ah, bon, excuse-moi, tu sembles être beaucoup plus au courant que moi de la chose.
> c'est la plateforme qui est importante
Oh, me voilà renseigné alors.
> sache que tout de meme en Java on peut ecrire avec une floppé de langages divers et qui produisent tous de bytecode
Bien. J'ai un pote qui travaille chez BEA, un autre chez IBM, un au W3C, un qui s'occupe de SVG, et je bosse pour une boite qui fait des composants Java depuis 97. C'est curieux, mais à part jython dont on a vaguement parlé mais qu'ils n'ont jamais utilisé dans le cadre professionel, ils programment tous en Java, et ils surveillent de prêt l'évolution du langage lui-même.
La "plateforme Java", c'est tout ce qui s'est construit au dessus : JDBC, JEE, etc... (je m'y perds dans tout ces acronymes). Les langages qui compilent vers du byte-code Java n'ont pour le moment aucune existence dans l'industrie.
> Je t'en veux pas car 50% des personnes qui sont "contre java"
Mais qu'est-ce qui te fais croire que je suis "contre Java" ?? Je suis pour, vivement que ça marche sur le desktop. J'ai juste un peu plus que toi la tête sur les épaules.
> >prédilection de Java est plutôt du coté serveur :-).
> Tout a fait, mais l'une des principale raisons est tout autre : jusqu'a present installer une appli Java cliente c'etait le mal de tete assuré
Non, rien à voir. Pour un serveur les perfs sont moins importantes que sur le desktop, parce qu'il suffit de prendre une machine plus grosse pour les augmenter, ou d'en mettre en parallèle, ce que Java sait bien gérer. C'est un coup fixe, connu, alors que celui de debugger un serveur écrit en C ou C++ ne l'est pas. Mais tu ne peux pas faire ça pour une appli desktop, upgrader 1 machine ça passe, 150 non.
Ensuite l'autre raison c'est que décompiler une appli Java est trivial, et pour faire une appli commerciale avec du bon vieux code proprietaire qui va vérifier sa licence au lancement, ça craint. Tu peux toujours utiliser un offuscateur de code, mais ça complique pas mal le développement parce que ça apporte son lot de problèmes. J'en sais quelque chose, le chef d'équipe dans le bureau à coté du mien en a régulièrement.
> Parce que tu crois que patcher la lib de Qt pour corriger un bug c'est facile
Toujours plus facile qu'une JVM. C'est pas la même complexité.
> Ben si tu crois encore que java n'est qu'un langage, de plus hyper lent et qui sert à rien d'autre qu'a faire plaisir à des techos de bas etages pas capable d'ecrire une ligne de bon vieux KR-C ou d'ASMx86 alors je crois que j'ai ma reponse
Relis ce que tu as dit : si je trouve que Java a besoin d'être amélioré, y a qu'a logger une JSR. Cool. C'est comme si je te disais que si C++ ne te plait pas, tu n'as qu'a ouvrir un defect au C++ committee. Et strictement parlant c'est vrai, la spec C++ est ouverte aussi (même plus). Le pb c'est que c'est une procédure qui prend des années, et reservée à un petit nombre de gens qui ont du temps à y consacrer.
Qu'est-ce que je dois mettre dans ma JSR pour dire "je veux de meilleures perfs" ?
Et pour info, non, je ne considère pas que Java soit un language hyper-lent, etc... Sors toi de tes clichés.
> c'est clair que c'es pas si simple
Content que tu t'en rendes compte.
> mais l'avantage c'est que les elus (tu peux te presenté à l'election si tu le desirent... je sais plus quand est la prochaine ...) eux peuvent faire avancer les specs ...
Les utilisateurs font aussi avancer Qt sinon la librairie n'aurais pas la qualité qu'elle a actuellement. Qt est plein de patches de gens externes à TT, souvent revus par TT pour s'assurer de la qualité. Par exemple le support des fonts antialiasés ne vient pas d'eux au départ.
> Et enfin, la fameuse Genericité que meme le pere de Java refusait ... et bien la JSR l'a adopté et l'intégration dans le langage est en cours et la sortie est pour le 1.5
Je sais, mais il semble que l'implémentation ne soit pas si géniale :
[^] # Re: Emmm qqe correctifs :
Posté par Guillaume Laurent . En réponse à la dépêche Interview du president TrollTech. Évalué à 9.
Non, P90 avec 32Mb de RAM, sous Win98 en plus. C'est du vécu, j'ai fait tourner une GUI au dessus d'une DB Oracle qui se constituait à partir d'un fichier de description en XML. Il est actuellement impossible d'en faire autant en Java, même si j'aurai préféré utiliser JDBC pour développer ce truc.
> je sais pas si t'es au courrant mais le langage on s'en fout un peu
Ah, bon, excuse-moi, tu sembles être beaucoup plus au courant que moi de la chose.
> c'est la plateforme qui est importante
Oh, me voilà renseigné alors.
> sache que tout de meme en Java on peut ecrire avec une floppé de langages divers et qui produisent tous de bytecode
Bien. J'ai un pote qui travaille chez BEA, un autre chez IBM, un au W3C, un qui s'occupe de SVG, et je bosse pour une boite qui fait des composants Java depuis 97. C'est curieux, mais à part jython dont on a vaguement parlé mais qu'ils n'ont jamais utilisé dans le cadre professionel, ils programment tous en Java, et ils surveillent de prêt l'évolution du langage lui-même.
La "plateforme Java", c'est tout ce qui s'est construit au dessus : JDBC, JEE, etc... (je m'y perds dans tout ces acronymes). Les langages qui compilent vers du byte-code Java n'ont pour le moment aucune existence dans l'industrie.
> Je t'en veux pas car 50% des personnes qui sont "contre java"
Mais qu'est-ce qui te fais croire que je suis "contre Java" ?? Je suis pour, vivement que ça marche sur le desktop. J'ai juste un peu plus que toi la tête sur les épaules.
> >prédilection de Java est plutôt du coté serveur :-).
> Tout a fait, mais l'une des principale raisons est tout autre : jusqu'a present installer une appli Java cliente c'etait le mal de tete assuré
Non, rien à voir. Pour un serveur les perfs sont moins importantes que sur le desktop, parce qu'il suffit de prendre une machine plus grosse pour les augmenter, ou d'en mettre en parallèle, ce que Java sait bien gérer. C'est un coup fixe, connu, alors que celui de debugger un serveur écrit en C ou C++ ne l'est pas. Mais tu ne peux pas faire ça pour une appli desktop, upgrader 1 machine ça passe, 150 non.
Ensuite l'autre raison c'est que décompiler une appli Java est trivial, et pour faire une appli commerciale avec du bon vieux code proprietaire qui va vérifier sa licence au lancement, ça craint. Tu peux toujours utiliser un offuscateur de code, mais ça complique pas mal le développement parce que ça apporte son lot de problèmes. J'en sais quelque chose, le chef d'équipe dans le bureau à coté du mien en a régulièrement.
> Parce que tu crois que patcher la lib de Qt pour corriger un bug c'est facile
Toujours plus facile qu'une JVM. C'est pas la même complexité.
> Ben si tu crois encore que java n'est qu'un langage, de plus hyper lent et qui sert à rien d'autre qu'a faire plaisir à des techos de bas etages pas capable d'ecrire une ligne de bon vieux KR-C ou d'ASMx86 alors je crois que j'ai ma reponse
Relis ce que tu as dit : si je trouve que Java a besoin d'être amélioré, y a qu'a logger une JSR. Cool. C'est comme si je te disais que si C++ ne te plait pas, tu n'as qu'a ouvrir un defect au C++ committee. Et strictement parlant c'est vrai, la spec C++ est ouverte aussi (même plus). Le pb c'est que c'est une procédure qui prend des années, et reservée à un petit nombre de gens qui ont du temps à y consacrer.
Qu'est-ce que je dois mettre dans ma JSR pour dire "je veux de meilleures perfs" ?
Et pour info, non, je ne considère pas que Java soit un language hyper-lent, etc... Sors toi de tes clichés.
> c'est clair que c'es pas si simple
Content que tu t'en rendes compte.
> mais l'avantage c'est que les elus (tu peux te presenté à l'election si tu le desirent... je sais plus quand est la prochaine ...) eux peuvent faire avancer les specs ...
Les utilisateurs font aussi avancer Qt sinon la librairie n'aurais pas la qualité qu'elle a actuellement. Qt est plein de patches de gens externes à TT, souvent revus par TT pour s'assurer de la qualité. Par exemple le support des fonts antialiasés ne vient pas d'eux au départ.
> Et enfin, la fameuse Genericité que meme le pere de Java refusait ... et bien la JSR l'a adopté et l'intégration dans le langage est en cours et la sortie est pour le 1.5
Je sais, mais il semble que l'implémentation ne soit pas si géniale :
http://www.beust.com/cedric/javaone-2001.html(...)
Ils n'ont fait que rajouter un typage plus fort mais sans supprimer la nécéssité de downcaster.
Par contre Gosling parlait d'ajouter l'overloading d'operateur il y a longtemps
http://java.sun.com/people/jag/FP.html#overloading(...)
on dirait que c'est enterré, dommage.