Why doesn't Sun do a C# to Java byte code compiler?

Question

We Want to Run Our C# Code on the JVM

My company has a large C# code base. Well over half of this code is our core engine for creating, reading, modifying, calculating and writing Excel workbooks. We frequently get questions from customers and potential customers asking whether we are going to build a Java version of our engine - many of them are not at all interested in the UI. We even have a few customers who have taken the trouble to use our .NET library from their Java applications.

So, we would like to build a Java version of our core engine, ideally without maintaining a separate Java source code base.

Eric Sink described this problem very well. I am in a similar position except for the fact that our software license includes royalty free deployment, making Eric's choice of Mainsoft a nonstarter for us.

I have been Googling the likes of "c# to jvm" every few months for several years now with no joy. Having spent ~7 years developing similar software for Java, I am confident that the .NET APIs we use in our core engine could easily be encapsulated and we could accomplish everything we need using the Java libraries. So, if we only had a C# -> JVM compiler we could build our core engine for Java and we would no longer have to turn away Java developers who would like to use it.

I am not asking for the technical reasons why Sun does not do a C# compiler. I recognize that Java has no properties or an unsigned 64 bit long, etc... For the sake of argument, just assume that all of these technical issues could be dealt with by extending the JVM and / or other means.

And I am not asking for yet another debate on why one language / stack might be better than the other. The reality in our business is that there are plenty of potential customers using each.

Why Should Sun do a C# Compiler? (IMO of course)

Making it easier to run C# code on the Java platform means more developers and more software for the platform. Is there anything more important to the success of a platform? Jonathan Schwartz is a software guy. I will leave it to others smarter than me to decide whether or not he took on an impossible job as President and CEO of Sun, but having met with Jonathan shortly after he joined Sun my impression is that he understands software and the need for a large base of developers.

So Why Doesn't Sun do a C# Compiler?

1. NIH syndrome?
2. The ghost of Scott McNealy?
3. Too many Java developers dislike or distrust anything related to Microsoft?
4. They agreed not to as part of taking the big bucks?
5. ???

There must be a good reason. I just cannot for the life of me figure out what it is...

Answer 1

Joe Erickson wrote:

Making it easier to run C# code on the Java platform means more developers and more software for the platform.

This is an untrue statement. Running C# code on the JVM does not create Java programmers, it creates C# programmers who can execute on a JVM. It only expands the reach of C#, assuming the JVM also translates any microsoft specific calls (i.e. win32) into something that is platform neutral. So if Sun translates IL to Java Bytecode, the only group it helps is: Microsoft. And, given Sun's history with Microsoft during the original C#-Java schism/Visual J++ lawsuits...

Plus, you have to face the technical infeasibility, whether you want to or not. There are fundamental differences in the way the bytecodes are executed that are far more important issues than whether or not there's an unsigned long datatype.

If you must have C# on a non-Microsoft platform, use Mono

Answer 2

Firstly Sun have zero incentive to implement a C# compiler on the JVM because they have something very similar called the Java programming language.

Its also not really as simple as just implementing a compiler as the Java standard class libraries are not the same as the .net Base Class Libraries. You would end up having to change all the .NET API calls to Java API calls.

Micrsoft had a product called J# which was meant to be for Java to .NET conversion but in the end no one used it as the API was limited to pre Java 2 API so it was mostly useless. It would be the same if Sun implemented parts of the .NET BCL, as only the core portons of it are standardised and royalty free. Parts like ASP.NET and WPF, WCF etc are not part of the ECMA standards and so Sun would need Microsofts permission to implement those API's.

If enough customers want a java version to make business sense to port your application to java then do it, you just wont ever get any help from Sun via a C# to JVM compiler.

Answer 3

Why doesn't Microsoft do a C# to Java byte code compiler? Why don't you do it? There are open specs on each side...

Answer 4

Have fun.

1. Must break checked exceptions.
2. Must find a way to implement delegates (which are like single-method interfaces added no earlier than load time).

Answer 5

You can run your .NET code and Java code in the same interpreter! See the IKVM .NET-based JVM, and the Boo and Java wiki page for an example use case (using the .NET-based Boo language to write applications using Java libraries).

Answer 6

Joe, I suggest you investigate IKVM. You might find something there that scratches your itch

Answer 7

Expose your .NET API as ASMX web services and you should be good to go.

EDIT: For more heavy-usage scenarios, it would be worth looking into Windows Communication Foundation (WCF). This has built-in, configurable support for security, streaming, different transport scenarios (HTTP, TCP/IP, local named pipes). You are not restricted to SOAP message encoding, but that would probably be the easiest way to interop with Java.

I'm not too sure about your exact scenario, but if you're dealing with large files and the .NET code and Java code are both running locally, you can just save the file to the user's hard drive using .NET and then fetch it from your Java app.

Answer 8

"So, we would like to build a Java version of our core engine, ideally without maintaining a separate Java source code base."

Basically, you want to compile your C# code unmodified, and have it run in a Java-only environment.

IKVM is not what you want. IKVM is three main things.

a. ikvm - CLI implementation of a Java virtual machine (note that this uses Classpath for the Java class library).

b. ikvmc - Compiles java bytecode to CLI bytecode.

c. ikvmstub - Generates java stub classes that call CLI code.

Note that all of these tools depend on CLI at runtime. What you want is exactly the opposite of IKVM, which is of course MVKI (Most Venerable Kompiler Intermediary) :):

a. mvki - Java implementation of a CLI virtual machine (presumably this would use Mono or DotGNU for the class library).

b. mvkic - Compiles CLI bytecode to Java bytecode.

c. mvkistub - Generates CLI stub classes that call Java

Note that none of these would require an existing implementation of the .NET Framework at runtime, so they should be satisfactory to your Java-only customers.

Unfortunately, as far as I know MVKI does not exist, so you're best off doing a manual port (which would inevitably be cleaner, albeit more work).

Edit: Based on the description of Mainsoft, it appears to be similar to mvki, though I'm not sure what they do for the class library, and unlike IKVM it's not FOSS.

Answer 9

I think your find that this tool Mainsoft, Enterprise Edition allows you to run most/maybe all your .NET code under the Java JVM.... Seems to be focused more on ASP.NET but will allow C#. It's has been available for sometime, pitty they don't publise it better!

Tony

Warning Blurb follows....

Mainsoft® is Java-.NET interoperability software that enables IT organizations to move to Java-enabled platforms such as Linux while preserving existing investments in .NET code and skills. The software integrates seamlessly into the Visual Studio® development environment, enabling C# and Visual Basic developers to rapidly develop and maintain server and Web applications that run on Windows, Java EE platforms or both, thereby reducing application development and maintenance costs, time-to-production and total cost of ownership.

Answer 10

If i was doing something like cross platform cross language support, I would create a 'common api' since the languages are similar in syntax you could make a translator easy enough. Then instead of calling java or .net apis directly from the core, you would call your 'common api' which would re implement the java and .net apis you would need. In this way you could create a cross language sandbox if you will. Since the main differences in java and c# are object definitions, I would get those by reflecting the C# dlls, and then reconstruct the constructs, then it would be easy to have an interpreter run through and implement the function bodies and convert properties to getters setters already knowing the structure of the files. This of course is assuming .net 2.0, some of the features in 3.0 and 3.5 become very difficult to 'interpret'

It would be complex, but probably not as complex as reconstructing a core in java by hand, and having to have 2 teams working on them seperatly. If this idea sparks some inspiration i might create one. I would really rather see a simpler stable mono installation for mac.

Basically I think a code level interpreter based on a set of common api classes is something very possible to write with a team in a week or two.

Answer 11

There must be a good reason. I just cannot for the life of me figure out what it is...

It is easy to believe that companies are non-profit organisations which have your interests at heart. It is easy to forget that the only purpose for a listed company is to make money for it share holders. This is a legal obligation and directors/executives have been sacked/sued if share holders don't believe they have failed to do this.

Sun makes Java free because it helps sell their hardware which how it makes money from Java. IBM makes Java free because it helps them make more money on their consulting.

If Sun were to spend money on a C# converter how would it make that money back and make a profit. Imagine you have to convince Sun's share holders. If you can, Sun will make a C# converter.

Answer 12

Simple. Because Sun would rather not be sued by Microsoft. And while we as programmers might see no viable reason for a suit, keep in mind that Microsoft is quite a bigger company than Sun and has the power to boss them around.

Sun fortunately is in the position of being quite more open than Microsoft however. If such a demand exists, either open source or a third-party could make this compiler for Java and Sun wouldn't have to take the heat.

Answer 13

JACIL is an apparently dead project that attempts to do the reverse of IKVM. Perhaps some motivated folks could use it as a starting point for a viable .Net to JVM compiler.

Answer 14

http://jsc.sourceforge.net/ is a c# cross compiler that can convert .NET code to Java (amongst other things).

Answer 15

I guess the better question is why don't you write a C# to Java byte code compiler, if you want one to exist. Waiting for corporate overlords to do something is a bad idea.

A suggestion for creating such an implementation: take Mono's or .GNU's C# front end. Don't bother writing your own.

Answer 16

I wonder whether the Mono project could have made less work for themselves by targeting the JVM instead of developing and maintaining their own virtual machine from scratch. Development effort could have focused on a C# cross-compiler and porting clean-room implementations of the .NET libraries to the JVM. Sort of like an open-source version of what Mainsoft has done. You could then enable inter-language calls between Java and C# code in the same JVM, and deploy Applets and Java Web Start applications written in C#.