Alors ça veut dire quoi "100% pur Java" dans ta phrase d'origine ?
Ca veut dire que le programme est écrit entièrement en Java et utilise un toolkit écrit en C. Tu es stupide ou tu le fais exprès ? Tu ne vois pas la différence avec SDL qui propose une api pour les jeux, avec gestion des sprites, etc ? Et donc qu'il y a beaucoup plus de C dans Frozen Bubble Perl que dans la version Java ?
Que vient faire la méthode d'implémentation des bibliothèques natives dans une discussion sur les langages compilés en bytecode ?
Ca commence a devenir clair dans ma tête, tu le fais exprès... Mais comme je suis charitable, je t'explique : si tu utilises une bibliothèque ultra optimisée (SDL) pour faire un jeu, tu peux même l'écrire en tcl, ça ne ramera pas. Alors que faire un jeu dont l'affichage est ultimement géré par motif, ça demande un langage qui tourne correctement.
Oui. Et trouver dans Arkanae une preuve des performances de Java est ridicule. Tu comprends l'analogie ou il te manque encore un bout d'objectivité pour accepter l'évidence ?
Je ne dis pas le contraire, je réponds à l'affirmation stupide que Java ça rame. Il existe des bibliothèques Java qui permettent de faire de la programmation orientée objet en pur Java (pour l'utilisateur de la bibliothèque) tout en obtenant d'excellentes performances. Mais visiblement, tu ne veux pas comprendre, alors bon...
après avoir convenu toi-même que le rendu ne faisait pas partie du langage hôte (puisque réalisé par des bibliothèques natives), tu persistes avec cet argument idiot
Mais tu es vraiment crétin, c'est ça ? Aucun langage autre que le C (et encore), n'utilise le hardware moderne de façon native. Tu es trop bête pour comprendre ça, c'est ça ton problème ? Les drivers sont programmés en C et en assembleur, puis on ajoute une couche du langage cible. C'est la vie.
Actuellement, l'impression de lenteur associée à Java est presque exclusivement liée à trois choses : l'occupation mémoire (vrai problème mais intimement lié à l'aspect très dynamique du langage) qui donne l'impression que ça rame sur une machine avec une mémoire sous dimensionnée, le temps de chargement (lié au fait que Sun n'a toujours par prévu la sauvegarde du code byte compilé pour les bibliothèques de base) et surtout swing. Nous sommes plusieurs a essayer de t'expliquer que swing pose problème, pas Java, avec des exemples de couches d'abstraction mieux conçues comme SWT ou comme Open GL for Java. Mais comme tu te comportes comme un crétin, tu ne veux pas comprendre. J'abandonne.
[^] # Re: 1ère mouture du collecticiel client de OpenOfice.org : Glow
Posté par boubou . En réponse à la dépêche 1ère mouture du collecticiel client de OpenOffice.org : Glow. Évalué à -1.
Ca veut dire que le programme est écrit entièrement en Java et utilise un toolkit écrit en C. Tu es stupide ou tu le fais exprès ? Tu ne vois pas la différence avec SDL qui propose une api pour les jeux, avec gestion des sprites, etc ? Et donc qu'il y a beaucoup plus de C dans Frozen Bubble Perl que dans la version Java ?
Que vient faire la méthode d'implémentation des bibliothèques natives dans une discussion sur les langages compilés en bytecode ?
Ca commence a devenir clair dans ma tête, tu le fais exprès... Mais comme je suis charitable, je t'explique : si tu utilises une bibliothèque ultra optimisée (SDL) pour faire un jeu, tu peux même l'écrire en tcl, ça ne ramera pas. Alors que faire un jeu dont l'affichage est ultimement géré par motif, ça demande un langage qui tourne correctement.
Oui. Et trouver dans Arkanae une preuve des performances de Java est ridicule. Tu comprends l'analogie ou il te manque encore un bout d'objectivité pour accepter l'évidence ?
Je ne dis pas le contraire, je réponds à l'affirmation stupide que Java ça rame. Il existe des bibliothèques Java qui permettent de faire de la programmation orientée objet en pur Java (pour l'utilisateur de la bibliothèque) tout en obtenant d'excellentes performances. Mais visiblement, tu ne veux pas comprendre, alors bon...
après avoir convenu toi-même que le rendu ne faisait pas partie du langage hôte (puisque réalisé par des bibliothèques natives), tu persistes avec cet argument idiot
Mais tu es vraiment crétin, c'est ça ? Aucun langage autre que le C (et encore), n'utilise le hardware moderne de façon native. Tu es trop bête pour comprendre ça, c'est ça ton problème ? Les drivers sont programmés en C et en assembleur, puis on ajoute une couche du langage cible. C'est la vie.
Actuellement, l'impression de lenteur associée à Java est presque exclusivement liée à trois choses : l'occupation mémoire (vrai problème mais intimement lié à l'aspect très dynamique du langage) qui donne l'impression que ça rame sur une machine avec une mémoire sous dimensionnée, le temps de chargement (lié au fait que Sun n'a toujours par prévu la sauvegarde du code byte compilé pour les bibliothèques de base) et surtout swing. Nous sommes plusieurs a essayer de t'expliquer que swing pose problème, pas Java, avec des exemples de couches d'abstraction mieux conçues comme SWT ou comme Open GL for Java. Mais comme tu te comportes comme un crétin, tu ne veux pas comprendre. J'abandonne.