JVM에 C #을 구현하려는 사람이 있습니까? Java 개발자로서 저는 C #을 부러워하고 있지만 JVM의 다양한 도구는 말할 것도없고 JVM의 이식성과 성숙도를 포기하고 싶지 않습니다.
JVM과 CLR 사이에 몇 가지 중요한 차이점이 있다는 것을 알고 있지만 눈에 띄는 것이 있습니까?
JVM에 C #을 구현하려는 사람이 있습니까? Java 개발자로서 저는 C #을 부러워하고 있지만 JVM의 다양한 도구는 말할 것도없고 JVM의 이식성과 성숙도를 포기하고 싶지 않습니다.
JVM과 CLR 사이에 몇 가지 중요한 차이점이 있다는 것을 알고 있지만 눈에 띄는 것이 있습니까?
답변:
CLR과 JVM 간에는 매우 중요한 차이가 있습니다.
몇 가지 예 :
많은 C #을 이식 할 수 있지만 IMO라는 꽤 불만족스러운 경험이 남아있을 것입니다.
반대로 IKVM 을 알고 있습니까? .NET에서 Java 코드를 실행할 수 있습니다.
http://code.google.com/p/stab-language를 방문합니다 .
JVM 용 Stab 언어 코드 인 경우 아래 코드
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 는 CLR 바이트 코드를 가져와 JVM 용으로 트랜스 파일 할 수 있습니다. 주로 웹 앱을위한 것으로 Windows Forms 클래스의 JVM 구현 등을 제공하지 않습니다. 하지만 다소 구식 인 것 같습니다. 웹에서는 ASP.NET 2.0, Visual Studio 2008 등에 대해 이야기합니다. @alex가 처음 언급 함
XMLVM 은 CLR 또는 JVM 바이트 코드를 입력으로 사용하고 출력으로 생성 할 수 있습니다. 또한 Javascript 또는 Objective-C를 출력 할 수 있습니다. 아직 릴리스가없고 Subversion 만 있습니다. "프로덕션 환경에서 사용하지 않는 실험용 개발 버전입니다."
IKVM 은 OP가 원하는 방향과는 다른 방향으로 진행됩니다. CLR에서 실행되는 JVM 구현, CLR 바이트 코드 변환기에 대한 JVM 및 Java 용 CLR 라이브러리 메서드 스텁 생성기를 제공합니다. http://www.ikvm.net/uses.html @Jon Skeet에서 언급 함
CLR과 JVM을 함께 실행하고 가능한 한 마찰없이 통신을하지 않는 이유는 무엇입니까? 이것은 OP가 원하는 것이 아니지만 다른 답변은 이미 다른 방식으로 주제에서 벗어 났으므로 다루겠습니다.
RabbitMQ 에는 무료 옵션이 있으며 C #, Java 등을위한 API 라이브러리와 함께 Erlang으로 작성된 RPC 서버입니다.
jnBridge , 일부 잠재 사용자에게는 라이센스가 너무 비쌀 수 있습니다.
gRPC 및 이와 유사한 최신 RPC 라이브러리는 광범위한 언어 지원, 이러한 언어로 된 클라이언트 라이브러리에 대한 코드 생성, 데이터에 대한 언어 독립적 유선 형식, 계단식 호출 취소 등의 고급 기능을 제공합니다.
한 번 작성하고 어디에서나 실행하십시오.)
Haxe 는 C # / CLR, Java / JVM, Javascript, Flash, Python 등으로 컴파일됩니다. 각 대상 언어에 대한 interop 메커니즘을 제공합니다. 어느 정도는 ActionScript3의 후속 제품으로 생각할 수 있습니다. 적어도 하나의 회사가 실제로 그것에 의존하는 꽤 견고한 것 같습니다. 다음에 언급 된 Stab보다 훨씬 더 신뢰할 수 있습니다.
Stab 은 일부 C # 기능과 Java 상호 운용성을 제공합니다. 별로 유용하지는 않지만 C # 기능을 사용할 수 있지만 상호 작용하는 것은이를 사용하지 않는 Java 코드입니다. https://softwareengineering.stackexchange.com/a/132080/45826 언어는 상대적으로 모호하고 버려 질 수 있으며 더 나아질 가능성이 거의 없습니다. @Vns가 여기서 처음 언급했습니다.
JVM 플랫폼을위한 신선한 공기 돌풍;)
Scala , Kotlin 등은 Java에서 C # 프로그래머가 놓칠 수있는 기능을 제공하는 JVM 위에서 실행되는 상당히 멋진 언어입니다. 특히 Kotlin은 JVM 세계에서 C #에 대한 합리적인 대안처럼 느껴집니다. Scala는 프로그래머가 짧은 시간에 익숙해지기에는 너무 큰 언어 일 수 있습니다.
그것은 확실히 옵션입니다. Mono가있는 그대로 실행할 수 있다면 JVM으로 트랜스 파일하는 이유. @ferhrosa가 처음 언급 함
뉴욕 — 2014 년 11 월 12 일 — 수요일에 Microsoft Corp.는 전체 서버 측 .NET 스택을 오픈 소싱하고 Linux 및 Mac OS 플랫폼에서 실행되도록 .NET을 확장함으로써 크로스 플랫폼 개발자 경험에 대한 약속을 강화했습니다.
인용문이 나온 이 보도 자료 에 따르면 Visual Studio 2015는 Linux / Mono를 지원되는 플랫폼으로 추가합니다.
이것은 Mono 프로젝트 사람들이 다른 쪽에서 작성한 블로그입니다. .NET 소스 코드 통합 (2014 년 11 월)입니다.
Microsoft가 관리하는 (일부) .Net의 Windows / Linux 멀티 플랫폼 버전. 'nuff는 https://github.com/dotnet/core 말했다 .
이제 이러한 도구 / 프레임 워크를 사용해보고 마찰이 얼마나 많은지 확인해야합니다. OP는 실제로 Grasshopper를 사용하여 잘 작동 할 수있는 JVM 용 C #으로 작성하려고합니다.
단일 코드베이스에서 C # 및 Java 세계 라이브러리를 혼합하려는 목표를 가지고이 작업을 수행하면 제대로 작동하지 않을 수 있습니다.
출처
http://blog.pluralsight.com/new-course-making-java-and-c-work-together-jvm-and-net-clr-interop
IL에서 바이트 코드로 변환기를 작성하는 것이 더 간단 할 수 있습니다. 이렇게하면 JVM에서 모든 .NET 언어에 대한 지원을 자동으로받을 수 있습니다.
그러나 이것은 이것이 아직 수행되지 않았다면 아마도 매우 어렵거나 잘 / 유용하게 수행하기 어렵다는 명백한 아이디어입니다.
Grasshopper를 보세요 . Linux® 및 기타 Java 지원 플랫폼에서 .NET 웹 및 서버 응용 프로그램을 실행할 수 있도록하는 Visual Studio 기반 SDK 및 특허를받은 .NET to Java 변환기입니다.
C #의 크로스 플랫폼 개발 옵션은 모노 일 수 있습니다. http://www.mono-project.com/
소스 대 소스 컴파일러 를 사용하여 C #을 JVM에서 실행되는 언어로 번역 할 수 있습니다 . 예를 들어, C # 애플리케이션이 Java로 변환 된 후 JVM에서 실행되도록하는 C # to Java 변환기 가 여러 개 있습니다.
이 답변은 늦을 수 있지만 이것은 새로운 것입니다. 당신은 체크 아웃 할 수 있습니다 코 틀린의 프로그래밍 언어를. 비 Java JVM 언어를 제외하고 C #에있는 구문 설탕과 C # 구문에 가장 가까운 구문을 제공합니다. 그것에서 JetBrains의 .
나는 이것이 그다지 열정을 얻지 못하는 두 가지 이유를 알 수 있습니다.
가장 먼저 깨달아야 할 것은 언어의 실제 기능과 관련하여 C #과 Java가 매우 가깝다는 것입니다. C #과 Java는 비슷할뿐만 아니라 비슷한 방향으로 움직이고 있습니다. JVM이 현재 기본적으로 지원하지 않는 몇 가지 기능이 있지만 실제 문제는 아닙니다. 당신은 항상 빠진 것을 속일 수 있습니다. 사람들은 처음부터 거의 자바를 만드는 것보다 자바가 더 많은 설탕을 얻기를 기다리는 것을 선호한다고 생각합니다. 포트가 준비 될 때까지 Java는 따라 잡기로 결정했을 수 있습니다.
둘째, 개발자가 C #을 선호하는 이유는 언어 자체가 아니라 그 주변의 도구, C #과의 양방향 관계 및 Microsoft가 전체를 지원하는 방법 때문입니다. 예를 들어 C # -XAML 콤보는 JavaFX보다 친숙합니다. C #과 XAML이 서로 해킹 되었기 때문입니다 (예 : C #의 부분 클래스, XAML의 바인딩 등). JavaFX에서 C #을 사용해도 크게 개선되지는 않습니다. JVM에서 C # 경험을 얻으려면 도구도 이식해야하며 이는 훨씬 더 큰 프로젝트입니다. Mono 조차도 신경 쓰지 않습니다 .
따라서 익숙한 도구 위에 더 멋진 언어를 사용하고 싶은 Java 개발자에게 제 조언은 기존 JVM 언어 를 확인하는 것 입니다.
모노도 옵션이지만 나는 항상 그것에 대해 회의적이었습니다. C #-. NET 및 크로스 플랫폼이지만 Microsoft 도구로 빌드 된 것은 일반적으로 Mono에서 작동하지 않습니다. 본질적으로 그 자체입니다. Microsoft가 공동 작업 할 것이라고 말한 지금 어떤 일이 발생하는지 살펴 보겠습니다.