JVM 용 C # 구현


91

JVM에 C #을 구현하려는 사람이 있습니까? Java 개발자로서 저는 C #을 부러워하고 있지만 JVM의 다양한 도구는 말할 것도없고 JVM의 이식성과 성숙도를 포기하고 싶지 않습니다.

JVM과 CLR 사이에 몇 가지 중요한 차이점이 있다는 것을 알고 있지만 눈에 띄는 것이 있습니까?


3
또한 Java로 많은 완전 멀티 플랫폼 앱을 작성했습니다. 저와 제 팀에게는 일상적인 일입니다. 우리는 일반적으로 공식적으로 "자격을 부여하는"각 플랫폼에서 테스트 계획을 실행하지만 테스트 버그가 플랫폼 차이로 인해 발생한 지 수년이 지났다고 생각합니다.
Jared

1
당사의 주요 제품은 Windows, OS X 및 Linux에서 변경없이 실행됩니다. 정말 어렵지 않습니다.
Thorbjørn Ravn Andersen

1
저는 Windows에서 Java를 수행하고, 다른 사람은 OSX에서 자신의 역할을 수행하고, CI는 Linux에서 모든 테스트를 처리하고, 소프트웨어를 다양한 Windows 및 Linux 서버, 심지어 Solaris에 배포했습니다. 그래서 저는 한동안 진정으로 완전한 다중 플랫폼 Java 프로그램을 작성했다고 말할 수있을 것 같습니다.
Esko

1
.NET에서 구현 된 JavaVM; Java LIBS의 .NET 구현 두 세계의 상호 운용성-> IKVM.NET ( ikvm.net )
gsscoder

1
... 당신이 (JSIL 예를 들어이 작업을 수행) 자바 스크립트로 .NET을 변환 할 수 있다면, 당신은 자바로 변환 할 수 있어야한다고 나에게 보인다
BrainSlugs83

답변:


93

CLR과 JVM 간에는 매우 중요한 차이가 있습니다.

몇 가지 예 :

  • Java에는 사용자 정의 값 유형이 없습니다.
  • Java 제네릭은 .NET 제네릭과 완전히 다릅니다.
  • C #의 많은 측면은 프레임 워크의 요소 (대리자 등)에 의존합니다 . 언어 측면 에서도 라이브러리를 이식해야합니다 .
  • Java는 JVM 수준에서 속성 및 이벤트와 같은 것을 지원하지 않습니다. 이 중 일부를 위조 할 수는 있지만 동일하지는 않습니다.
  • Java에는 JVM 수준에서도 참조에 의한 전달 매개 변수와 동등한 것이 있다고 생각하지 않습니다.
  • 다른 메모리 모델과 관련된 미묘함은 C # 사양에 얼마나 많은지 확실하지 않지만 물릴 수 있습니다.
  • 일반적으로 안전하지 않은 코드는 Java에서 가능하지 않을 수 있습니다.
  • 네이티브 코드와의 상호 운용성은 JNI와 P / Invoke간에 매우 다릅니다. 이것은 아마도 당신에게 큰 문제가되지 않을 것입니다.
  • 연산자 오버로딩과 사용자 정의 변환을 위조해야합니다.

많은 C #을 이식 할 수 있지만 IMO라는 꽤 불만족스러운 경험이 남아있을 것입니다.

반대로 IKVM 을 알고 있습니까? .NET에서 Java 코드를 실행할 수 있습니다.


7
Java에는 종료자가 있으며 .NET 종료도 결정적이지 않습니다. 둘 사이에 약간의 미묘한 차이가있을 수 있지만, 나는 어떤 상황에서도 생각할 수 없습니다. Java의 도달 가능성 테스트가 .NET보다 강력하다고 생각합니다. 다른 스레드가 인스턴스 메서드를 실행하는 동안에는 종료가 없습니다
Jon Skeet

3
값 유형을 참조 유형에 매핑 할 수 있다고 생각합니다. 모든 할당을 얕은 복제로 만드십시오!
Daniel Earwicker

3
@Earwicker : ... 배열 할당을 변경하고 의미론이 차이를 만드는 다른 여러 장소? 나는 될 것이다 의심 매우 작업에 구하기 힘든 경우 가 가능하고, 결과는 사용할 줄 뭔가하지 않을 것입니다.
Jon Skeet

4
제네릭도 해결할 수 있다고 생각합니다. 유형 매개 변수에 대한 Class 객체를 보유하려면 추가 필드가있는 Java 클래스를 생성해야하므로 약간의 오버 헤드가 추가되지만 새로운 T () 및 typeof (T)를 사용할 수 있습니다.
Daniel Earwicker

30
@Jon Skeet : 그것은 당신에게 두 세계의 최악의 상황을 제공합니다 : 마이크로 소프트의 독점 플랫폼에서 자바의 다소 오래된 언어입니다.
Bart van Heukelom 2010

43

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

7
stab은 JVM에서 C # 언어의 대부분을 제공하지만 Java 상호 운용이 가능한 방식으로 제공합니다. 따라서 .NET CLR 용으로 작성된 C # 코드와 엄격하게 호환되는 소스 코드는 아니지만 Java 프로그래머가 동일한 품질의 바이트 코드를 생성하고 Java 라이브러리 및 프레임 워크와 비 임피던스 상호 운용성을 가지면서도 C #과 유사한 언어를 즐길 수 있습니다. JVM에서 C #을 얻기위한 올바른 접근 방식입니다.
RogerV 2010

1
좋은 플랫폼에서 좋은 언어 ... 내가이 년 전에 우연히 발견했으면 좋겠어.
Jefferey Cave 2014.01.09

15

바이트 코드 트랜스 파일러

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에서 언급 함

RPC

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 월)입니다.

.NET Core

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


좋은 대답! Java로 전환하는 데 불만이 있고 (속성없이 어떻게 살 수 있습니까?!) Scala에 대해 모호한 C # 개발자로서, 이것은 실제로 옵션을 잘 설명합니다.
Gilthans 2015 년

9

IL에서 바이트 코드로 변환기를 작성하는 것이 더 간단 할 수 있습니다. 이렇게하면 JVM에서 모든 .NET 언어에 대한 지원을 자동으로받을 수 있습니다.

그러나 이것은 이것이 아직 수행되지 않았다면 아마도 매우 어렵거나 잘 / 유용하게 수행하기 어렵다는 명백한 아이디어입니다.


6
당신은 내가 나열한 대부분의 문제를 겪게 될 것입니다-다른 제네릭 등등.
Jon Skeet

8
이것은 Grasshopper 가하는 일입니다 (위의 @alex의 답변 참조) 실제로 잘하기가 매우 어렵습니다 (나는 Grasshopper에서 작업했습니다).
Motti

7

Grasshopper를 보세요 . Linux® 및 기타 Java 지원 플랫폼에서 .NET 웹 및 서버 응용 프로그램을 실행할 수 있도록하는 Visual Studio 기반 SDK 및 특허를받은 .NET to Java 변환기입니다.


2
실제 경험이 있습니까? 또한 라이센스는 무료 버전의 경우 용감합니다.
Thorbjørn Ravn Andersen

13
"특허"라는 단어를 말하는 순간 당신은 내 관심을 잃었습니다. 한숨.
Stephen C

2
몇 가지 소식 : Grasshopper는 이제 지원 및 보증없이 무료로 제공됩니다 (대부분의 오픈 소스 제품처럼).
fernacolo

1
Mainsoft는 완전히 죽은 것처럼 보이며 Grasshopper 링크는 더 이상 작동하지 않습니다.
다윗은 주어

1
그럼 그냥 그물 흔들림이 분명합니다. 이제 두 링크가 모두 작동합니다. 내가 원하는 이유는 불행하게도 지금은 기억이 안나요 ...
데이비드을 감안할 때



0

이 답변은 늦을 수 있지만 이것은 새로운 것입니다. 당신은 체크 아웃 할 수 있습니다 코 틀린의 프로그래밍 언어를. 비 Java JVM 언어를 제외하고 C #에있는 구문 설탕과 C # 구문에 가장 가까운 구문을 제공합니다. 그것에서 JetBrains의 .


0

나는 이것이 그다지 열정을 얻지 못하는 두 가지 이유를 알 수 있습니다.

가장 먼저 깨달아야 할 것은 언어의 실제 기능과 관련하여 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가 공동 작업 할 것이라고 말한 지금 어떤 일이 발생하는지 살펴 보겠습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.