CLR 与 Java（作为一种语言）不兼容吗？
我有一段时间想知道让 Java 在 CLR 上运行的可行性。
在这里看到前面的问题后，我意识到 Sun Java 平台和 .NET 运行时之间存在相当多的差异，这使得除了最微不足道的情况之外的所有情况下都无法进行交叉编译。
话虽如此，IL 不是图灵完备的语言吗？你不能用IL写一个JVM吗？答案当然是肯定的，但为什么要走那么远呢？
我的问题是：
CLR（作为一个平台）与Java作为一种语言（不是平台）不兼容吗？
为了适应 Java，需要扭曲或破坏多少 Java 内容？
当然，这个可以针对 CLR + .NET 进行编译：
import System.*;
public class HelloWorldExample
{
public static void main(String args[])
{
Console.WriteLine("Hello World !");
}
}
澄清：
我的意思是，我想知道 java 的哪些语言功能与其 CLR 对应项不兼容。
例如，我认为泛型在某种程度上是不一致的。我相信这是一个类似的故事，但也有例外。
I have wondered for a while about the feasibility of having Java run on the CLR.
After seeing a previous question here, I realize that there are quite a few differences between the Sun Java platform and the .NET runtime that would make cross-compiling impossible in all but the most trivial cases.
That being said, isn't IL a Turing-complete language? Couldn't you write a JVM in IL? Of course, the answer is yes, but why even go that far?
My question is:
Is the CLR (as a platform) incompatible with Java as a language (not a platform)?
How much of Java would have to be contorted or broken in order to make it fit?
Surely, this could be compiled for the CLR + .NET:
import System.*;
public class HelloWorldExample
{
public static void main(String args[])
{
Console.WriteLine("Hello World !");
}
}
Clarification:
What I'm getting at, is that I want to know what language features of java are incompatible with their CLR counterparts.
For example, I think that Generics are somehow in-congruent. I believe that it is as similar story with exceptions.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
CLR 的设计假设人们必须能够在很大程度上不加修改地编译其 Java 源代码，从而从 Java 过渡到 .Net。因此，您可能认为 Java 中运行时存在问题的事物（例如协变数组）作为 CLR 的功能包含在内。
J# 项目实现了足够的 Java 标准库，大多数 Java 应用程序只需进行最少的更改即可进行编译。请注意，J# 可以加载 JVM 字节码以实现兼容性，但 J# 源代码始终编译为 CLR 字节码。
The CLR was designed with the assumption that people would have to be able to transition to .Net from Java by being able to compile their Java source code largely unmodified. Thus, things in Java you might consider to be problematic in a runtime (like covariant arrays) are included as features in the CLR.
The J# project implements enough of the Java standard library that most Java apps will compile with minimal changes. Note that J# can load JVM bytecodes for compatibility, but J# source always compiles to CLR bytecodes.
快速搜索即可发现 IKVM 和正在进行的项目 Ja.NET.
也就是说，我可以看到走另一条路的价值。
A quick search reveals IKVM and the in-progress project Ja.NET.
That said, I could see value in going the other way.
是的，但是鉴于 Java 的使用更广泛且更标准……您难道不想反过来，即将 C# 编译为 Java 字节码吗？答案当然是可以编写一个为 CLR 生成字节码的 Java 编译器，或者编写一个生成 Java 字节码的 C# 编译器。但棘手的是，您需要提供一个或多个标准库的自定义实现，该实现将遵循该平台的一个或多个库。考虑到这两个 API 的规模，这将是一项相当重大的任务。这可能需要一个相当大的团队才能在合理的时间内完成。如果您打算这样做，我建议您启动一个开源项目，尽管考虑到 C#/CLR 是 Microsoft 主义，但我不确定可以产生多少热情。
Yes, but given that Java is much more widely used and more standard... wouldn't you want it the other way around, i.e. compile C# to Java bytecode? The answer of course is that it is possible to write a Java compiler that will emit bytecode for CLR or a C# compiler that will emit Java bytecode. The trickiness, though, is that you would need to provide a custom implementation of the standard library / libraries that would defer to the library or libraries for that platform. And given the size of both APIs that would be a fairly significant undertaking. This would probably require a fairly large team to get it done in a reasonable amount of time. I would suggest starting an opensource project if you intend to do that, although given that C#/CLR is a Microsoft-ism, I'm not sure how much enthusiam can be generated.