 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / December 2005Compiling Java file to .NET managed code or vice versa?
Hi, Are there any experiments on compiling Java file to .NET managed code or compiling C# file to Java bytecode? It seems very interesting! 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. > 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. 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. > 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... [quoted text clipped - 7 lines] > 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. 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. > 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 [quoted text clipped - 5 lines] > 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. 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. > 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. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.