Czy ktoś próbuje zaimplementować język C # dla maszyny JVM? Jako programista Java z zazdrością podchodzę do C #, ale nie chcę rezygnować z przenośności i dojrzałości JVM, nie wspominając już o różnorodnej gamie narzędzi do tego.

Wiem, że istnieje kilka ważnych różnic między JVM i CLR, ale czy jest coś, co powstrzymuje show?

Istnieją bardzo znaczące różnice między CLR a JVM.

Kilka przykładów:

• Java nie ma typów wartości zdefiniowanych przez użytkownika
• Generyczne programy Java są zupełnie inne niż generyczne .NET
• Wiele aspektów C # zależy od elementów frameworka - delegatów itp. Będziesz musiał również przenieść bibliotekę, nawet jeśli chodzi o aspekty językowe .
• Java nie obsługuje takich elementów, jak właściwości i zdarzenia na poziomie JVM. Możesz to udawać, ale to nie będzie to samo.
• Nie wierzę, że Java ma jakikolwiek odpowiednik parametrów przekazywania przez referencję, nawet na poziomie JVM
• Subtelności związane z różnymi modelami pamięci prawdopodobnie gryzłyby, chociaż nie jestem pewien, ile jest w specyfikacji C #.
• Generalnie niebezpieczny kod prawdopodobnie nie jest możliwy w Javie
• Współdziałanie z kodem natywnym jest bardzo różne między JNI i P / Invoke. Prawdopodobnie nie stanowi to dla ciebie większego problemu.
• Musiałbyś udawać przeciążenie operatora i konwersje zdefiniowane przez użytkownika

Prawdopodobnie mógłbyś przeportować wiele C # - ale zostałbyś z dość niezadowalającym doświadczeniem, IMO.

Idąc w drugą stronę, czy znasz IKVM ? Pozwala na uruchamianie kodu Java w .NET.

Odwiedź http://code.google.com/p/stab-language

Poniższy kod, jeśli kod języka Stab dla maszyny 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);
        }
    }
}

Transpilery kodu bajtowego

Grasshopper może pobrać kod bajtowy CLR i przetransponować go do JVM. Przeznaczony głównie dla aplikacji webowych, nie zapewnia m.in. implementacji JVM klas Windows Forms. Wydaje się jednak nieco przestarzały. W sieci Web można znaleźć informacje o ASP.NET 2.0, Visual Studio 2008 i tak dalej. Pierwsza wzmianka o @alex

XMLVM może pobierać kod bajtowy CLR lub JVM jako dane wejściowe i generować jako dane wyjściowe. Dodatkowo może wyświetlać Javascript lub Objective-C. Nie ma jeszcze żadnych wydań, tylko Subversion. „Eksperymentalna wersja rozwojowa, która nie jest przeznaczona do użytku w środowisku produkcyjnym”.

IKVM idzie w innym kierunku niż chce OP. Zapewnia implementację JVM działającą w środowisku CLR, transpiler kodu bajtowego JVM do CLR oraz generator skrótów metody biblioteki CLR dla języka Java. http://www.ikvm.net/uses.html Wspomniane przez @Jon Skeet

RPC

Dlaczego nie mieć CLR i JVM działających równolegle i uczynić komunikację tak bezproblemową, jak to tylko możliwe? Nie tego chce PO, ale niektóre inne odpowiedzi są już całkiem poza tematem na różne sposoby, więc omówmy to.

RabbitMQ , ma darmową opcję, jest to serwer RPC napisany w Erlang z bibliotekami API dla C #, Java i nie tylko.

jnBridge , licencja może być zbyt droga dla niektórych potencjalnych użytkowników.

gRPC i podobne nowoczesne biblioteki RPC oferują obsługę wielu języków, generowanie kodu dla bibliotek klienckich w tych językach, format przewodowy danych niezależny od języka, zaawansowane funkcje, takie jak kaskadowe anulowanie połączeń i tak dalej.

Języki programowania

Napisz raz, biegnij wszędzie;)

Haxe , kompiluje do C # / CLR, Java / JVM, Javascript, Flash, Python,… Zapewnia mechanizmy międzyoperacyjne dla każdego z języków docelowych. Do pewnego stopnia można go traktować jako następcę ActionScript3. Wydaje się, że to całkiem solidna sprawa, przynajmniej jedna firma faktycznie od tego zależy. Znacznie bardziej godny zaufania niż wspomniany dalej Stab.

Stab wprowadza niektóre funkcje C # i interoperacyjność Java. Niezbyt przydatne, masz pewne funkcje C #, ale to, z czym wchodzisz w interakcję, to kod Java, który ich nie używa. https://softwareengineering.stackexchange.com/a/132080/45826 Język jest stosunkowo niejasny, prawdopodobnie porzucony, z niewielką szansą na poprawę. Po raz pierwszy wspomniano tutaj przez @Vns.

Podmuch świeżego powietrza dla platformy JVM;)

Scala , Kotlin i inni to całkiem przyjemne języki działające na bazie JVM, które oferują funkcje, których programista C # może przegapić w Javie. Szczególnie Kotlin wydaje się rozsądną alternatywą dla C # w świecie JVM. Scala może być trochę za dużym językiem, aby programiści mogli się z nim swobodnie pogodzić w krótkim czasie.

Mononukleoza

To z pewnością też opcja. Po co transponować do JVM, skoro Mono może go uruchomić tak, jak jest. Pierwsza wzmianka o @ferhrosa

NOWY JORK - 12 listopada 2014 r. - W środę firma Microsoft Corp. wzmocniła swoje zaangażowanie w tworzenie wieloplatformowych doświadczeń deweloperów, udostępniając na zasadach open source pełny stos .NET po stronie serwera i rozszerzając .NET tak, aby działał na platformach Linux i Mac OS.

Zgodnie z tym komunikatem prasowym, z którego pochodzi cytat, Visual Studio 2015 doda Linux / Mono jako obsługiwaną platformę.

To jest blog napisany o tym przez ludzi z projektu Mono, z drugiej strony: .NET Source Code Integration (listopad 2014).

.NET Core

Wieloplatformowa wersja (niektórych) .Net dla systemów Windows / Linux zarządzana przez firmę Microsoft. 'nuff powiedział https://github.com/dotnet/core .

Wniosek

Należałoby teraz wypróbować te narzędzia / ramy i zobaczyć, jak duże są tarcia. OP chce pisać w języku C # dla maszyny JVM, która może faktycznie działać całkiem dobrze przy użyciu Grasshopper.

Robienie tego w celu połączenia bibliotek świata C # i Java w jednej bazie kodu może nie działać tak dobrze.

Źródła

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

Łatwiej byłoby napisać konwerter z IL na kod bajtowy. W ten sposób automatycznie uzyskasz wsparcie dla dowolnego języka .NET w JVM.

Jest to jednak tak oczywisty pomysł, że jeśli jeszcze tego nie zrobiono, prawdopodobnie jest to niezwykle trudne lub trudne do zrobienia dobrze / pożytecznie.

Spójrz na konika polnego . Jest to zestaw SDK oparty na Visual Studio i opatentowany konwerter .NET na Java, który umożliwia uruchamianie aplikacji internetowych i serwerowych .NET w systemie Linux® i innych platformach obsługujących język Java.

Opcją dla programowania międzyplatformowego w C # może być mono: http://www.mono-project.com/

Możesz użyć kompilatora typu source-to-source, aby przetłumaczyć C # na język, który jest uruchamiany na JVM. Na przykład istnieje kilka konwerterów języka C # do języka Java , które umożliwiałyby uruchamianie aplikacji C # w JVM po przetłumaczeniu na język Java.

Ta odpowiedź może być dla ciebie spóźniona, ale ta jest po prostu nowa. Możesz sprawdzić język programowania Kotlin . Oferuje cukry składniowe, które ma C # i jest również najbliższa składni C #, inne niż jakikolwiek inny język JVM inny niż Java. Pochodzi z JetBrains .

Widzę dwa powody, dla których nie jest to zbyt entuzjastyczne.

Pierwszą rzeczą, którą należy sobie uświadomić, jest to, że jeśli chodzi o rzeczywiste cechy języka, C # i Java są bardzo blisko. C # amd Java jest nie tylko blisko, ale również zmierzają w podobnym kierunku. Istnieją pewne funkcje, których JVM obecnie nie obsługuje po wyjęciu z pudełka, ale to nie jest prawdziwy problem. Zawsze możesz udawać to, czego brakuje. Myślę, że ludzie wolą czekać, aż Java dostanie trochę więcej cukru, niż tworzyć prawie Java od podstaw. Zanim port będzie gotowy, Java mogła zdecydować się nadrobić zaległości.

Po drugie, powodem, dla którego programiści wolą C #, nie jest sam język, ale otaczające go narzędzia, ich dwukierunkowa relacja z C # i sposób, w jaki Microsoft obsługuje całość. Na przykład kombinacja C # -XAML jest bardziej przyjazna niż JavaFX, ponieważ C # i XAML zostały zhakowane dla siebie nawzajem (np. Częściowe klasy w C #, powiązania w XAML i nie tylko). Używanie C # w JavaFX nie poprawia wiele. Aby uzyskać doświadczenie C # w JVM, musisz także przenieść narzędzia, a to jest znacznie większy projekt. Nawet Mono nie będzie się tym przejmował.

Tak więc moja rada dla programisty Java, który chce użyć bardziej wyszukanego języka na bazie znanych narzędzi, to sprawdzenie istniejących języków JVM .

Mono też jest opcją, ale zawsze byłem wobec niej sceptyczny. Mimo że jest to C # - .NET i wieloplatformowy, rzeczy zbudowane przy użyciu narzędzi Microsoftu nie będą działać na Mono. Zasadniczo jest to jego własna sprawa. Zobaczymy, co się stanie teraz, gdy Microsoft powiedział, że będą współpracować.