Mono implémente une VM, plus les 3 librairies de base que M$ à gentiment standardisé pour faire plaisir au bon peuple. Donc il est relativement facile de sortir Mono en même temps que M$. Sauf que ça n'a absolument aucun sens au niveau de la portabilité entre les environnements. A partir du moment ou les environnements ne sont pas compatibles (et ne le seront sans doute jamais), je vois pas vraiment l'intérêt de copier commes des bénets M,ドル avec tous les risques que cela comporte.
Pour Java, il faut comprendre la plate-forme dans son ensemble, et la difficulté vient essentiellement de la mise à jour des librairies (au niveau de la JVM les nouvelles fonctionnalités sont relativement simples à implémenter). En revanche si tu considères, Mono + dotNet, tu t'exposes exactement aux mêmes problèmes, en pire, car les api M$ sont énormes, peu documentées, et sujettes à des évolutions sans préavis. (cf Wine).
Maintenant, comme dans Mono, rien n'empêche une appli Java d'appeler des fonctions natives, ex. http://java-gnome.sourceforge.net/news.en.html(...) . Et tant qu' à faire du non portable, tu peux utiliser GCJ et CNI (plus simple et + rapide que JNI).
[^] # Re: A comparer plutot au C#
Posté par Cook Captain . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 4.
Pour Java, il faut comprendre la plate-forme dans son ensemble, et la difficulté vient essentiellement de la mise à jour des librairies (au niveau de la JVM les nouvelles fonctionnalités sont relativement simples à implémenter). En revanche si tu considères, Mono + dotNet, tu t'exposes exactement aux mêmes problèmes, en pire, car les api M$ sont énormes, peu documentées, et sujettes à des évolutions sans préavis. (cf Wine).
Maintenant, comme dans Mono, rien n'empêche une appli Java d'appeler des fonctions natives, ex. http://java-gnome.sourceforge.net/news.en.html(...) . Et tant qu' à faire du non portable, tu peux utiliser GCJ et CNI (plus simple et + rapide que JNI).