I'd say this reads more like an ad than an explanation. The first paragraph is totally a sales pitch, then they invite you to use the product and constantly nag on about how awesome it is.
And anyway, marketing aside it's not really a good explanation at all. It's way too abstract to be of any practical use, completely obvious and revealing no information to someone who has made compilers, and completely opaque and, once again, revealing nothing to someone who hasn't.
That's a shame, really. If it works as advertised it would be a really interesting piece of tech. I don't want to know that it parses C# and then converts that tree to one for Java. How else would you do it? On the other hand, how exactly does the mapping from .NET classes to Java ones work? Does the converter also handle coding style and not just syntax and semantics? More importantly, how would you go about doing that?
Overall, I'm not terribly impressed with their transparency.
Library differences could probably just be handled with a support library. Microsoft used one to support its VB6 to VB.NET conversion engine, and it worked fairly well in my experience.
I wonder more about all the myriad C# language features that don't translate directly to Java. If their engine is limited to porting C# 2.0 code then a lot of that hassle probably goes away (though I'd still wonder about unsafe blocks), but that excludes most new code that's been written in the past 8 years. And I would be leery of trusting any automatic porting engine that claims to work with C# 4 but doesn't come with a very clear and detailed explanation of how it's going to handle something like extension methods or late binding.
And, for that matter, a clear explanation for why I should prefer automatic porting of a large project instead of just running it in Mono, using IPC to get it talking to my Java code, and calling it a day.
I don't see anything on this page that explains why you'd use this instead of say, IKVM.
Also, they claim their technology makes your app platform independent... How exactly? C# and Java are both compilable for basically every platform out there, so I don't see how a language translation would help. Do they map WinForms/WPF API calls to SWING or something?
What do they do about structs and pointers and generics?
Migrating from C# to java makes your app platform independent. C# is not platform indenpendent because it is never complete outside windows. The site is an ad without details, but I guess that the translation can not magically map WinForms to swing. Some manual work probably remains, but this kind of tools remains very usefull to reduce migration workload.
The bits of C# code that could be plausibly ported to Java (read: doesn't rely on a Windows-only library) are pretty darn complete outside of Windows. Mono is really a very solid project.
Winforms (through version 2.0) is supported by Mono. So in the case of that example, before taking on the immense hassle of trying to port my C#/Winforms app to Java/Swing, I'd take a good long hard look at just downgrading my C#/Winforms app from Winforms >2.0 back a version or two. For any non-trivial case you'd be looking at a fraction of the cost.
This is frustratingly vague. Obviously marketing and not real content. It doesn't even hint at how they resolve semantic differences between C# and Java.
How do they erase the generic types while preserving functionality? How do they correctly translate value types into reference types? These are IMPORTANT! Otherwise who knows what happens when you feed it this:
8 comments
[ 3.2 ms ] story [ 21.1 ms ] threadAnd anyway, marketing aside it's not really a good explanation at all. It's way too abstract to be of any practical use, completely obvious and revealing no information to someone who has made compilers, and completely opaque and, once again, revealing nothing to someone who hasn't.
That's a shame, really. If it works as advertised it would be a really interesting piece of tech. I don't want to know that it parses C# and then converts that tree to one for Java. How else would you do it? On the other hand, how exactly does the mapping from .NET classes to Java ones work? Does the converter also handle coding style and not just syntax and semantics? More importantly, how would you go about doing that?
Overall, I'm not terribly impressed with their transparency.
I wonder more about all the myriad C# language features that don't translate directly to Java. If their engine is limited to porting C# 2.0 code then a lot of that hassle probably goes away (though I'd still wonder about unsafe blocks), but that excludes most new code that's been written in the past 8 years. And I would be leery of trusting any automatic porting engine that claims to work with C# 4 but doesn't come with a very clear and detailed explanation of how it's going to handle something like extension methods or late binding.
And, for that matter, a clear explanation for why I should prefer automatic porting of a large project instead of just running it in Mono, using IPC to get it talking to my Java code, and calling it a day.
Also, they claim their technology makes your app platform independent... How exactly? C# and Java are both compilable for basically every platform out there, so I don't see how a language translation would help. Do they map WinForms/WPF API calls to SWING or something?
What do they do about structs and pointers and generics?
Winforms (through version 2.0) is supported by Mono. So in the case of that example, before taking on the immense hassle of trying to port my C#/Winforms app to Java/Swing, I'd take a good long hard look at just downgrading my C#/Winforms app from Winforms >2.0 back a version or two. For any non-trivial case you'd be looking at a fraction of the cost.
How do they erase the generic types while preserving functionality? How do they correctly translate value types into reference types? These are IMPORTANT! Otherwise who knows what happens when you feed it this: