Compiling Java file to .NET managed code or vice versa?

[=?iso-8859-1?B?bW9vcJk=?=]

Hi,
Are there any experiments on compiling Java file to .NET managed code
or compiling C# file to Java bytecode? It seems very interesting!

 

[Ranganath Kini]

Yes, there have not only been experiments but also commercial products
which are capable of compiling Java source code to the Common
Intermediate Language (CIL) of .NET. Microsoft's Visual J# is one such
product that ships with Visual Studio.NET. It is capable of compiling
Java language source code to .NET assemblies. Even the Visual C#.NET
that ships with VS.NET, comes with a Java Language Conversion Assistant
(JLCA) which can help u import existing java source code and convert it
to C# source code.

But as of now there has been no news of compilers capable of compiling
C# to Java bytecode programs. In my opinion, C# to Java bytecode
compilation cannot be possible as C# has a larger set of features than
Java (such as properties, events, delegates, operator overloading)
which cannot be emulated thru Java bytecodes. Java Bytecodes were not
designed to support such facilities.

The other problem is the Java API class library which is much more
different that the .NET Base Class Library (BCL). So even if u r
successful in converting Java source to C# source, u will still have to
modify ur code to use classes from the BCL rather than the classes from
the Java Class Library.

 

[Mike Schilling]

But as of now there has been no news of compilers capable of compiling
C# to Java bytecode programs. In my opinion, C# to Java bytecode
compilation cannot be possible as C# has a larger set of features than
Java (such as properties, events, delegates, operator overloading)
which cannot be emulated thru Java bytecodes. Java Bytecodes were not
designed to support such facilities.

The ones you mention aren't a problem, really. Properties are syntactic
sugar for getters and setters, events are just callbacks, delegates can be
emulated via reflection, and operator overloading is just another syntax for
function calls. These could be translated directly from C# to Java and then
compiled with no real difficulty.

There are a few things that are harder, since they break with the Java
convention all all non-private methods with the same signature are
indistinguishable: non-virtual methods and "new" methods (same signature,
no override). Interfaces are different in C# too; if a class implements two
interfaces that both define, say, void foo(), it can implement the two foo's
differently. These can't be directly represented in Java [1]. I'm not
enough of a bytecode hacker to know if it can do that.

Then there are C# 2.0 generics, which are "real" generics: no type erasure,
and new types like Map(<String>, <Document>) created dynamically. Existing
JVMs just can't do that.

1. Without playing games like adding dummy parameters to change the
signatures, anyway.

 

[Ranganath Kini]

Well yes, its not like you cannot emulate properties, events,
delegates, operator overloading of C# in the Java language. All Im
saying is that these are first class features of C# and make the
language more expressive. If u do emulate them in Java, u loose the
syntactic conveinece that u have in C#. For example the C# feature of
operator loading becomes verbose and looses its elegance.

And some of the emulated features might also add to performance
problems due to excessive method calls or other housekeeping
operations. Then the more complex things such as unsafe code blocks in
C# dont have a direct syntactic expression in Java.

And yes, some of the convention changes u mentioned r not compatible
with Java. The other conventions that break with Java are things like
absence of the concept of checked exceptions, absence of the concept of
non-static nested classes, C# 2.0's anonymous method ( may roughly be
similar to Java's anonymous classes), etc...

Overall, there can be smart ways to bring in functionality of C# into
Java, but it becomes harder to work with those features in Java as Java
does not support them as first class features. They become less
expressive or usable.

The simple fact is C# is more feature rich than Java and provides best
expriences to work with modern features than Java does. Hence
conversion from C# do Java is not a prefereable thing to do.

 

[Mike Schilling]

Well yes, its not like you cannot emulate properties, events,
delegates, operator overloading of C# in the Java language. All Im
saying is that these are first class features of C# and make the
language more expressive. If u do emulate them in Java, u loose the
syntactic conveinece that u have in C#. For example the C# feature of
operator loading becomes verbose and looses its elegance.

But your statement was they they couldn't be exppessed in bytecode. If they
can be emulated in Java, then obviously they can be expressed in bytecode.

And some of the emulated features might also add to performance
problems due to excessive method calls or other housekeeping
operations. Then the more complex things such as unsafe code blocks in
C# dont have a direct syntactic expression in Java.

This is true; .NET plays nicer with non-.NET code than Java does with
non-Java code.

And yes, some of the convention changes u mentioned r not compatible
with Java. The other conventions that break with Java are things like
absence of the concept of checked exceptions,

This makes .NET *less* expressive than Java; it's as if all Java methods
were declared "throws Throwable".

absence of the concept of
non-static nested classes,

Again, less expressive

C# 2.0's anonymous method ( may roughly be
similar to Java's anonymous classes), etc...

Overall, there can be smart ways to bring in functionality of C# into
Java, but it becomes harder to work with those features in Java as Java
does not support them as first class features. They become less
expressive or usable.

The simple fact is C# is more feature rich than Java and provides best
expriences to work with modern features than Java does. Hence
conversion from C# do Java is not a prefereable thing to do.

C++ had more features still; it's not always a good thing.

 

[Ranganath Kini]

About my first reply, I apologize, perhaps I shud have rephrased it
more clearly. My intention was to say that one "could" emulate features
of C# in Java but u "cannot do full justice" to those emulated
features. In sense that you cannot use them in Java with the same
flexibility as u can in C#.

This makes .NET *less* expressive than Java; it's as if all Java methods
were declared "throws Throwable".

My intention here is not to compare or decide which is a superior
platform. I want to highlight the difference between .NET and Java in
the context of source code translation from the former to the latter. I
want to say that if u need to translate from C# to Java, u need special
treatment to exceptions. Certain checked exceptions of Java correspond
to unchecked exceptions of .NET, so u need special care when u
translate from C# to Java and ensure that the Java code uses proper
try...catch...blocks to handle checked exceptions. The same with
non-static nested classes.

And no doubt C++ has many features. But where C# and Java compile to
intermediate code, C++ code is popularly( here im not considering
managed extentions to C++) compiled to native code. Also C# and Java
resemble a lot in terms of features than C++ . So I can keep C++ out of
the scope of this discussion.

 

[Mike Schilling]

My intention here is not to compare or decide which is a superior
platform. I want to highlight the difference between .NET and Java in
the context of source code translation from the former to the latter. I
want to say that if u need to translate from C# to Java, u need special
treatment to exceptions. Certain checked exceptions of Java correspond
to unchecked exceptions of .NET, so u need special care when u
translate from C# to Java and ensure that the Java code uses proper
try...catch...blocks to handle checked exceptions. The same with
non-static nested classes.

You'ce picked two of the easiest things to "emulate". All C# exceptions are
unchecked, so any translated Java methods should "throw Throwable". And all
nested classes should become static.

 

[Ranganath Kini]

It isnt as easy as having all translated method to "throws Throwable".
No doubt u cud do that, but wats the idea then of having specialized
exceptions to trap special error conditions. For example, the
System.IO.IOException is an unchecked exception but the
java.io.IOException is a checked exception.

I write a C# program that works with files and has method that may
possibly throw an System.IO.IOException. When I translate this program
into Java, I cannot simply translate the method and have it marked as
"throws Throwable", if I do so, after translation, I again need to go
thru the translated Java code and change "throws Throwable" to "throws
IOException" so that I can handle IOException properly and also adhere
to Java's notion of handling checked exceptions.

This is one of the reasons why I say that a translation from C# to Java
is not a elegant one.

 

[Mike Schilling]

It isnt as easy as having all translated method to "throws Throwable".
No doubt u cud do that, but wats the idea then of having specialized
exceptions to trap special error conditions. For example, the
System.IO.IOException is an unchecked exception but the
java.io.IOException is a checked exception.

Because C# doesn't declare what exceptions are thrown by a method, all C#
exceptions are unchecked. This is precisely like a Java method that
declares "throws Throwable", not that it does throw every possible
exception, but that it might. You need to do some reading about what
"checked exception" means.