Why the Common Language Runtime Cannot Support Java [closed]

Asked 16/12, 2011 at 6:16 Answered 16/12, 2011 at 6:28

Today the Common Language Run Time Supports Many Languages including Iron Python and Iron Ruby. We can similarly can use J Ruby and J Python in Java Run Time environments . If so why the .net frame work common language run time cannot support for Java? Um just curious to know though u may see this as a dumb question .

Taegu answered 16/12, 2011 at 6:16 Comment(6)

The CLR directly competes with the JVM; why should the CLR support Java-based languages (or vice-versa)? – Stelle 16/12, 2011 at 6:17

BoltClock, there was J#, though ;-) – Rebato 16/12, 2011 at 6:20

Well we can develop Java Applications in .net run time environment – Taegu 16/12, 2011 at 6:20

ya J# it just vanished without a trace – Taegu 16/12, 2011 at 6:21

I think if Java can satisfy the conditions for CLS then it can be run under CLR. Right? – Since 16/12, 2011 at 6:21

Perhaps we just need a history lesson? en.wikipedia.org/wiki/… – Carotid 16/12, 2011 at 6:58

The CLR was actually designed so that it could do everything required to run Java. (Indeed, there are some warts in the way IL is defined which are there specifically for compatibility with Java.) You just need a way of converting bytecode to IL, or compiling from Java source code to IL. J# was one way of doing this, but the limitation of using Java 1.1.4 was a pretty huge one.

I suspect the reason for not going further wasn't an issue with running Java as a language, but the fact that system libraries would need porting. If you were willing to write Java-like source code but target .NET framework libraries (and only .NET framework libraries), with a version of the JLS which switched java.lang.String to System.String etc, it would be doable. I don't think there'd be much benefit though, when C# is simply a nicer language in almost all ways.

You may be interested in looking at IKVM.NET though - an implementation of Java running on the CLI.

Tessera answered 16/12, 2011 at 6:25 Comment(4)

Thank you i will go through the link – Taegu 16/12, 2011 at 6:32

Now you made me curious regarding those warts. I don't have terribly much experience in either JVM bytecode or the CIL, but is there somewhere where those warts are explained? – Rebato 16/12, 2011 at 6:39

@Joey: The annotated CLI specification, if I remember rightly. One example is array covariance (i.e. the ability to convert a reference of type String[] to Object[] etc.) – Tessera 16/12, 2011 at 7:3

I would agree that if you want CLR, use C#, not just because you might feel the language is nicer, but because there is tools support for using C# with .NET libraries. (And not for Java) – Parthenopaeus 16/12, 2011 at 9:27

First of all, Java may only be called Java if it compiles to JVM bytecode and runs on a certified JVM (iirc), those were the reasons behind Microsoft's efforts being named J++ and J#.

Then there is still J#, which is something close to Java, running on the CLR.

Then there is IKVM which is an implementation of a JVM and the class library on top of the CLR.

Actually, the class library might be the most annoying thing in this case. J# comes with an own library containing the Java core classes just for that purpose and the language closely ties in with that class library (just as it does in .NET).

The final thing though is probably: Why bother at all? Java itself would be a sub-par language on the CLR, where careful effort is needed to recreate things like its not-actual generics. Due to this interoperability with other CLR languages will likely be limited, too. There are powerful translators from Java to C# if you have a large Java codebase and want to use .NET, but a CLR-native Java, compatible with SuOracle's would be a lot of effort for something that you'd only want to touch for compatibility purposes and which poorly interfaces with the CLR or other .NET languages.

Rebato answered 16/12, 2011 at 6:28 Comment(1)

Why? To eat markedshare from Oracle and OpenJDK. The new release scheme would make an alternative deployment platform much more interesting. – Heard 17/5, 2018 at 13:38

CLR does support J#. In an utopian world CLR should have supported C# and Java, but Java is a competitor to Microsoft's C# and hence it won't support Java.

Filagree answered 16/12, 2011 at 6:21 Comment(3)

okay . that means is there a different in architectures? [CLR and JRE] if CLR supports JRE then CLR will degrade – Taegu 16/12, 2011 at 6:23

@Taegu Of course CLR and JRE are runtime envrionment with different architecture with the sole purpose of having a managed environment. I don't understand what do you mean when you say 'if CLR supports JRE then CLR will degrade ' – Filagree 16/12, 2011 at 6:25

If the reason were a competitive one, J# wouldn't have come out to start with, and there wouldn't be warts in the IL design specifically put in there to allow Java to run on the CLI. Now it's possible that the engineers wanted it to be available but others in MS didn't, but I think your "hence" is still a bit spurious. – Tessera 16/12, 2011 at 6:27

The way I see it, C# is a superset of Java, so you should technically be able to compile a Java class to CIL.

As others have pointed out, Microsoft has no intention of supporting their competition, however I see there have been some projects, such as Ja.NET, to compile Java code to the CLR. There's also IKVM.NET, which among other things seems to be able to translate Java bytecode to CIL, and includes the Java class library from OpenJDK compiled to .NET.

Pterosaur answered 16/12, 2011 at 6:22 Comment(5)

'C# is mostly a superset of Java, so you should technically be able to compile a Java class to IL no problem.' What does this mean? – Filagree 16/12, 2011 at 6:26

I mean that, if C# is a superset of Java, and C# compiles to CLR, then Java should also compile to CLR if someone wrote that compiler -- well, I suppose J# fits that bill, in a way. – Pterosaur 16/12, 2011 at 6:27

okay i found that CLR is dynamic and JRE is static – Taegu 16/12, 2011 at 6:31

C# and java do share their similarities but essentially are very different, heck, only look at the implementation of generics in both languages. – Quiche 16/12, 2011 at 6:59

I agree. However, since generics in Java don't exist in the compiled code, you can get Java-like generics by simply ignoring the support for generics in the CLR and performing type erasure as in Java. – Pterosaur 16/12, 2011 at 8:31

The respective Virtual Machines act on Intermediate Code in a different language (CIL for .net), and IL for .net and JVM are incompatible with each other.

The IL and Runtime features sometimes disallow a few things, for example Generics in C# are closely tied to how Generics in the .net Runtime work, while Java has a completely different implementation.

Still, there shouldn't be much technically preventing Java from running on .net, just no one did it yet. It's a massive effort, for what? Is there really enough money to make? If there is a business, someone will do it. But if you're in the business of Java, then most likely you are also tied closely to it's tools and environments, e.g. Eclipse and Tomcat, possibly Ant and Maven.

Jebel answered 16/12, 2011 at 6:27 Comment(0)

Recommended topics

Hot tags