Quelqu'un tente-t-il d'implémenter C # pour la JVM? En tant que développeur Java, je lorgne C # avec envie, mais je ne suis pas disposé à abandonner la portabilité et la maturité de la JVM, sans parler de la gamme diversifiée d'outils pour cela.

Je sais qu'il existe des différences importantes entre la JVM et le CLR, mais y a-t-il quelque chose qui soit un succès?

Il existe des différences très importantes entre le CLR et la JVM.

Quelques exemples:

• Java n'a pas de types de valeur 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 des éléments du framework - les délégués, etc. Vous devrez également porter la bibliothèque, même pour le langage aspects .
• 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 pense pas que Java ait d'équivalent aux paramètres de passage par référence, même au niveau JVM
• Les subtilités liées aux différents modèles de mémoire pourraient très probablement mordre, même si je ne suis pas sûr de la quantité dans la spécification C #.
• Le code non sécurisé 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.
• Vous auriez à simuler la surcharge d'opérateurs et les conversions définies par l'utilisateur

Vous pourriez probablement porter 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 du code 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 Bytecode

Grasshopper peut prendre un bytecode CLR et le transpiler pour JVM. Destiné principalement aux applications Web, il ne fournit par exemple pas d'implémentation JVM des classes Windows Forms. Cela semble un peu daté, cependant. Le Web parle d'ASP.NET 2.0, de Visual Studio 2008 et ainsi de suite. Mentionné pour la première fois par @alex

XMLVM peut prendre le bytecode CLR ou JVM comme entrée et produire l'un ou l'autre comme sortie. De plus, il peut générer du Javascript ou Objective-C. Pas encore de versions, 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 ce que souhaite OP. Il fournit une implémentation JVM exécutée 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 faire fonctionner le CLR et la JVM en parallèle et rendre la communication aussi fluide que possible? Ce n'est pas ce que veut le PO, 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 d'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 filaire indépendant du langage pour les données, des fonctionnalités avancées telles que l'annulation d'appel en cascade, etc.

Langages de programmation

Écrivez une fois, courez 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 en dépend. Beaucoup plus digne de confiance que Stab, mentionné ensuite.

Stab apporte des fonctionnalités C # et une interopérabilité Java. Pas très utile, vous obtenez des fonctionnalités C #, mais ce avec quoi vous interagissez, c'est du code Java qui ne les utilise pas. https://softwareengineering.stackexchange.com/a/132080/45826 Le langage est relativement obscur, peut-être abandonné, avec peu de promesses de devenir meilleur. Mentionné pour la première fois ici par @Vns.

Bouffée d'air frais pour la plateforme JVM;)

Scala , Kotlin , d'autres, sont des langages assez sympas fonctionnant sur JVM qui apportent des fonctionnalités qu'un programmeur C # peut manquer en Java. Surtout Kotlin se sent comme une alternative raisonnable à C # dans le monde JVM. Scala est peut-être un langage un peu trop volumineux pour qu'un programmeur se sente à l'aise en peu de temps.

Mono

C'est certainement une option aussi. Pourquoi transpiler vers JVM si Mono peut l'exécuter tel quel. Mentionné pour la première fois par @ferhrosa

NEW YORK - 12 novembre 2014 - Mercredi, Microsoft Corp. a renforcé son engagement en faveur des expériences de développement multiplateformes en ouvrant l'approvisionnement de la pile complète .NET côté serveur et en étendant .NET pour fonctionner sur les plates-formes Linux et Mac OS.

Selon ce communiqué de presse dont provient la citation, Visual Studio 2015 ajoutera Linux / Mono en tant que plate-forme prise en charge.

Ceci est 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 (certains de) .Net régie par Microsoft. 'nuff a déclaré 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 fonctionner assez bien avec Grasshopper.

Faire cela dans le but de mélanger les bibliothèques du monde C # et Java dans une seule base de code peut ne pas fonctionner aussi bien.

Sources

http://blog.pluralsight.com/new-course-making-java-and-c-work-together-jvm-and-net-clr-interop

Il peut être plus simple d'écrire un convertisseur d'IL en bytecode. De cette façon, vous obtiendrez automatiquement la prise en charge de n'importe quel langage .NET sur la JVM.

Cependant, c'est une idée tellement évidente que si cela n'a pas déjà été fait, il est probablement extrêmement difficile ou difficile de bien / utilement faire.

Regardez Grasshopper . Il s'agit d'un SDK basé sur Visual Studio et d'un convertisseur breveté .NET vers Java 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 convertisseurs C # vers Java qui permettraient aux applications C # de s'exécuter sur la JVM après avoir été traduites en Java.

Cette réponse est peut-être en retard pour vous, mais celle-ci est juste nouvelle. Vous voudrez peut-être vérifier le langage de programmation Kotlin . Il offre les sucres syntaxiques du C # et les plus proches de la syntaxe C #, à l'exception de tout langage JVM non Java. C'est de JetBrains .

Je peux voir deux raisons pour lesquelles cela ne suscite pas beaucoup d'enthousiasme.

La première chose à réaliser est que, s'agissant des fonctionnalités réelles du langage, C # et Java sont très proches. Non seulement C # et Java sont proches, mais ils évoluent également dans des directions similaires. Il existe certaines fonctionnalités que la JVM ne prend actuellement pas en charge, 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 que Java obtienne 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, des classes partielles en C #, des 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 souhaite 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 à ce sujet. Même s'il s'agit de C # - .NET et multiplate-forme, les éléments créés 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.