Je sais très bien que la technologie Java est présente sur de nombreuses plateformes non supportées par Mono (pour le moment) mais bon. Ce que j'ai voulu dire c'est que de toute façon la portabilité est toute relative, et une application qui tourne sur un PC ne tournera pas forcement sur un PDA, même si c'est sur une JVM de Sun dans tous les cas. Pourquoi ? PArcque les API ne sont pas tous portés, que des API ne sont disponibles que sur certaines plateformes, etc. bref, il faut se limiter aux implentations de bases pour être 100% portable. d'où le terme "relative".
S'il est vrai qu'actuellement J2SE signifie portable, n'oublions pas que les PDAs modernes ont déja des processeurs de plus de 400 MHz, ce qui fait plus que ble PC sur lequel j'ai commencé le Java. A mon avis, il sera bientôt faux de dire que la portabilité est restreinte, à moins bien sûr que ce ne soit le fait volontaire des fabricants de ces engins qui préfèrent brider les utilisateurs en imposant une méthode de téléchargement d'applications payante (ce qui risque fortement de se produire).
(je rajouterai que la portabilité se fait en général au détriment de l'intégration dans l'environnement, autant graphiquement qu'ergonomiquement)
C'est quoi cet argument à la noix non justifié ?
Je croyais avoir définitivement anéanti l'argument "Java c'est moche" ! Bref, piqûre de rappel : http://java.sun.com/products/jfc/tsc/sightings/(...) Et je connais certaines autres applis qui pourraient facilement y figurer ...
En plus, le JDK 1.4.2 amène d'importantes novueautés au niveau L&F qui mettent les applis Java au même niveau que les applis natives.
non non, jes JVM essai de faire du JIT, mais sont toujours obligé de faire de l'interprété pour commencer.
Tu as une preuve de ça ?
D'ailleur le démarrage d'une appli Java donne une idée du travail que doit effectuer la VM derrière ;)
Vachement, ouais, on est toujours dans le même niveau d'argumentaire. La machine virtuelle prend du temps à se lancer, car avant de lancer le programme, elle doit instancier le monde Java : Object, System, Class, ClassLoader et tous leurs petits potes. Après, une fois que l'appli se contente de tourner, ça va mieux. C'est d'ailleurs pour ça que certains JCP s'intéressent à des JVMs serveurs qui ne s'arrêteraient pas vraiment ...
Et celà ne change rien à ce que j'ai dit, le code IL est optimisé pour cette opération, qui est donc faite plus rapidement et sans passer par un système de profiling et d'interprétation.
Je crois que tu as eu assez d'arguments clairs à ce sujet ...
Pour les implentation d'autres langages sur la plateforme Java, je suis tout à fait d'accord que celà est possible. Mais là encore, le bytecode n'a pas été conçu pour, et il existe de nombreuses limitations (le code IL de .NET et Mono en a également je te rassure) et surtout ne définit aucun standard d'implentation qui facile l'interopérabilité entre les langages (tu peux écrire une classe en ADA, l'instancier en Logo et la modifier en Perl sur une machine virtuelle Java ?).
Déja, le faire, tout court, ça me paraît peu évident ;-)
Non, mais d'un auitre côté, quand tu mets un int dans un byte, il faut quand même être un minimum muni d'un cerveau.
Et puis, ce que j'aime bien dans cet article, c'est à quel point il démontre les différences entre Java et C#. C'est effarant de voir à quel point Microsoft a su évoluer depuis la base du VB pour produire une plateforme de qualité ;-)
Pour les métas-données, effectivement elles existent désormais dans Java 5, d'ailleur cette version de Java n'est là que pour rattraper le retard sur C# quand on voit les nouvelles fonctionnalités et pour proposer une implentation bancale des generics. (je ne rentrerais pas dans le débat, c'est très bien expliqué ici : http://www.artima.com/intv/generics.html(...(...)))
Pas besoin, les genercis sont une erreur, une stupidité innomable dont java n'avait pas besoin. En revanche, des choses comme les annotations, l'autoboxing qui apparaît enfin et le remplacement de StringBuffer me paraissent plus intéressantes, mais c'est un autre sujet ...
Tu considère l'ECMA comme étant dirigé par Microsoft (d'ailleur l'ECMA va parfois à l'encontre de Microsoft, un peu comme le java Community Process). Mais si j'en crois toutes les demandes faites à Sun pour libérer Java, j'en déduit qu'il n'est pas si libre que ça ;)
Tu me parles des demandes faites par IBM à SUN pour libérer sa machine virtuelle ? Est-ce que tu es naïf au point de ne pas voir la grossière manoeuvre stratégique ? Si IBM voulait réellement contribuer à une JVM libre, ils pourraient reprendre le projet GNU Classpath, ou d'autres (comme Blackdown, je crois), plutôt que de mendier à Sun la libération de leur travail.
Soyons sérieux cinq minutes. Si tu veux parler des gros sous entre IBM, Sun et Microsoft, pas de problèmes, mais là, ce sera DIFFICILE de ne pas marcher dans le FUD.
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par Nicolas Delsaux . En réponse à la dépêche Mono 1.0 : le singe est laché. Évalué à 3.
Je sais très bien que la technologie Java est présente sur de nombreuses plateformes non supportées par Mono (pour le moment) mais bon. Ce que j'ai voulu dire c'est que de toute façon la portabilité est toute relative, et une application qui tourne sur un PC ne tournera pas forcement sur un PDA, même si c'est sur une JVM de Sun dans tous les cas. Pourquoi ? PArcque les API ne sont pas tous portés, que des API ne sont disponibles que sur certaines plateformes, etc. bref, il faut se limiter aux implentations de bases pour être 100% portable. d'où le terme "relative".
S'il est vrai qu'actuellement J2SE signifie portable, n'oublions pas que les PDAs modernes ont déja des processeurs de plus de 400 MHz, ce qui fait plus que ble PC sur lequel j'ai commencé le Java. A mon avis, il sera bientôt faux de dire que la portabilité est restreinte, à moins bien sûr que ce ne soit le fait volontaire des fabricants de ces engins qui préfèrent brider les utilisateurs en imposant une méthode de téléchargement d'applications payante (ce qui risque fortement de se produire).
(je rajouterai que la portabilité se fait en général au détriment de l'intégration dans l'environnement, autant graphiquement qu'ergonomiquement)
C'est quoi cet argument à la noix non justifié ?
Je croyais avoir définitivement anéanti l'argument "Java c'est moche" ! Bref, piqûre de rappel : http://java.sun.com/products/jfc/tsc/sightings/(...) Et je connais certaines autres applis qui pourraient facilement y figurer ...
En plus, le JDK 1.4.2 amène d'importantes novueautés au niveau L&F qui mettent les applis Java au même niveau que les applis natives.
non non, jes JVM essai de faire du JIT, mais sont toujours obligé de faire de l'interprété pour commencer.
Tu as une preuve de ça ?
D'ailleur le démarrage d'une appli Java donne une idée du travail que doit effectuer la VM derrière ;)
Vachement, ouais, on est toujours dans le même niveau d'argumentaire. La machine virtuelle prend du temps à se lancer, car avant de lancer le programme, elle doit instancier le monde Java : Object, System, Class, ClassLoader et tous leurs petits potes. Après, une fois que l'appli se contente de tourner, ça va mieux. C'est d'ailleurs pour ça que certains JCP s'intéressent à des JVMs serveurs qui ne s'arrêteraient pas vraiment ...
Et celà ne change rien à ce que j'ai dit, le code IL est optimisé pour cette opération, qui est donc faite plus rapidement et sans passer par un système de profiling et d'interprétation.
Je crois que tu as eu assez d'arguments clairs à ce sujet ...
Pour les implentation d'autres langages sur la plateforme Java, je suis tout à fait d'accord que celà est possible. Mais là encore, le bytecode n'a pas été conçu pour, et il existe de nombreuses limitations (le code IL de .NET et Mono en a également je te rassure) et surtout ne définit aucun standard d'implentation qui facile l'interopérabilité entre les langages (tu peux écrire une classe en ADA, l'instancier en Logo et la modifier en Perl sur une machine virtuelle Java ?).
Déja, le faire, tout court, ça me paraît peu évident ;-)
En revanche, je l'ai déja dit, mais par exemple JScheme fournit de très efficaces moyens d'utiliser le Java en Scheme et réciproquement : http://jscheme.sourceforge.net/jscheme/doc/javaprimitives.html(...)
ah bon tu peux faire ca en Java ? : http://www.dotnetguru.org/articles/CSharpVsJava.htm#_D%E9tection_de(...))
Non, mais d'un auitre côté, quand tu mets un int dans un byte, il faut quand même être un minimum muni d'un cerveau.
Et puis, ce que j'aime bien dans cet article, c'est à quel point il démontre les différences entre Java et C#. C'est effarant de voir à quel point Microsoft a su évoluer depuis la base du VB pour produire une plateforme de qualité ;-)
Pour les métas-données, effectivement elles existent désormais dans Java 5, d'ailleur cette version de Java n'est là que pour rattraper le retard sur C# quand on voit les nouvelles fonctionnalités et pour proposer une implentation bancale des generics. (je ne rentrerais pas dans le débat, c'est très bien expliqué ici : http://www.artima.com/intv/generics.html(...(...)))
Pas besoin, les genercis sont une erreur, une stupidité innomable dont java n'avait pas besoin. En revanche, des choses comme les annotations, l'autoboxing qui apparaît enfin et le remplacement de StringBuffer me paraissent plus intéressantes, mais c'est un autre sujet ...
Tu considère l'ECMA comme étant dirigé par Microsoft (d'ailleur l'ECMA va parfois à l'encontre de Microsoft, un peu comme le java Community Process). Mais si j'en crois toutes les demandes faites à Sun pour libérer Java, j'en déduit qu'il n'est pas si libre que ça ;)
Tu me parles des demandes faites par IBM à SUN pour libérer sa machine virtuelle ? Est-ce que tu es naïf au point de ne pas voir la grossière manoeuvre stratégique ? Si IBM voulait réellement contribuer à une JVM libre, ils pourraient reprendre le projet GNU Classpath, ou d'autres (comme Blackdown, je crois), plutôt que de mendier à Sun la libération de leur travail.
Soyons sérieux cinq minutes. Si tu veux parler des gros sous entre IBM, Sun et Microsoft, pas de problèmes, mais là, ce sera DIFFICILE de ne pas marcher dans le FUD.