Bon, je vais donc reprendre point par point, mais je ne vais pas te cacher que je préfère Mono à Java, et je ne m'en cache pas vraiment.
la portabilité (toute relative cependant pour les deux plateformes)
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". (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)
On sent que c'est un avantage énorme, effectivement, surtout quand la plupart des JVMs supportent le JIT compiling, qui revient à disposer d'un code ... compilé.
non non, jes JVM essai de faire du JIT, mais sont toujours obligé de faire de l'interprété pour commencer. D'ailleur le démarrage d'une appli Java donne une idée du travail que doit effectuer la VM derrière ;) 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.
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 ?). C'est ce qui fait toute la force de cette plateforme, on utilise une librairie et on se moque complètement du langage dans lequel il a été développé, sans faire aucun binding. (les bindings ne sont utiles que pour utiliser du code natif).
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(...))
Tu peux être plus explicite sur la simplicité d'utilisation du C ? Ca me laisse pantois !
J'ai peut être mal formulé ma phrase, je voulais dire la simplicité d'utiliser un API écrit en C depuis la plateforme Mono, notamment en C#.
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 ;)
Et OUI, j'ai attaqué Java, parcque dans le domaine Java a plus ou moins le monopole (question plateforme complète) et Mono se présente comme une alternative libre qui respecte des standards, et qui apporte quelques innovations qui ont l'avantage de faire bouger les 2 parties, vive la concurrence et longue vie aux 2 plateformes.
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (site web personnel) . En réponse à la dépêche Mono 1.0 : le singe est laché. Évalué à 5.
la portabilité (toute relative cependant pour les deux plateformes)
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". (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)
On sent que c'est un avantage énorme, effectivement, surtout quand la plupart des JVMs supportent le JIT compiling, qui revient à disposer d'un code ... compilé.
non non, jes JVM essai de faire du JIT, mais sont toujours obligé de faire de l'interprété pour commencer. D'ailleur le démarrage d'une appli Java donne une idée du travail que doit effectuer la VM derrière ;) 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.
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 ?). C'est ce qui fait toute la force de cette plateforme, on utilise une librairie et on se moque complètement du langage dans lequel il a été développé, sans faire aucun binding. (les bindings ne sont utiles que pour utiliser du code natif).
Ben .. ça existe depuis un bon moment en Java, [détection de déblordement]
ah bon tu peux faire ca en Java ? : http://www.dotnetguru.org/articles/CSharpVsJava.htm#_D%E9tection_de(...)
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(...))
Tu peux être plus explicite sur la simplicité d'utilisation du C ? Ca me laisse pantois !
J'ai peut être mal formulé ma phrase, je voulais dire la simplicité d'utiliser un API écrit en C depuis la plateforme Mono, notamment en C#.
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 ;)
Et OUI, j'ai attaqué Java, parcque dans le domaine Java a plus ou moins le monopole (question plateforme complète) et Mono se présente comme une alternative libre qui respecte des standards, et qui apporte quelques innovations qui ont l'avantage de faire bouger les 2 parties, vive la concurrence et longue vie aux 2 plateformes.