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...

Solution 1

Firstly Sun has 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 portions 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.

Solution 2

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...

Solution 3

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

Solution 4

"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 (now OpenJDK) 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.

Solution 5

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

View more solutions

Comments

[Steven A. Lowe]

this is not a technical question, it's asking us to read the minds of Sun executives - my Kreskin program says they don't like C#, they like Java, and want the two to remain distinct, otherwise they cannot justify their existence

[Joe Erickson]

My #1 and #2 suggestions above go along with your Amazing insight. With the current Pres of Sun being a software guy, who knows, maybe we'll get an Amazing answer from the top?

[Joe Erickson]

Should Sun "embrace and extend" C# instead of pretending that it doesn't exist. I've been in the biz of developing software for other developers since before Gosling noticed his Oak tree and it seems to me that embracing C# would be a good thing - but maybe I drink too much of the Microsoft Koolaid?

[Craig van Wilson]

There was a project a while ago in Sun to run VB code on the JVM. They lost interest though - probably as a result of lack of developer interest. Sun have enough on their plate with all the Dynamic languages they are supporting: JRuby, JPython etc

[Brett]

You could just port it to Java and drop the minority platform.

[Joe Erickson]

Tom - I did the Java thing from 1996 until 2002. My official reason for leaving Actuate? Microsoft understood the need for basic things like enumerated types (since added to Java but it took way too long) and excellent Windows UI support and Actuate had no interest in building .NET products.

[Joe Erickson]

Fortyrunner - No doubt that Ruby, Python and such are hot these days. I've been too busy starting a company to play with a new language for a while so I haven't had time to play with the new Dynamic languages...maybe it takes an obsessed advocate inside of Sun for any of these to succeed.

[Dan Tao]

It may be a long shot, but have you looked into leveraging the Stab programming language? It basically IS C# for the JVM. Seems to me you could just about write some Java class wrappers, try to compile your code as Stab and almost get away with it? Of course I've never tried such a thing so I could be way off.

[Joe Erickson]

IMO Sun does not want to create Java programmers. They want developers writing software for their platform whether it's C or C++ or Java or Ruby or Python - but maybe not C#?

[Joe Erickson]

You and I disagree on technical feasibility. Mainsoft is a small ISV who manages to convert .NET assemblies to Java jar files. If a small ISV can do it - with no ability to change the JVM - certainly Sun can do it if they choose to.

[Randolpho]

I've only just realized that my last two paragraphs were probably off-topic. The original poster wants a compiler of C# to JVM bytecode, not an IL bytecode translator. I'll leave the post as is, but consider that part retracted. :)

[Randolpho]

And then I see replies. Heh. I see what you mean, but I don't think Sun has any real incentive, especially if an ISV has already done it for them.

[Joe Erickson]

Yes, Java is similar, but we would like to make our core engine available and we don't want to maintain C# and Java code bases. The reality is that we, and many other companies, have C# code bases today that would arguably be more likely to run on Java someday if there were a C# compiler.

[Randolpho]

I will look into mainsoft, however.

[Joe Erickson]

In my post I pointed out that we want to port our core engine and we could easily encapsulate the .NET APIs we use and use Java APIs on the Java platform. Having said that, we might be the exception and the lack of .NET libraries might make C# a dead end language just as you point out J# is.

[Randolpho]

It also looks like it's not really automatic; my first guess is that they do it manually. I'm listening to their integration webcast now.

[Tim]

I think if you want a Java version you are going to have to bite the bullet and port to Java. I doubt there will ever be a high quality C# compiler for the JVM. Without a good compiler there is not point even thinking about it. Sorry.

[Joe Erickson]

Unfortunately, the people who ask us for a Java version of our engine are not interested in a Mono solution - if they were we would not be thinking of going to all the trouble of doing a Java version.

[Randolpho]

Wait... C# is a dead-end language? Now that's a riot!

[Joe Erickson]

If we had to start today we'd definitely do it in Java. I am afraid your are correct that we are unlikely to ever get a high quality C# compiler for the JVM.

[Joe Erickson]

Randolpho - oops, guess I wasn't too clear - how about "the lack of .NET libraries for the JVM might make a C# to JVM compiler a dead end project."

[Randolpho]

Ok, that I agree with. The APIs are very incompatible.

[Joe Erickson]

Since C# code must assume that any method can throw any exception, the compiler could simply emit byte code which indicates that function F() throws any checked exceptions thrown by methods called by F() (hmmm...I remember doing a lot of essentially this same thing by hand back in the day).

[Joe Erickson]

As for delegates, the proper way to do it would be to extend the JVM. It could be done without extensions but it (emitted byte code) probably wouldn't be pretty or efficient.

[Joe Erickson]

Unfortunately, our potential customers are Java developers who want something which works in their current Java environment - whether it's a web server, application server, Applet, Java GUI app or whatever.

[Joe Erickson]

I've seen it - but it's not what we need. Unfortunately, our potential customers are Java developers who want something which works in their current Java environment - whether it's a web server, application server, Applet, Java GUI app or whatever

[Joe Erickson]

This is a good suggestion which we will certainly do eventually (we've already been playing with Windows Azure with this in mind). However, this is not a solution for many of our potential customers for performance (we have customers with 500MB workbooks) and / or security reasons.

[Matthew Flaschen]

IKVM has a runtime dependency on CLI, which Joe already said he doesn't want. See my post for the gory details.

[Joe Erickson]

Agreed - as it stands today a port and ongoing maintance of two code bases would seem to be our best option. We have plenty of opportunities on the .NET side which allow us to leverage our C# engine, so this where we will invest our time.

[Rad]

Well, unfortunately there never is a free lunch. There's nothing in it for Microsoft to build a compiler to Java and Sun for sure won't do it. A compromise must be made somewhere to solve this particular problem.

[Robert C. Barth]

Actually Sun DOES have incentive to make C# run on Java. Sun makes their money off HARDWARE, not software. If C# stuff ran on the JVM, possibly they'd sell more Sun SPARCstations to run that C# on JVM code.

[Robert C. Barth]

Now, MICROSOFT has no incentive to do this as they DO make money off software (quite a bit, too). Hardware companies try to commoditize the software, software companies try to commoditize the hardware.

[Tim]

They might as well offically support mono on solaris than port C# and the .NET BCL to the JVM. If Sun were to implement the ECMA 334/335 standards your apps sill would not run as they use parts which are not part of that standard. Those other parts require MS licensing, I doubt that would happen.

[Joe Erickson]

If you read the original post, you will see that I refer to Mainsoft and the reason why it's a nonstarter for us.

[Johnny]

so you do... sorry. Anyway it would be of interest to others.

[Chase Seibert]

Their incentive would be to try and kill Java. Offering backwards compatibility with the competition was how they killed Netwear, remember.

[Randolpho]

@Robert: I agree with Tim; Mono on Solaris is the best way to allow C# on a Sun platform.

[Tjkoopa]

IIRC the JVM is in effect a CPU so what would be needed would be not a JVM based CLI VM but a CLI JIT that targets the JVM (more or less)

[dmeister]

That is no problem. Checked exceptions are a property of the Java language, not of the JVM. Other JVM languages havn't checked exceptions.

[gbjbaanb]

note that WCF doesn't do 'interoperable' tcpip: it only supports "optimised" connections to other WCF services, so it'll be just as bad for performance as a webservice. Maybe they'll change this in the future, but until then roll your own. (or use gsoap and a c++/cli wrapper)

[tuinstoel]

Check out whether you can MTOM from Java to WCF? If it possible I would build a WCF service. I would never build an asmx web service, asmx is obsolete.

[Todd Stout]

+1 Interesting! Have you used this for transformation of non-trivial/production code?

[Joe Erickson]

We will not do a C# to Java byte code compiler because we have many years worth of work to do while staying focused on what we do best - which is spreadsheet technology.

[Joe Erickson]

I run my own for profit company so I do understand the need to make a profit. It seems to me that Sun is (was if the Oracle deal closes) interested in having as much software as possible run on their JVM and therefore on their hardware. Making it easier to get C# code running on the JVM would arguably make more software available.

[redcalx]

BTW IKVM no longer uses GNU Classpath. It switched to Open JDK some time ago.

[Mikhaël Bois]

This is how i would do it, I would use WCF (BasicHttp Binding) over port 80 (WebService). I have made a call from just the Http get from this.

[Joe Erickson]

That's a great question. Of course, it's too late now. I wonder if they considered it. I'm guessing that performance would be a big issue - no value types for example.

[Justin]

It is just not technically possible at this point to implement the C# spec on the JVM. C# supports pointers, unsigned types, user defined value types, true generics, passing by reference, and loads of other things. For a very C#-like JVM language, check out Stab: code.google.com/p/stab-language

[Behrooz]

It costs $5,000 per CPU on Tomcat and $15,000 per CPU on WebSphere Application Server, plus $6,000 per developer seat.... $11000 ^#$(@^$@&$$@%# NO THANK YOU.