Có ai đang cố gắng triển khai C # cho JVM không? Là một nhà phát triển Java, tôi đã để mắt đến C # với sự ghen tị, nhưng tôi không sẵn lòng từ bỏ tính di động và sự trưởng thành của JVM, chưa kể đến hàng loạt công cụ đa dạng cho nó.
Tôi biết có một số điểm khác biệt quan trọng giữa JVM và CLR nhưng có điều gì là một showstopper không?
Câu trả lời:
Có sự khác biệt rất đáng kể giữa CLR và JVM.
Một vài ví dụ:
Bạn có thể chuyển rất nhiều C # - nhưng bạn sẽ bị bỏ lại với một trải nghiệm khá không hài lòng, IMO.
Đi theo hướng khác, bạn có biết về IKVM ? Nó cho phép bạn chạy mã Java trong .NET.
Truy cập http://code.google.com/p/stab-language
Đoạn mã dưới đây nếu là mã ngôn ngữ Stab cho 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);
}
}
}Grasshopper có thể lấy một mã bytecode CLR và chuyển nó cho JVM. Chủ yếu dành cho các ứng dụng web, nó không cung cấp triển khai JVM ví dụ như các lớp Windows Forms. Có vẻ hơi cũ, mặc dù. Trang web nói về ASP.NET 2.0, Visual Studio 2008, v.v. Được đề cập lần đầu bởi @alex
XMLVM có thể lấy CLR hoặc JVM bytecode làm đầu vào và sản xuất dưới dạng đầu ra. Ngoài ra, nó có thể xuất ra Javascript hoặc Objective-C. Chưa có bản phát hành nào, chỉ có Subversion. "Phiên bản phát triển thử nghiệm không được sử dụng trong môi trường sản xuất."
IKVM đi theo hướng khác mà OP muốn. Nó cung cấp một triển khai JVM chạy trên CLR, một trình vận chuyển mã bytecode JVM sang CLR và một trình tạo sơ khai phương thức thư viện CLR cho Java. http://www.ikvm.net/uses.html Được đề cập bởi @Jon Skeet
Tại sao không để CLR và JVM chạy cùng và làm cho việc giao tiếp trở nên dễ dàng nhất có thể? Đây không phải là những gì OP muốn, nhưng một số câu trả lời khác đã khá lạc đề theo những cách khác nhau, vì vậy hãy đề cập đến nó.
RabbitMQ , có một tùy chọn miễn phí, nó là một máy chủ RPC được viết bằng Erlang với các thư viện API cho C #, Java và hơn thế nữa.
jnBridge , giấy phép có thể quá đắt đối với một số người dùng tương lai.
gRPC và các thư viện RPC hiện đại tương tự cung cấp hỗ trợ ngôn ngữ rộng rãi, tạo mã cho thư viện khách bằng các ngôn ngữ này, định dạng dây độc lập ngôn ngữ cho dữ liệu, các tính năng nâng cao như hủy cuộc gọi theo tầng, v.v.
Viết một lần, chạy khắp nơi;)
Haxe , biên dịch sang C # / CLR, Java / JVM, Javascript, Flash, Python,… Cung cấp cơ chế tương tác cho từng ngôn ngữ đích. Có thể được coi như một người kế nhiệm ActionScript3 ở một mức độ nào đó. Có vẻ như những thứ khá chắc chắn, với ít nhất một công ty thực sự phụ thuộc vào nó. Đáng tin cậy hơn nhiều so với Stab, được đề cập tiếp theo.
Stab mang đến một số tính năng C # và khả năng tương tác Java. Không hữu ích lắm, bạn nhận được một số tính năng C #, nhưng những gì bạn tương tác với là mã Java không sử dụng chúng. https://softwareengineering.stackexchange.com/a/132080/45826 Ngôn ngữ tương đối tối nghĩa, có thể bị bỏ rơi, ít hứa hẹn sẽ trở nên tốt hơn. Lần đầu tiên được đề cập ở đây bởi @Vns.
Luồng không khí trong lành cho nền tảng JVM;)
Scala , Kotlin , những ngôn ngữ khác, là những ngôn ngữ khá đẹp chạy trên JVM mang lại các tính năng mà một lập trình viên C # có thể bỏ lỡ trong Java. Đặc biệt Kotlin cảm thấy như một sự thay thế hợp lý cho C # trong thế giới JVM. Scala có thể là một ngôn ngữ hơi quá lớn đối với một lập trình viên để sử dụng trong thời gian ngắn.
Đó chắc chắn cũng là một lựa chọn. Tại sao lại chuyển sang JVM nếu Mono có thể chạy nó như hiện tại. Được đề cập lần đầu bởi @ferhrosa
NEW YORK - Ngày 12 tháng 11 năm 2014 - Hôm thứ Tư, Microsoft Corp. đã củng cố cam kết của mình đối với trải nghiệm của nhà phát triển đa nền tảng bằng cách mở nguồn cung cấp đầy đủ ngăn xếp .NET phía máy chủ và mở rộng .NET để chạy trên nền tảng Linux và Mac OS.
Theo thông cáo báo chí có trích dẫn này, Visual Studio 2015 sẽ thêm Linux / Mono làm nền tảng được hỗ trợ.
Đây là một blog được viết bởi những người của dự án Mono về nó, từ phía bên kia: Tích hợp mã nguồn .NET (tháng 11 năm 2014).
Phiên bản đa định dạng Windows / Linux của (một số) .Net do Microsoft quản lý. 'nuff nói https://github.com/dotnet/core .
Bây giờ sẽ là cần thiết để thử các công cụ / khuôn khổ này và xem có bao nhiêu ma sát. OP muốn viết bằng C # cho JVM, có thể thực sự hoạt động khá tốt khi sử dụng Grasshopper.
Làm điều này với mục tiêu trộn các thư viện thế giới C # và Java trong một cơ sở mã duy nhất có thể không hoạt động tốt.
Nguồn
http://blog.pluralsight.com/new-course-making-java-and-c-work-together-jvm-and-net-clr-interop
Có thể đơn giản hơn khi viết một bộ chuyển đổi từ IL sang bytecode. Bằng cách đó, bạn sẽ tự động nhận được hỗ trợ cho bất kỳ ngôn ngữ .NET nào trên JVM.
Tuy nhiên, đây là một ý tưởng hiển nhiên đến nỗi nếu điều này chưa được thực hiện, nó có thể cực kỳ khó, hoặc khó làm tốt / hữu ích.
Hãy nhìn Grasshopper . Đây là SDK dựa trên Visual Studio và trình chuyển đổi .NET sang Java được cấp bằng sáng chế cho phép bạn chạy Web .NET và các ứng dụng máy chủ trên Linux® và các nền tảng hỗ trợ Java khác.
Một tùy chọn để phát triển đa nền tảng trong C # có thể là mono: http://www.mono-project.com/
Bạn có thể sử dụng trình biên dịch mã nguồn để dịch C # sang một ngôn ngữ hơn là chạy trên JVM. Ví dụ: có một số bộ chuyển đổi C # sang Java sẽ cho phép các ứng dụng C # chạy trên JVM sau khi được dịch sang Java.
Tôi có thể thấy hai lý do tại sao điều này không nhận được nhiều sự nhiệt tình.
Điều đầu tiên cần nhận ra là, khi nói đến các tính năng thực tế của ngôn ngữ, C # và Java rất gần nhau. Không chỉ C # amd Java gần, chúng cũng đang di chuyển theo các hướng tương tự. Có một số tính năng mà JVM hiện sẽ không hỗ trợ, nhưng đó không phải là vấn đề thực sự. Bạn luôn có thể giả mạo những gì còn thiếu. Tôi nghĩ mọi người thích đợi Java kiếm được nhiều đường hơn là tạo ra một Hầu như Java từ đầu. Vào thời điểm cổng đã sẵn sàng, Java có thể đã quyết định bắt kịp.
Thứ hai, lý do tại sao các nhà phát triển thích C # không phải là ngôn ngữ mà chính là các công cụ xung quanh nó, mối quan hệ hai chiều của họ với C # và cách Microsoft hỗ trợ toàn bộ điều này. Ví dụ: tổ hợp C # -XAML thân thiện hơn JavaFX, vì C # và XAML đã bị tấn công cho nhau (ví dụ: các lớp một phần trong C #, các liên kết trong XAML và hơn thế nữa). Sử dụng C # trên JavaFX không cải thiện nhiều. Để có được trải nghiệm C # trên JVM, bạn cũng cần phải chuyển các công cụ và đó là một dự án lớn hơn nhiều. Thậm chí không phải Mono cũng không bận tâm.
Vì vậy, lời khuyên của tôi dành cho một nhà phát triển Java, những người muốn sử dụng một ngôn ngữ lạ hơn ngoài các công cụ quen thuộc, là hãy kiểm tra các ngôn ngữ JVM hiện có .
Mono cũng là một lựa chọn, nhưng tôi đã luôn hoài nghi về nó. Mặc dù nó là C # -. NET và đa nền tảng, những thứ được xây dựng bằng các công cụ của Microsoft nói chung sẽ không hoạt động trên Mono. Về cơ bản nó là thứ riêng của nó. Chúng ta sẽ thấy điều gì sẽ xảy ra bây giờ khi Microsoft cho biết họ sẽ cộng tác.