Implementowanie języka C # dla maszyny JVM


91

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?


3
Napisałem też wiele, wiele w pełni multiplatformowych aplikacji w Javie - to codzienność dla mnie i mojego zespołu. Zwykle przeprowadzamy plan testów na każdej platformie, którą oficjalnie „kwalifikujemy”, ale myślę, że minęły lata, odkąd błąd testowy został przypisany różnicy między platformami.
Jared,

1
Nasz główny produkt działa bez zmian w systemach Windows, OS X i Linux. To naprawdę nie jest trudne.
Thorbjørn Ravn Andersen

1
Ja robię swoją Javę w Windows, inny facet robi swoją część w OSX, CI przeprowadza wszystkie testy pod Linuksem i wdrożyliśmy oprogramowanie na wielu serwerach Windows i Linux, a nawet Solaris. Więc myślę, że mógłbym powiedzieć, że od jakiegoś czasu pisałem naprawdę, w pełni, wieloplatformowe programy w Javie.
Esko

1
JavaVM zaimplementowana w .NET; Implementacja Java LIBS w .NET; interoperacyjność obu światów -> IKVM.NET ( ikvm.net )
gsscoder

1
Wydaje mi się, że jeśli potrafisz przekonwertować .NET na JavaScript (na przykład robi to JSIL), powinieneś być w stanie przekonwertować go na Javę ...
BrainSlugs83

Odpowiedzi:


93

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.


7
Java ma finalizatory, a finalizacja .NET też nie jest deterministyczna. Mogą istnieć między nimi pewne subtelne różnice, ale nie mogę wymyślić żadnej odręcznej. Podejrzewam, że testy osiągalności Javy są silniejsze niż .NET: brak finalizacji, podczas gdy inny wątek nadal działa metodą instancji
Jon Skeet

3
Myślę, że można odwzorować typy wartości na typy referencyjne. Po prostu spraw, aby każde zadanie wykonało płytki klon!
Daniel Earwicker,

3
@Earwicker: ... i zmienić alokację tablic i różne inne miejsca, w których semantyka ma znaczenie? Podejrzewam, że byłoby bardzo trudno go uruchomić, jeśli jest to możliwe, a wynik nie byłby czymś, czego chciałbyś użyć.
Jon Skeet,

4
Myślę, że leki generyczne również można by rozwiązać. Musiałbyś wygenerować klasę java z dodatkowymi polami do przechowywania obiektów Class dla parametrów typu, więc dodałoby to trochę narzutu, ale wtedy byłyby dostępne nowe T () i typeof (T).
Daniel Earwicker,

30
@Jon Skeet: To daje ci najgorsze z obu światów: nieco przestarzały język Java na zastrzeżonej platformie Microsoftu.
Bart van Heukelom

43

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

7
stab dostarcza większość treści języka C # na JVM, ale robi to w sposób, który jest bardzo interoperacyjny w Javie. Więc nie jest to ściśle zgodny kod źródłowy z kodem C # napisanym dla .NET CLR, ale pozwala programistom Java cieszyć się językiem bardzo podobnym do C #, jednocześnie uzyskując generowany kod bajtowy tej samej jakości i bezimpedancyjną interoperacyjność z bibliotekami i strukturami Java. Jest to właściwe podejście do uzyskiwania języka C # na JVM.
RogerV

1
Dobry język, na dobrej platformie ... Szkoda, że ​​nie natknąłem się na to lata temu.
Jaskinia Jefferey

15

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


Świetna odpowiedź! Jako programista C #, który jest niezadowolony z konieczności przejścia na Javę (jak możesz żyć bez właściwości ?!) i ma wątpliwości co do Scali, to naprawdę dobrze przedstawia opcje.
Gilthans

9

Ł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.


6
Napotkasz większość problemów, które wymieniłem - różne leki generyczne itp.
Jon Skeet,

8
To jest dokładnie to, co robi Grasshopper (patrz odpowiedź @ alex powyżej), co jest naprawdę niezwykle trudne do zrobienia dobrze (kiedyś pracowałem na Grasshopper).
Motti

7

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.


2
Czy masz z tym praktyczne doświadczenie? Należy również pamiętać, że licencja jest drakoniczna dla wersji bezpłatnej.
Thorbjørn Ravn Andersen

13
Straciłem zainteresowanie w momencie, gdy powiedziałeś słowo „opatentowany”. Westchnienie.
Stephen C

2
Kilka wiadomości: Grasshopper jest teraz darmowy , bez wsparcia i gwarancji (jak większość produktów open source).
fernacolo

1
Wydaje się, że Mainsoft jest całkowicie martwy, a łącza Grasshopper już nie działają.
David Given

1
W takim razie oczywiste, że jest to tylko ruch sieciowy. Oba łącza działają teraz. Niestety teraz nie pamiętam, dlaczego tego chciałem ...
David Given



0

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 .


0

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ć.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.