Implementieren von C# für die JVM

Lesezeit: 9 Minuten

Benutzer-Avatar
rauben

Versucht jemand, C# für die JVM zu implementieren? Als Java-Entwickler habe ich C# neidisch beäugt, bin aber nicht bereit, die Portabilität und Reife der JVM aufzugeben, ganz zu schweigen von der vielfältigen Palette an Tools dafür.

Ich weiß, dass es einige wichtige Unterschiede zwischen JVM und CLR gibt, aber gibt es irgendetwas, das ein Showstopper ist?

  • Ich habe auch viele, viele vollständig plattformübergreifende Apps in Java geschrieben – es ist eine alltägliche Sache für mich und mein Team. Normalerweise führen wir den Testplan auf jeder Plattform aus, die wir offiziell „qualifizieren“, aber ich denke, es ist Jahre her, seit ein Testfehler einem Plattformunterschied zugeschrieben wurde.

    – Jared

    25. März 2009 um 18:52 Uhr

  • Unser Hauptprodukt läuft unverändert auf Windows, OS X und Linux. Es ist wirklich nicht schwer zu tun.

    – Thorbjørn Ravn Andersen

    7. August 2009 um 21:07 Uhr

  • Warum verwenden Sie nicht einfach Groovy? Es bietet Ihnen wahrscheinlich alles, was Sie in C # mögen und in Java vermissen, und es läuft auf JVM …

    Benutzer283127

    28. Februar 2010 um 15:13 Uhr

  • Ich mache mein Java in Windows, der andere macht seinen Teil in OSX, CI führt alle Tests unter Linux durch und wir haben die Software auf einer Vielzahl von Windows- und Linux-Servern und sogar Solaris bereitgestellt. Ich schätze also, ich könnte sagen, dass ich jetzt schon seit einiger Zeit wirklich vollständige Multiplattform-Java-Programme geschrieben habe.

    – Esko

    1. Mai 2010 um 16:18 Uhr

  • JavaVM implementiert in .NET; .NET-Implementierung von Java LIBS; Interoperabilität beider Welten -> IKVM.NET (ikvm.net)

    – gscoder

    31. Dezember 2012 um 20:20 Uhr

Benutzer-Avatar
Jon Skeet

Es gibt sehr signifikante Unterschiede zwischen der CLR und der JVM.

Ein paar Beispiele:

  • Java hat keine benutzerdefinierten Werttypen
  • Java-Generika ist vollständig anders als .NET-Generika
  • Viele Aspekte von C# hängen von Elementen des Frameworks ab – Delegaten usw. Sie müssten auch die Bibliothek portieren, sogar für Sprache Aspekte.
  • Java unterstützt Dinge wie Eigenschaften und Ereignisse auf JVM-Ebene nicht. Sie könnten etwas davon vortäuschen, aber es wäre nicht dasselbe.
  • Ich glaube nicht, dass Java ein Äquivalent zu Pass-by-Reference-Parametern hat, selbst auf JVM-Ebene
  • Feinheiten, die mit den verschiedenen Speichermodellen zu tun haben, würden sehr wahrscheinlich beißen, obwohl ich nicht sicher bin, wie viel in der C#-Spezifikation enthalten ist.
  • Unsicherer Code im Allgemeinen ist in Java wahrscheinlich nicht möglich
  • Die Interoperabilität mit nativem Code ist zwischen JNI und P/Invoke sehr unterschiedlich. Das ist wahrscheinlich kein großes Problem für Sie.
  • Sie müssten Operatorüberladungen und benutzerdefinierte Konvertierungen vortäuschen

Du könntest wahrscheinlich a portieren viel von C# – aber Sie würden mit einer ziemlich unbefriedigenden Erfahrung zurückbleiben, IMO.

Gehen Sie in die andere Richtung, sind Sie sich dessen bewusst IKVM? Damit können Sie Java-Code in .NET ausführen.

  • Java hat Finalizer, und die .NET-Finalisierung ist auch nicht deterministisch. Es mag einige subtile Unterschiede zwischen den beiden geben, aber auf Anhieb fallen mir keine ein. Ich vermute jedoch, dass die Erreichbarkeitstests von Java stärker sind als die von .NET: keine Finalisierung, während ein anderer Thread noch eine Instanzmethode ausführt

    – Jon Skeet

    25. März 2009 um 17:45 Uhr

  • Ich denke, Sie könnten Werttypen Referenztypen zuordnen. Machen Sie einfach jede Aufgabe zu einem flachen Klon!

    – Daniel Earwicker

    25. März 2009 um 17:47 Uhr

  • @Earwicker: … und die Array-Zuordnung ändern und an verschiedenen anderen Stellen, an denen die Semantik einen Unterschied macht? Ich vermute, es wäre sehr schwer, es zum Laufen zu bringen, wenn Es ist möglich, und das Ergebnis wäre nicht etwas, das Sie verwenden möchten.

    – Jon Skeet

    25. März 2009 um 17:50 Uhr

  • Ich denke, Generika wären auch lösbar. Sie müssten eine Java-Klasse mit zusätzlichen Feldern generieren, um die Klassenobjekte für die Typparameter aufzunehmen, was etwas Overhead hinzufügen würde, aber dann wären neue T() und typeof(T) verfügbar.

    – Daniel Earwicker

    25. März 2009 um 18:21 Uhr

  • @Jon Skeet: Das gibt Ihnen das Schlimmste aus beiden Welten: Javas etwas veraltete Sprache auf der proprietären Plattform von Microsoft.

    – Bart van Heukelom

    2. Juli 2010 um 22:04 Uhr

Benutzer-Avatar
Vns

Besuch http://code.google.com/p/stab-language

Der folgende Code ist ein Stab-Sprachcode für 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);
        }
    }
}

  • stab liefert einen Großteil der C#-Sprache auf JVM, tut dies jedoch auf eine Weise, die sehr Java-interoperabel ist. Es ist also nicht streng quellcodekompatibel mit C#-Code, der für die .NET CLR geschrieben wurde, aber es ermöglicht einem Java-Programmierer, eine sehr C#-ähnliche Sprache zu genießen, während er Bytecode mit der gleichen Qualität generiert und eine nicht-impedanzische Interoperabilität mit Java-Bibliotheken und -Frameworks hat. Es ist der richtige Ansatz, um C# auf die JVM zu bringen.

    – RogerV

    24. Juli 2010 um 14:53 Uhr

  • Die gute Sprache, auf der guten Plattform … wünschte, ich wäre vor Jahren darüber gestolpert.

    – Jeffrey Cave

    9. Januar 2014 um 18:30 Uhr

Bytecode-Transpiler

Heuschrecke kann einen CLR-Bytecode nehmen und für JVM transpilieren. In erster Linie für Web-Apps gedacht, bietet es zB keine JVM-Implementierung von Windows Forms-Klassen. Wirkt allerdings etwas veraltet. Das Web spricht über ASP.NET 2.0, Visual Studio 2008 und so weiter. Erstmals erwähnt von @alex

XMLVM kann CLR- oder JVM-Bytecode als Eingabe verwenden und beides als Ausgabe erzeugen. Zusätzlich kann es Javascript oder Objective-C ausgeben. Noch keine Releases, nur Subversion. “Experimentelle Entwicklungsversion, die nicht in einer Produktionsumgebung verwendet werden soll.”

IKVM geht in die andere Richtung als OP will. Es bietet eine JVM-Implementierung, die auf CLR läuft, einen JVM-zu-CLR-Bytecode-Transpiler und einen Stub-Generator für CLR-Bibliotheksmethoden für Java. http://www.ikvm.net/uses.html Erwähnt von @Jon Skeet

RPC

Warum nicht CLR und JVM parallel laufen lassen und die Kommunikation so reibungslos wie möglich gestalten? Dies ist nicht das, was das OP will, aber einige andere Antworten sind auf unterschiedliche Weise bereits ziemlich vom Thema abgekommen, also lassen Sie uns darüber sprechen.

RabbitMQhat eine kostenlose Option, es ist ein in Erlang geschriebener RPC-Server mit API-Bibliotheken für C#, Java und mehr.

jnBrückekann die Lizenz für einige potenzielle Benutzer zu teuer sein.

gRPCund ähnliche moderne RPC-Bibliotheken bieten breite Sprachunterstützung, Codegenerierung für Clientbibliotheken in diesen Sprachen, sprachunabhängiges Drahtformat für Daten, erweiterte Funktionen wie kaskadierende Anrufunterdrückung und so weiter.

Programmiersprachen

Einmal schreiben, überall laufen 😉

Haxe, kompiliert nach C#/CLR, Java/JVM, Javascript, Flash, Python, … Bietet Interop-Mechanismen für jede der Zielsprachen. Kann bis zu einem gewissen Grad als ActionScript3-Nachfolger betrachtet werden. Scheint ziemlich solides Zeug zu sein, von dem mindestens ein Unternehmen tatsächlich abhängig ist. Viel vertrauenswürdiger als Stab, der als nächstes erwähnt wird.

Stechen bringt einige C#-Features und Java-Interoperabilität mit. Nicht sehr nützlich, Sie erhalten einige C#-Funktionen, aber Sie interagieren mit Java-Code, der sie nicht verwendet. https://softwareengineering.stackexchange.com/a/132080/45826 Die Sprache ist relativ obskur, möglicherweise verlassen, mit wenig Versprechen, besser zu werden. Hier zuerst erwähnt von @Vns.

Frischer Wind für die JVM-Plattform 😉

Skala, Kotlin, andere, sind ziemlich nette Sprachen, die auf JVM laufen und Funktionen mitbringen, die ein C#-Programmierer in Java vermissen könnte. Vor allem Kotlin fühlt sich in der JVM-Welt als sinnvolle Alternative zu C# an. Scala ist möglicherweise eine etwas zu große Sprache, als dass sich ein Programmierer in kurzer Zeit damit anfreunden könnte.

Mono

Das ist sicherlich auch eine Option. Warum in JVM transpilieren, wenn Mono es so ausführen kann, wie es ist. Erstmals erwähnt von @ferhrosa

NEW YORK – 12. November 2014 – Am Mittwoch verstärkte Microsoft Corp. sein Engagement für plattformübergreifende Entwicklererfahrungen, indem es den vollständigen serverseitigen .NET-Stack als Open Source bereitstellte und .NET für die Ausführung auf Linux- und Mac OS-Plattformen erweiterte.

Entsprechend diese Pressemitteilung aus dem das Zitat stammt, wird Visual Studio 2015 Linux/Mono als unterstützte Plattform hinzufügen.

Dies ist ein Blog, der von den Leuten des Mono-Projekts darüber geschrieben wurde, von der anderen Seite: .NET-Quellcode-Integration (November 2014).

.NET Core

Eine Windows/Linux-Multiplattformversion von (einigen von) .Net, die von Microsoft verwaltet wird. ’nuff sagte https://github.com/dotnet/core.

Fazit

Es wäre jetzt notwendig, diese Tools/Frameworks auszuprobieren und zu sehen, wie viel Reibung es gibt. Das OP möchte in C# für die JVM schreiben, was mit Grasshopper eigentlich ganz gut funktionieren kann.

Dies mit dem Ziel zu tun, C#- und Java-Weltbibliotheken in einer einzigen Codebasis zu mischen, funktioniert möglicherweise nicht so gut.

Quellen

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

  • Gute Antwort! Als C#-Entwickler, der mit der Umstellung auf Java unzufrieden ist (wie kann man ohne Eigenschaften leben?!) und Scala skeptisch gegenübersteht, sind die Optionen wirklich gut dargestellt.

    – Gilthaner

    15. März 2015 um 20:45 Uhr

Es könnte einfacher sein, einen Konverter von IL zu Bytecode zu schreiben. Auf diese Weise erhalten Sie automatisch Unterstützung für jede .NET-Sprache auf der JVM.

Dies ist jedoch eine so offensichtliche Idee, dass es, wenn dies noch nicht geschehen ist, wahrscheinlich extrem schwierig oder schwierig ist, es gut / nützlich zu machen.

Benutzer-Avatar
Alex

Ansehen Heuschrecke. Es ist ein Visual Studio-basiertes SDK und ein patentierter .NET-zu-Java-Konverter, mit dem Sie .NET-Web- und -Serveranwendungen auf Linux®- und anderen Java-fähigen Plattformen ausführen können.

  • Hast du praktische Erfahrungen damit? Beachten Sie auch, dass die Lizenz für die kostenlose Version drakonisch ist.

    – Thorbjørn Ravn Andersen

    7. August 2009 um 21:17 Uhr

  • Sie haben mein Interesse verloren, als Sie das Wort “patentiert” sagten. Seufzen.

    – Stefan C

    20. November 2011 um 11:51 Uhr

  • Nur ein paar Neuigkeiten: Grasshopper ist jetzt freiohne Support und Garantie (wie die meisten Open-Source-Produkte).

    – Fernakolo

    14. August 2012 um 13:25 Uhr

  • Mainsoft scheint komplett tot zu sein und die Grasshopper-Links funktionieren nicht mehr.

    – David gegeben

    12. März 2013 um 14:56 Uhr

  • Offensichtlich nur ein Netz wackeln dann. Beide Links funktionieren jetzt. Leider weiß ich jetzt nicht mehr, warum ich es wollte…

    – David gegeben

    19. Dezember 2013 um 20:28 Uhr

Benutzer-Avatar
ferhrosa

Eine Option für die plattformübergreifende Entwicklung in C# könnte Mono sein: http://www.mono-project.com/

  • Hast du praktische Erfahrungen damit? Beachten Sie auch, dass die Lizenz für die kostenlose Version drakonisch ist.

    – Thorbjørn Ravn Andersen

    7. August 2009 um 21:17 Uhr

  • Sie haben mein Interesse verloren, als Sie das Wort “patentiert” sagten. Seufzen.

    – Stefan C

    20. November 2011 um 11:51 Uhr

  • Nur ein paar Neuigkeiten: Grasshopper ist jetzt freiohne Support und Garantie (wie die meisten Open-Source-Produkte).

    – Fernakolo

    14. August 2012 um 13:25 Uhr

  • Mainsoft scheint komplett tot zu sein und die Grasshopper-Links funktionieren nicht mehr.

    – David gegeben

    12. März 2013 um 14:56 Uhr

  • Offensichtlich nur ein Netz wackeln dann. Beide Links funktionieren jetzt. Leider weiß ich jetzt nicht mehr, warum ich es wollte…

    – David gegeben

    19. Dezember 2013 um 20:28 Uhr

Benutzer-Avatar
Andersen Grün

Sie können eine verwenden Source-to-Source-Compiler um C# in eine Sprache zu übersetzen, die auf der JVM läuft. Beispielsweise gibt es mehrere C#-zu-Java-Konverter, mit denen C#-Anwendungen nach der Übersetzung in Java auf der JVM ausgeführt werden können.

1283600cookie-checkImplementieren von C# für die JVM

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy