4 ms·

Switching from C# to Java

31 points by amitshah 16y ago

bruceboughton 16y ago
I can understand porting C# code to Java code, but what I don't understand and what the article doesn't explain is how they handled their dependencies, i.e. System.* libraries. They clearly didn't port the CLR libraries to the JVM, so they must have modified their code to work with Java libraries, e.g. Swing, etc. To me, it seems like this would be the bulk of the work, not language translation from Java to C#.
- ivenkys 16y ago
  Good point - its not the language translation per-se but the ecosystem surrounding it unless there's is one of those projects where they hand-coded everything and used no external libraries at all. I doubt it very much though.
Tichy 16y ago
How does the converted code look, though? Is it viable to continue working on that, rather than fixing the original C# code? (Ie comments would be carried over in the conversion).
- AndrewDucker 16y ago
  That would be my question. In my experience code that's been transformed programmatically is not meant for the eyes of mortal man.
tzs 16y ago
It sounds like they rejected Grasshopper, the .NET to Java converter that works at the bytecode level, without doing a test to see if it would have worked, on the grounds that they wanted to be open source. They probably should have given it a try, because if it had worked, it would have opened up a possibility that they seem to have completely overlooked. Use Grasshopper to convert at the bytecode level, then use a Java decompiler to go from bytecode to Java source. You'd lose comments in the source code that way, but I bet it would not be hard to write a tool to transfer the function level comments from the C# source to the Java source. Subsequent hand editing to translate any C#-isms to Java-isms in the comments, and restore any crucial sub-function level comments, would probably have only taken a few days.
plesn 16y ago
I wonder why they couldn't use Mono. I can't really grok how they managed library usage, and how difficult it will be to maintain the java one when on platform updates etc.
CWuestefeld 16y ago
As with many HN articles, the headline is misleading. Really, the language switch is a symptom, and not the driver of the decision. From the article, their requirements included: one of the first tasks we got was to make the management application cross platform, well this was expected considering the fact that the acquisition was done by RedHat. And: Sticking with C# requires technologies to help us run it on Linux. We found Mono ..., and the second option we found was Grasshopper which is a project of Mainsoft to compile MSIL to Java Bytecode. ... These 2 solutions were taken off the table ... we wanted to use a technology supported by Red Hat. So it appears to me that the decision had nothing at all to do with technical strengths of the language. Moreover, it had nothing to do with the platform as such -- whether its technical strengths or any end-user demographics -- but purely politics driven by Red Hat.
- rwmj 16y ago
  No, they tried Mono and found it wasn't ready for primetime. Read the article.
rit 16y ago
Totally reactionary, prejudiced statement. But my first reaction on headline before reading the article was "Ugh. I'm sorry". (I will read it in a second, I felt this obdurate urge to rant BEFORE I read it). I coded in Java for work (After being hired to do Java) for years, then went over to Python, and worked with some C# for about a year. Now I'm back working with Java, and Scala (for which I have lots of love - it has a lot of what I love about Python but in many cases better). There are little things in C# that just really give it an edge over Java. Among other things relating to Generics (Which are awful to begin with in that the JVM currently erases type information at compile time [Scala has a few clever hacks to get around it]) - as I understand it, C#/CLR automatically generates multiple specialized paths for all possible primitive types with generic collections. And being a fan of closures, anonymous functions, etc. Java is just painful. C# has these, and more. Now Off to read the article :)
- Kototama 16y ago
  The decision taken in the article is clear : it's not so a matter of language but a matter of platforms. The JVM has a lot to offer in this way.
- brazzy 16y ago
  I keep seeing people bash Java's Generics because of type erasure - but what exactly is so awful about it? All the questions on stackoverflow where the answer is "impossible because of type erasure, or use this workaround" don't seem to be about terribly important or useful things.
  - fauigerzigerk 16y ago
    The most horrible thing about it is that all primitives have to be boxed using huge amounts of memory. And there are lots of other bad consequences like not being able to call a constructor for a type parameter. But Java's horrible generics implementation is only my second most pressing problem. The first being the lack of structured value types (i.e struct in C#). I am rewriting a C# app in Java right now and I'm being forced into extremely awful hacks to prevent memory consumption from exploding. To illustrate how bad the situation is let me tell you that I'm seriously thinking about rewriting everything in C++ :-)

31 points by amitshah 16y ago

I can understand porting C# code to Java code, but what I don't understand and what the article doesn't explain is how they handled their dependencies, i.e. System.* libraries. They clearly didn't port the CLR libraries to the JVM, so they must have modified their code to work with Java libraries, e.g. Swing, etc. To me, it seems like this would be the bulk of the work, not language translation from Java to C#.

ivenkys 16y ago
Good point - its not the language translation per-se but the ecosystem surrounding it unless there's is one of those projects where they hand-coded everything and used no external libraries at all. I doubt it very much though.

Tichy 16y ago

How does the converted code look, though? Is it viable to continue working on that, rather than fixing the original C# code? (Ie comments would be carried over in the conversion).

AndrewDucker 16y ago
That would be my question. In my experience code that's been transformed programmatically is not meant for the eyes of mortal man.

tzs 16y ago

It sounds like they rejected Grasshopper, the .NET to Java converter that works at the bytecode level, without doing a test to see if it would have worked, on the grounds that they wanted to be open source. They probably should have given it a try, because if it had worked, it would have opened up a possibility that they seem to have completely overlooked. Use Grasshopper to convert at the bytecode level, then use a Java decompiler to go from bytecode to Java source. You'd lose comments in the source code that way, but I bet it would not be hard to write a tool to transfer the function level comments from the C# source to the Java source. Subsequent hand editing to translate any C#-isms to Java-isms in the comments, and restore any crucial sub-function level comments, would probably have only taken a few days.

plesn 16y ago

I wonder why they couldn't use Mono. I can't really grok how they managed library usage, and how difficult it will be to maintain the java one when on platform updates etc.

CWuestefeld 16y ago

As with many HN articles, the headline is misleading. Really, the language switch is a symptom, and not the driver of the decision. From the article, their requirements included: one of the first tasks we got was to make the management application cross platform, well this was expected considering the fact that the acquisition was done by RedHat. And: Sticking with C# requires technologies to help us run it on Linux. We found Mono ..., and the second option we found was Grasshopper which is a project of Mainsoft to compile MSIL to Java Bytecode. ... These 2 solutions were taken off the table ... we wanted to use a technology supported by Red Hat. So it appears to me that the decision had nothing at all to do with technical strengths of the language. Moreover, it had nothing to do with the platform as such -- whether its technical strengths or any end-user demographics -- but purely politics driven by Red Hat.

rwmj 16y ago
No, they tried Mono and found it wasn't ready for primetime. Read the article.

rit 16y ago

Totally reactionary, prejudiced statement. But my first reaction on headline before reading the article was "Ugh. I'm sorry". (I will read it in a second, I felt this obdurate urge to rant BEFORE I read it). I coded in Java for work (After being hired to do Java) for years, then went over to Python, and worked with some C# for about a year. Now I'm back working with Java, and Scala (for which I have lots of love - it has a lot of what I love about Python but in many cases better). There are little things in C# that just really give it an edge over Java. Among other things relating to Generics (Which are awful to begin with in that the JVM currently erases type information at compile time [Scala has a few clever hacks to get around it]) - as I understand it, C#/CLR automatically generates multiple specialized paths for all possible primitive types with generic collections. And being a fan of closures, anonymous functions, etc. Java is just painful. C# has these, and more. Now Off to read the article :)

Kototama 16y ago
The decision taken in the article is clear : it's not so a matter of language but a matter of platforms. The JVM has a lot to offer in this way.
brazzy 16y ago
I keep seeing people bash Java's Generics because of type erasure - but what exactly is so awful about it? All the questions on stackoverflow where the answer is "impossible because of type erasure, or use this workaround" don't seem to be about terribly important or useful things.
- fauigerzigerk 16y ago
  The most horrible thing about it is that all primitives have to be boxed using huge amounts of memory. And there are lots of other bad consequences like not being able to call a constructor for a type parameter. But Java's horrible generics implementation is only my second most pressing problem. The first being the lack of structured value types (i.e struct in C#). I am rewriting a C# app in Java right now and I'm being forced into extremely awful hacks to prevent memory consumption from exploding. To illustrate how bad the situation is let me tell you that I'm seriously thinking about rewriting everything in C++ :-)