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

Quelques exemples:

• Java n’a pas de type de valeur défini 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 – delegates, etc. Vous devrez également porter la bibliothèque, même pour les aspects linguistiques .
• Java ne prend pas en charge des éléments tels que les propriétés et les événements au niveau de la JVM. Vous pourriez simuler une partie de cela, mais ce ne serait pas la même chose.
• Je ne crois pas que Java ait l’équivalent des parameters de référence, même au niveau de la JVM
• Les subtilités à faire avec les différents modèles de mémoire pourraient très bien mordre, même si je ne suis pas certain de ce qu’il ya 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 un problème pour vous.
• Vous devez simuler une surcharge de l’opérateur et des conversions définies par l’utilisateur

Vous pourriez probablement porter beaucoup de C # – mais vous auriez 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(Ssortingng[] args) { // Sorts the arguments starting with "-" by length and then using the default // ssortingng 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); } } } 

Transstackurs Bytecode

Grasshopper peut prendre un bytecode CLR et le transposer pour JVM. Destiné principalement aux applications Web, il ne fournit pas, par exemple, l’implémentation JVM des classes Windows Forms. Semble quelque peu daté, cependant. Le web parle d’ASP.NET 2.0, Visual Studio 2008, etc. Tout d’abord mentionné par @alex

XMLVM peut utiliser le bytecode CLR ou JVM en entrée et en sortie. De plus, il peut produire du Javascript ou de l’objective-C. Pas encore de version, seulement Subversion. “Version de développement expérimental à ne pas utiliser dans un environnement de production.”

IKVM va dans l’autre sens que ne le souhaite OP. Il fournit une implémentation JVM s’exécutant sur CLR, un transstackr 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 utiliser CLR et JVM en parallèle et rendre la communication la plus fluide possible? Ce n’est pas ce que le PO veut, mais d’autres réponses sont déjà assez différentes de différentes manières, alors couvrons-le.

RabbitMQ , avec 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 prise en charge linguistique étendue, la génération de code pour les bibliothèques clientes dans ces langues, un format de fil indépendant des langues, des fonctionnalités avancées comme l’annulation des appels en cascade, etc.

Langages de programmation

Ecrire une fois, courir partout;)

Haxe , comstack 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 des fonctionnalités C # et une interopérabilité Java. Pas très utile, vous obtenez des fonctionnalités C #, mais vous interagissez avec 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 pour devenir meilleur. Tout d’abord mentionné ici par @Vns.

Rafale d’air frais pour la plate-forme JVM;)

Scala , Kotlin , etc., sont de bons langages fonctionnant au-dessus de la JVM, qui apportent des fonctionnalités qui peuvent manquer à un programmeur C # 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 un programmeur avec lequel il peut se familiariser rapidement.

Mono

C’est certainement une option aussi. Pourquoi transférer à JVM si Mono peut l’exécuter tel quel. Tout d’abord mentionné par @ferhrosa

NEW YORK – 12 novembre 2014 – Mercredi, Microsoft Corp. a renforcé son engagement envers les développeurs multi-plateformes en ouvrant la source complète de la stack .NET côté serveur et en développant .NET pour qu’il fonctionne sur les plates-formes Linux et Mac OS.

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

Ceci est un blog écrit par les personnes du projet Mono à ce sujet, de l’autre côté: Intégration du code source .NET (novembre 2014).

.NET Core

Une version multiplateforme Windows / Linux de (certaines) .Net régie par Microsoft. Nuff a dit https://github.com/dotnet/core .

Conclusion

Il serait maintenant nécessaire d’essayer ces outils / frameworks et de voir combien il y a de friction. Le PO veut écrire en C # pour la JVM, ce qui peut fonctionner très bien avec Grasshopper.

Faire cela avec l’objective de mélanger les bibliothèques mondiales C # et Java dans une base de code unique peut ne pas fonctionner si bien.

Sources

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

Il serait peut-être plus simple d’écrire un convertisseur de IL en bytecode. De cette façon, vous obtenez automatiquement une assistance pour tout langage .NET sur la machine virtuelle Java.

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 à faire.

Regardez la sauterelle . Il s’agit d’un SDK basé sur Visual Studio et d’un convertisseur .NET vers Java breveté qui vous permet d’exécuter des applications Web et serveur .NET sur Linux et d’autres plates-formes Java.

Une option pour le développement multi-plateforme en C # pourrait être mono: http://www.mono-project.com/

Vous pouvez utiliser un compilateur source à source pour traduire C # dans un langage plutôt que sur la machine virtuelle Java. Par exemple, plusieurs convertisseurs C # à Java permettraient aux applications C # de s’exécuter sur la JVM après avoir été traduites en Java.

Cette réponse 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 que C # possède et la plus proche 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, en ce qui concerne les fonctionnalités réelles du langage, C # et Java sont très proches. Non seulement C # amd Java close, ils se déplacent également dans des directions similaires. Il y a 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 un peu plus de sucre que de créer un Java presque à partir de rien. Au moment où le port est prêt, Java peut avoir 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 manière dont Microsoft prend tout en charge. Par exemple, le combo C # -XAML est plus convivial que JavaFX, car C # et XAML ont été piratés (par exemple, les classes partielles en C #, les liaisons dans XAML et autres). 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 va pas déranger.

Donc, mon conseil à un développeur Java, qui souhaite utiliser un langage plus sophistiqué sur des outils familiers, consiste à vérifier les langages JVM existants.

Mono est une option aussi, mais j’ai toujours été sceptique. Même s’il s’agit de C # -. NET et de multiplateformes, les choses construites avec les outils de Microsoft ne fonctionneront généralement pas sur Mono. C’est essentiellement sa propre chose. Nous allons voir ce qui se passe maintenant que Microsoft a déclaré qu’il collaborerait.