[IvoDankolov]

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.

[bunderbunder]

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.