Apakah ada yang mencoba menerapkan C # untuk JVM? Sebagai seorang pengembang Java, saya telah mengincar C # dengan iri, tetapi saya tidak mau melepaskan portabilitas dan kematangan JVM, belum lagi beragam alat untuk itu.

Saya tahu ada beberapa perbedaan penting antara JVM dan CLR, tetapi adakah yang dimaksud dengan showstopper?

Ada perbedaan yang sangat signifikan antara CLR dan JVM.

Beberapa contoh:

• Java tidak memiliki tipe nilai yang ditentukan pengguna
• Java generik adalah benar-benar berbeda dengan NET generik
• Banyak aspek C # bergantung pada elemen kerangka kerja - delegasi dll. Anda juga perlu mem-port perpustakaan, bahkan untuk aspek bahasa .
• Java tidak mendukung hal-hal seperti properti dan acara di tingkat JVM. Anda dapat memalsukan sebagian dari ini, tetapi itu tidak akan sama.
• Saya tidak percaya Java memiliki parameter yang setara dengan pass-by-reference, bahkan pada level JVM
• Kehalusan yang berkaitan dengan model memori yang berbeda sangat mungkin menggigit, meskipun saya tidak yakin berapa banyak dalam spesifikasi C #.
• Kode yang tidak aman secara umum mungkin tidak dimungkinkan di Java
• Interoperabilitas dengan kode asli sangat berbeda antara JNI dan P / Invoke. Ini mungkin tidak terlalu menjadi masalah bagi Anda.
• Anda harus memalsukan kelebihan beban operator dan konversi yang ditentukan pengguna

Anda mungkin bisa mem-port banyak C # - tetapi Anda akan ditinggalkan dengan pengalaman yang sangat tidak memuaskan, IMO.

Sebaliknya, apakah Anda mengetahui IKVM ? Ini memungkinkan Anda untuk menjalankan kode Java di .NET.

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

Kode di bawah ini merupakan kode bahasa Stab untuk 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);
        }
    }
}

Transpiler Bytecode

Belalang dapat mengambil bytecode CLR dan mentranspilasinya untuk JVM. Ditujukan terutama untuk aplikasi web, ia tidak menyediakan, misalnya implementasi JVM kelas Windows Forms. Sepertinya agak kuno. Web berbicara tentang ASP.NET 2.0, Visual Studio 2008 dan seterusnya. Pertama kali disebutkan oleh @alex

XMLVM dapat menggunakan bytecode CLR atau JVM sebagai input dan menghasilkan salah satunya sebagai output. Selain itu dapat menampilkan Javascript atau Objective-C. Belum ada rilis, hanya Subversion. "Versi pengembangan eksperimental yang tidak akan digunakan dalam lingkungan produksi."

IKVM pergi ke arah lain dari yang diinginkan OP. Ini menyediakan implementasi JVM yang berjalan di CLR, transpiler bytecode JVM ke CLR dan generator rintisan metode library CLR untuk Java. http://www.ikvm.net/uses.html Disebutkan oleh @Jon Skeet

PPK

Mengapa CLR dan JVM tidak berjalan berdampingan dan membuat komunikasi sebebas mungkin? Ini bukan yang diinginkan OP, tetapi beberapa jawaban lain sudah cukup off topic dengan cara yang berbeda, jadi mari kita bahas.

RabbitMQ , memiliki opsi gratis, ini adalah server RPC yang ditulis dalam Erlang dengan pustaka API untuk C #, Java dan banyak lagi.

jnBridge , lisensi mungkin terlalu mahal untuk sebagian calon pengguna.

gRPC , dan library RPC modern serupa menawarkan dukungan bahasa yang luas, pembuatan kode untuk library klien dalam bahasa ini, format kabel independen bahasa untuk data, fitur lanjutan seperti pembatalan panggilan berjenjang, dan sebagainya.

Bahasa pemrograman

Menulis sekali, lari kemana-mana;)

Haxe , mengkompilasi ke C # / CLR, Java / JVM, Javascript, Flash, Python,… Menyediakan mekanisme interop untuk setiap bahasa target. Dapat dianggap sebagai penerus ActionScript3 sampai taraf tertentu. Tampaknya hal yang cukup solid, dengan setidaknya satu perusahaan benar-benar bergantung padanya. Jauh lebih bisa dipercaya daripada Stab, yang disebutkan selanjutnya.

Stab menghadirkan beberapa fitur C # dan interoperabilitas Java. Tidak terlalu berguna, Anda mendapatkan beberapa fitur C #, tetapi yang berinteraksi dengan Anda adalah kode Java yang tidak menggunakannya. https://softwareengineering.stackexchange.com/a/132080/45826 Bahasanya relatif tidak jelas, mungkin ditinggalkan, dengan sedikit janji untuk menjadi lebih baik. Pertama kali disebutkan di sini oleh @Vns.

Hembusan udara segar untuk platform JVM;)

Scala , Kotlin , dan lainnya, adalah bahasa yang cukup bagus yang dijalankan di atas JVM yang menghadirkan fitur-fitur yang mungkin terlewatkan oleh programmer C # di Java. Terutama Kotlin terasa seperti alternatif yang masuk akal untuk C # di dunia JVM. Scala mungkin bahasa yang terlalu besar bagi programmer untuk merasa nyaman dalam waktu singkat.

Mono

Itu tentu saja merupakan pilihan juga. Mengapa transpile ke JVM jika Mono dapat menjalankannya apa adanya. Pertama kali disebutkan oleh @ferhrosa

NEW YORK - 12 November 2014 - Pada hari Rabu, Microsoft Corp. memperkuat komitmennya terhadap pengalaman pengembang lintas platform dengan sumber terbuka tumpukan .NET sisi server penuh dan memperluas .NET untuk berjalan di platform Linux dan Mac OS.

Menurut siaran pers ini , Visual Studio 2015 akan menambahkan Linux / Mono sebagai platform yang didukung.

Ini adalah blog yang ditulis oleh orang-orang proyek Mono, dari sisi lain: Integrasi Kode Sumber .NET (November 2014).

.NET Core

Versi multiplatform Windows / Linux dari (beberapa) .Net diatur oleh Microsoft. kata nuff https://github.com/dotnet/core .

Kesimpulan

Sekarang perlu untuk mencoba alat / kerangka kerja ini dan melihat berapa banyak gesekan yang ada. OP ingin menulis dalam C # untuk JVM, yang sebenarnya bisa bekerja cukup baik menggunakan Belalang.

Melakukan ini dengan tujuan untuk mencampur C # dan pustaka dunia Java dalam satu basis kode mungkin tidak bekerja dengan baik.

Sumber

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

Mungkin lebih mudah untuk menulis konverter dari IL ke bytecode. Dengan cara itu Anda secara otomatis mendapatkan dukungan untuk bahasa .NET apa pun di JVM.

Namun, ini adalah gagasan yang jelas bahwa jika ini belum dilakukan, mungkin akan sangat sulit, atau sulit dilakukan dengan baik / berguna.

Lihatlah Belalang . Ini adalah SDK berbasis Visual Studio dan pengonversi .NET ke Java yang dipatenkan yang memungkinkan Anda menjalankan aplikasi Web .NET dan server di Linux® dan platform lain yang mendukung Java.

Opsi untuk pengembangan lintas platform di C # bisa berupa mono: http://www.mono-project.com/

Anda dapat menggunakan kompilator sumber-ke-sumber untuk menerjemahkan C # ke dalam bahasa daripada yang dijalankan pada JVM. Misalnya, ada beberapa konverter C # ke Java yang memungkinkan aplikasi C # berjalan di JVM setelah diterjemahkan ke dalam Java.

Jawaban ini mungkin terlambat untuk Anda, tetapi yang ini baru saja. Anda mungkin ingin memeriksa bahasa pemrograman Kotlin . Ia menawarkan gula sintaksis yang dimiliki C # dan yang paling dekat dengan sintaks C # juga, selain bahasa JVM Non-Java. Ini dari JetBrains .

Saya dapat melihat dua alasan mengapa hal ini tidak begitu menarik.

Hal pertama yang harus disadari adalah, ketika menyangkut fitur bahasa yang sebenarnya, C # dan Java sangat dekat. Tidak hanya C # amd Java yang dekat, mereka juga bergerak ke arah yang sama. Ada beberapa fitur yang saat ini tidak didukung JVM, tetapi itu bukan masalah sebenarnya. Anda selalu bisa memalsukan apa yang hilang. Saya pikir orang lebih suka menunggu Java untuk mendapatkan lebih banyak gula, daripada membuat Almost-Java dari awal. Pada saat port siap, Java mungkin telah memutuskan untuk menyusul.

Kedua, alasan mengapa pengembang lebih memilih C # bukanlah karena bahasanya itu sendiri, tetapi alat di sekitarnya, hubungan dua arah mereka dengan C # dan bagaimana Microsoft mendukung semuanya. Misalnya, kombo C # -XAML lebih ramah daripada JavaFX, karena C # dan XAML diretas untuk satu sama lain (mis. Kelas parsial di C #, binding di XAML, dan lainnya). Menggunakan C # di JavaFX tidak banyak meningkatkan. Untuk mendapatkan pengalaman C # di JVM, Anda juga perlu memindahkan alat, dan itu adalah proyek yang jauh lebih besar. Bahkan Mono tidak akan mengganggu.

Jadi, saran saya untuk pengembang Java, yang ingin menggunakan bahasa yang lebih bagus di atas alat yang sudah dikenal, adalah memeriksa bahasa JVM yang ada .

Mono juga merupakan pilihan, tetapi saya selalu skeptis terhadapnya. Meskipun C # - .NET dan lintas platform, hal-hal yang dibangun dengan alat Microsoft umumnya tidak akan berfungsi di Mono. Itu pada dasarnya adalah miliknya sendiri. Kita akan lihat apa yang terjadi sekarang karena Microsoft mengatakan mereka akan berkolaborasi.