Implémentation de C # pour la JVM
Quelqu'un essaie-t-il d'implémenter C # pour la JVM? En tant que développeur Java, je regarde C # avec envie, mais je ne suis pas disposé à abandonner la portabilité et la maturité de la JVM, sans parler de la gamme variée d'outils pour cela.
Je sais qu'il y a des différences importantes entre la JVM et le CLR, mais y a-t-il quelque chose qui est un showstopper?
Il existe des différences très importantes entre le CLR et la JVM.
Quelques exemples:
- Java n'a pas de types de valeurs définis par l'utilisateur
- Les génériques Java sont complètement différents des génériques .NET
- De nombreux aspects de C # dépendent d'éléments du framework - délégués, etc. Vous devez également porter la bibliothèque, même pour les aspects language.
- Java ne prend pas en charge des éléments tels que les propriétés et les événements au niveau JVM. Vous pourriez simuler une partie de cela, mais ce ne serait pas la même chose.
- Je ne crois pas Java a un équivalent aux paramètres de passage par référence, même au niveau de la JVM
- Les subtilités liées aux différents modèles de mémoire mordraient très probablement, bien que je ne sois pas sûr de la quantité dans la spécification C #.
- Le code dangereux en général n'est probablement pas possible en Java
- L'interopérabilité avec le code natif est très différente entre JNI et P/Invoke. Ce n'est probablement pas vraiment un problème pour vous.
- Il faudrait simuler une surcharge d'opérateur et des conversions définies par l'utilisateur
Vous pourriez probablement porter un beaucoup de C # - mais vous vous retrouveriez avec une expérience assez insatisfaisante, IMO.
Dans l'autre sens, connaissez-vous IKVM ? Il vous permet d'exécuter Java dans .NET.
Visitez http://code.google.com/p/stab-language
Le code ci-dessous si un code de langue Stab pour JVM
using Java.lang;
using stab.query;
public class Test {
public static void main(String[] args) {
// Sorts the arguments starting with "-" by length and then using the default
// string comparison
var query = from s in Query.asIterable(args)
where s.startsWith("-")
orderby s.length(), s
select s;
foreach (var s in query) {
System.out.println(s);
}
}
}
Transpilateurs de bytecode
Grasshopper peut prendre un bytecode CLR et le transpiler pour JVM. Destiné principalement aux applications Web, il ne fournit pas par exemple Implémentation JVM des classes Windows Forms. Semble un peu daté, cependant. Le Web parle d'ASP.NET 2.0, de Visual Studio 2008 et ainsi de suite. Première mention par @alex
XMLVM peut prendre le bytecode CLR ou JVM en entrée et produire soit en sortie. De plus, il peut produire Javascript ou Objective-C. Pas encore de sorties, seulement Subversion. "Version de développement expérimental qui ne doit pas être utilisée dans un environnement de production."
IKVM va dans l'autre sens que OP le veut. Il fournit une implémentation JVM fonctionnant sur CLR, un transpilateur de bytecode JVM vers CLR et un générateur de stub de méthode de bibliothèque CLR pour Java. http://www.ikvm.net/uses.html Mentionné par @Jon Skeet
RPC
Pourquoi ne pas avoir CLR et JVM en parallèle et rendre la communication aussi fluide que possible? Ce n'est pas ce que l'OP veut, mais certaines autres réponses sont déjà assez hors sujet de différentes manières, alors couvrons-le.
RabbitMQ , a une option gratuite, c'est un serveur RPC écrit en Erlang avec des bibliothèques API pour C #, Java et plus.
jnBridge , la licence peut être trop chère pour certains utilisateurs potentiels.
gRPC , et les bibliothèques RPC modernes similaires offrent une large prise en charge des langues, la génération de code pour les bibliothèques clientes dans ces langues, un format de fil indépendant des langues pour les données, des fonctionnalités avancées telles que l'annulation d'appel en cascade, etc.
Langages de programmation
Écrivez une fois, exécutez partout;)
Haxe , compile en C #/CLR, Java/JVM, Javascript, Flash, Python,… Fournit des mécanismes d'interopérabilité pour chacun des langages cibles. Peut être considéré comme un successeur d'ActionScript3 dans une certaine mesure. Cela semble assez solide, avec au moins une entreprise qui en dépend. Beaucoup plus fiable que Stab, mentionné ci-dessous.
Stab apporte quelques fonctionnalités C # et Java interopérabilité. Pas très utile, vous obtenez quelques fonctionnalités C #, mais ce avec quoi vous interagissez est Java = code qui ne les utilise pas. https://softwareengineering.stackexchange.com/a/132080/45826 La langue est relativement obscure, peut-être abandonnée, avec peu de promesse de devenir meilleure. @Vns.
Rafale d'air frais pour la plateforme JVM;)
Scala , Kotlin , d'autres, sont des langages assez agréables fonctionnant au-dessus de JVM qui apportent des fonctionnalités qu'un programmeur C # peut manquer en Java. Surtout, Kotlin se sent comme une alternative raisonnable au C # dans le monde JVM. Scala peut être un langage un peu trop gros pour qu'un programmeur s'y mette à l'aise en peu de temps.
Mono
C'est certainement aussi une option. Pourquoi transpiler vers JVM si Mono peut l'exécuter tel quel. Première mention par @ferhrosa
NEW YORK - 12 novembre 2014 - Mercredi, Microsoft Corp. a renforcé son engagement envers les expériences des développeurs multiplateformes en ouvrant le sourcing complet côté serveur Pile .NET et extension de .NET pour fonctionner sur les plates-formes Linux et Mac OS.
Selon ce communiqué de presse d'où provient la citation, Visual Studio 2015 ajoutera Linux/Mono comme plate-forme prise en charge.
Il s'agit d'un blog écrit par les gens du projet Mono à ce sujet, de l'autre côté: . NET Source Code Integration (novembre 2014).
.NET Core
Une version multiplateforme Windows/Linux de (une partie de) .Net régie par Microsoft. 'nuff said https://github.com/dotnet/core .
Conclusion
Il serait maintenant nécessaire d'essayer ces outils/cadres et de voir combien il y a de friction. L'OP veut écrire en C # pour la JVM, ce qui peut en fait très bien fonctionner avec Grasshopper.
Faire cela dans le but de mélanger C # et Java dans une seule base de code peuvent ne pas fonctionner si bien.
Sources
http://blog.pluralsight.com/new-course-making-Java-and-c-work-together-jvm-and-net-clr-interop
Il pourrait être plus simple d'écrire un convertisseur d'IL en bytecode. De cette façon, vous obtiendrez automatiquement la prise en charge de tout langage .NET sur la JVM.
Cependant, c'est une idée tellement évidente que si cela n'a pas déjà été fait, c'est probablement extrêmement difficile, ou difficile à faire bien/utilement.
Regardez Grasshopper . Il s'agit d'un SDK basé sur Visual Studio et breveté .NET vers Java convertisseur qui vous permet d'exécuter des applications Web et serveur .NET sur Linux® et d'autres plates-formes compatibles Java.
Une option pour le développement multiplateforme en C # pourrait être mono: http://www.mono-project.com/
Vous pouvez utiliser un compilateur source-à-source pour traduire C # dans un langage qui s'exécute sur la JVM. Par exemple, il existe plusieurs C # à Java qui permettraient aux applications C # de s'exécuter sur la JVM après avoir été traduites en Java.
Je peux voir deux raisons pour lesquelles cela ne suscite pas beaucoup d'enthousiasme.
La première chose à réaliser est que, en ce qui concerne les fonctionnalités réelles du langage, C # et Java sont très proches. Non seulement C # AMD Java sont proches, mais ils se déplacent également dans des directions similaires. Il existe certaines fonctionnalités que la JVM ne prend pas en charge actuellement, mais ce n'est pas le vrai problème. Vous pouvez toujours simuler ce qui manque. Je pense que les gens préfèrent attendre Java pour obtenir un peu plus de sucre que de créer un Almost-Java à partir de zéro. Au moment où le port est prêt, Java a peut-être décidé de rattraper son retard.
Deuxièmement, la raison pour laquelle les développeurs préfèrent C # n'est pas tant le langage lui-même, mais les outils qui l'entourent, leur relation bidirectionnelle avec C # et la façon dont Microsoft prend en charge le tout. Par exemple, le combo C # -XAML est plus convivial que JavaFX, car C # et XAML ont été piratés l'un pour l'autre (par exemple, les classes partielles en C #, les liaisons en XAML et plus). L'utilisation de C # sur JavaFX ne s'améliore pas beaucoup. Pour obtenir l'expérience C # sur la JVM, vous devez également porter les outils, et c'est un projet beaucoup plus important. Même Mono ne dérangera pas.
Donc, mon conseil à un développeur Java, qui veut utiliser un langage plus sophistiqué sur des outils familiers, est de vérifier les langages JVM existants .
Mono est également une option, mais j'ai toujours été sceptique. Même si c'est C # -. NET et multiplateforme, les choses construites avec les outils de Microsoft ne fonctionneront généralement pas sur Mono. C'est essentiellement sa propre chose. Nous verrons ce qui se passe maintenant que Microsoft a annoncé sa collaboration.