Versucht jemand, C # für die JVM zu implementieren? Als Java-Entwickler habe ich C # mit Neid betrachtet, bin aber nicht bereit, die Portabilität und Reife der JVM aufzugeben, ganz zu schweigen von den vielfältigen Tools.

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

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

Einige Beispiele:

• Java hat keine benutzerdefinierten Werttypen
• Java Generics ist völlig anders zu .NET Generika
• Viele Aspekte von C # hängen von Elementen des Rahmens - Delegierte etc. Sie in den Hafen als auch die Bibliothek benötigen würde, auch für die Sprache Aspekte.
• Java unterstützt keine Eigenschaften und Ereignisse auf JVM-Ebene. Sie könnten etwas davon vortäuschen, aber es wäre nicht dasselbe.
• Ich glaube nicht, dass Java selbst auf JVM-Ebene Entsprechungen zu Referenzparametern hat
• Feinheiten, die mit den verschiedenen Speichermodellen zu tun haben, würden möglicherweise beißen, obwohl ich nicht sicher bin, wie viel in der C # -Spezifikation enthalten ist.
• Unsicherer Code ist in Java im Allgemeinen wahrscheinlich nicht möglich
• Die Interoperabilität mit nativem Code unterscheidet sich stark zwischen JNI und P / Invoke. Dies ist wahrscheinlich kein großes Problem für Sie.
• Sie müssten Operatorüberladung und benutzerdefinierte Konvertierungen vortäuschen

Sie könnten wahrscheinlich viel C # portieren - aber Sie würden eine ziemlich unbefriedigende Erfahrung haben, IMO.

Wenn Sie in die andere Richtung gehen, kennen Sie IKVM ? Sie können Java-Code in .NET ausführen.

Besuchen Sie 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);
        }
    }
}

Bytecode-Transpiler

Grasshopper kann einen CLR-Bytecode für JVM transpilieren. Es ist hauptsächlich für Web-Apps gedacht und bietet keine zB JVM-Implementierung von Windows Forms-Klassen. Scheint allerdings etwas veraltet zu sein. 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 entweder als Ausgabe erzeugen. Zusätzlich kann Javascript oder Objective-C ausgegeben werden. Noch keine Veröffentlichungen, 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 ausgeführt wird, einen JVM-zu-CLR-Bytecode-Transpiler und einen CLR-Bibliotheksmethoden-Stubgenerator für Java. http://www.ikvm.net/uses.html Erwähnt von @Jon Skeet

RPC

Warum nicht CLR und JVM nebeneinander 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 unangebracht. Lassen Sie uns dies behandeln.

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

jnBridge , die Lizenz kann für einige potenzielle Benutzer zu teuer sein.

gRPC und ähnliche moderne RPC-Bibliotheken bieten umfassende Sprachunterstützung, Codegenerierung für Clientbibliotheken in diesen Sprachen, sprachunabhängiges Drahtformat für Daten, erweiterte Funktionen wie kaskadierende Anrufunterbrechung usw.

Programmiersprachen

Einmal schreiben, überall laufen lassen;)

Haxe , kompiliert zu 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 solide zu sein, wobei mindestens eine Firma tatsächlich davon abhängt. Viel vertrauenswürdiger als Stab, der als nächstes erwähnt wird.

Stab bringt einige C # -Funktionen und Java-Interoperabilität. 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 dunkel, möglicherweise aufgegeben, und verspricht wenig, besser zu werden. Erstmals hier erwähnt von @Vns.

Frischluftstoß für die JVM-Plattform;)

Scala , Kotlin und andere sind ziemlich nette Sprachen, die auf JVM laufen und Funktionen bieten, die ein C # -Programmierer in Java möglicherweise vermisst. Besonders Kotlin scheint eine vernünftige Alternative zu C # in der JVM-Welt zu sein. Scala ist möglicherweise eine etwas zu große Sprache, als dass sich ein Programmierer in kurzer Zeit damit vertraut machen könnte.

Mono

Das ist sicherlich auch eine Option. Warum auf 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 durch Open Sourcing des gesamten serverseitigen .NET-Stacks und die Erweiterung von .NET für die Ausführung auf Linux- und Mac OS-Plattformen.

Laut dieser Pressemitteilung, aus der das Zitat stammt, wird Visual Studio 2015 Linux / Mono als unterstützte Plattform hinzufügen.

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

.NET Core

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

Fazit

Es wäre jetzt notwendig, diese Tools / Frameworks auszuprobieren und festzustellen, wie viel Reibung vorhanden ist. Das OP möchte in C # für die JVM schreiben, was mit Grasshopper möglicherweise recht gut funktioniert.

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

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

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

Schau dir Grasshopper an . Es handelt sich um ein Visual Studio-basiertes SDK und einen patentierten .NET-Java-Konverter, mit dem Sie .NET-Web- und -Serveranwendungen auf Linux® und anderen Java-fähigen Plattformen ausführen können.

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

Sie können einen Source-to-Source-Compiler verwenden , um C # in eine Sprache zu übersetzen, die auf der JVM ausgeführt wird. 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.

Diese Antwort mag für Sie zu spät sein, aber diese ist nur neu. Vielleicht möchten Sie die Programmiersprache Kotlin ausprobieren. Es bietet die syntaktischen Zucker, die C # hat, und ist der C # -Syntax am nächsten, abgesehen von jeder Nicht-Java-JVM-Sprache. Es ist von JetBrains .

Ich kann zwei Gründe sehen, warum dies nicht viel Begeisterung bekommt.

Das erste, was zu erkennen ist, ist, dass C # und Java in Bezug auf die tatsächlichen Merkmale der Sprache sehr nahe beieinander liegen. C # und Java sind nicht nur in der Nähe, sie bewegen sich auch in ähnliche Richtungen. Es gibt einige Funktionen, die die JVM derzeit nicht sofort unterstützt, aber das ist nicht das eigentliche Problem. Sie können immer fälschen, was fehlt. Ich denke, die Leute warten lieber darauf, dass Java etwas mehr Zucker bekommt, als ein Fast-Java von Grund auf neu zu erstellen. Bis der Port fertig ist, hat Java möglicherweise beschlossen, aufzuholen.

Zweitens ist der Grund, warum Entwickler C # bevorzugen, nicht so sehr die Sprache selbst, sondern die Tools, die sie umgeben, ihre wechselseitige Beziehung zu C # und wie Microsoft das Ganze unterstützt. Beispielsweise ist die C # -XAML-Kombination freundlicher als JavaFX, da C # und XAML für einander gehackt wurden (z. B. Teilklassen in C #, Bindungen in XAML und mehr). Die Verwendung von C # unter JavaFX verbessert sich nicht wesentlich. Um die C # -Erfahrung in der JVM zu erhalten, müssen Sie auch die Tools portieren, und das ist ein viel größeres Projekt. Nicht einmal Mono wird sich darum kümmern.

Mein Rat an einen Java-Entwickler, der eine ausgefallenere Sprache auf bekannten Tools verwenden möchte, ist daher, die vorhandenen JVM-Sprachen zu überprüfen .

Mono ist auch eine Option, aber ich war immer skeptisch. Obwohl es sich um C # -. NET und plattformübergreifend handelt, funktionieren Dinge, die mit Microsoft-Tools erstellt wurden, im Allgemeinen nicht mit Mono. Es ist im Wesentlichen seine eigene Sache. Wir werden sehen, was jetzt passiert, nachdem Microsoft angekündigt hat, dass sie zusammenarbeiten werden.