JVM 용 C # 구현

JVM 용 C # 구현

---

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

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

---

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

몇 가지 예 :

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

아마도 많은 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에서 언급 함

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 brings some C# features and Java interoperability. Not very useful, you get some C# features, but what you interact with is Java code which does not use them. https://softwareengineering.stackexchange.com/a/132080/45826 The language is relatively obscure, possibly abandoned, with little promise to become better. First mentioned here by @Vns.

Gust of fresh air for the JVM platform ;)

Scala, Kotlin, others, are fairly nice languages running on top of JVM which bring features that a C# programmer may miss in Java. Especially Kotlin feels like a reasonable alternative to C# in the JVM world. Scala may be a bit too large language for a programmer to get comfortable with in a short time.

Mono

That is certainly an option too. Why transpile to JVM if Mono can run it as it is. First mentioned by @ferhrosa

NEW YORK — Nov. 12, 2014 — On Wednesday, Microsoft Corp. reinforced its commitment to cross-platform developer experiences by open sourcing the full server-side .NET stack and expanding .NET to run on the Linux and Mac OS platforms.

According to this press release from which the quote comes, Visual Studio 2015 will add Linux/Mono as a supported platform.

This is a blog written by the Mono project people about it, from the other side: .NET Source Code Integration (November 2014).

.NET Core

A Windows/Linux multiplatform version of (some of) .Net governed by Microsoft. 'nuff said https://github.com/dotnet/core.

Conclusion

It would be now necessary to give these tools/frameworks a try and see how much friction there is. The OP wants to write in C# for the JVM, which may actually work quite well using Grasshopper.

Doing this with the goal to mix C# and Java world libraries in a single codebase may not work so well.

Sources

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

---

It might be simpler to write a converter from IL to bytecode. That way you'd automatically get support for any .NET language on the JVM.

However, this is such an obvious idea that if this hasn't already been done, it's probably extremely hard, or hard to do well/usefully.

---

Look at Grasshopper. It is a Visual Studio-based SDK and patented .NET to Java converter that enables you to run .NET Web and server applications on Linux® and other Java-enabled platforms.

---

An option for cross-platform development in C# could be mono: http://www.mono-project.com/

---

You can use a source-to-source compiler to translate C# into a language than runs on the JVM. For example, there are several C# to Java converters that would allow C# applications to run on the JVM after being translated into Java.

---

This answer may be late for you, but this one is just new. You may want to checkout Kotlin programming language. It offers the syntactic sugars which C# has and its the closest to C# syntax too, other than any Non-Java JVM language. Its from JetBrains.

---

I can see two reasons why this isn't getting much enthusiasm.

The first thing to realise is that, when it comes to the actual features of the language, C# and Java are very close. Not only are C# amd Java close, they are also moving in similar directions. There are some features that the JVM won't currently support out of the box, but that's not the real problem. You can always fake what is missing. I think people prefer waiting for Java to get some more sugar, than to create an Almost-Java from scratch. By the time the port is ready, Java may have decided to catch up.

Secondly, the reason why developers prefer C# isn't so much the language itself, but the tools around it, their two-way relationship with C# and how Microsoft supports the whole thing. For example, the C#-XAML combo is friendlier than JavaFX, because C# and XAML were hacked for eachother (e.g. partial classes in C#, bindings in XAML and more). Using C# on JavaFX doesn't improve much. To get the C# experience on the JVM, you need to also port the tools, and that's a much bigger project. Not even Mono will bother.

So, my advice to a Java developer, who wants to use a fancier language ontop of familiar tools, is to check out the existing JVM languages.

Mono is an option too, but I have always been skeptical of it. Even though it is C#-.NET and cross-platform, things built with Microsoft's tools won't generally work on Mono. It is essentially its own thing. We'll see what happens now that Microsoft said they'll be collaborating.

참고URL : https://stackoverflow.com/questions/682608/implementing-c-sharp-for-the-jvm