On Sep 12, 2014, at 3:40 AM, mutasim <d_muta...@hotmail.com> wrote: > the difference between Java and C# is the native code
That's...one way to think of it, certainly. That's also an oversimplification: before you even get to native code, your compiler needs to emit *something*, and that "something" needs to support your desired semantics. CIL and a set of custom attributes can support the necessary Java semantics, *except* for interface versioning. (At least, the last time I tried covariant return types in CIL it appeared to work... Java interfaces allow adding methods with impunity w/o invalidating existing compiled implementations. CIL doesn't permit that.) C#, on the other hand, does *not* support all Java semantics, nor can it easily be made to support them. (I've pondered a lot about how to sanely do covariant return types in C#. It's not easy.) Since your very premise consists of converting Java code into C# code, this requires that you get all of the semantic issues nailed down first, OR that you fork the C# language and add the missing Java-oriented semantics to C#. (This would be an interesting project, but it would no longer be C#.) > if the native code been programmed and add to the mono CLI that will handle > all the problems , i think , all the codes will return back to C or C++ and > then to the low level Mono, at present, consumes CIL. Consequently, you either need to emit CIL -- assuming CIL can represent your required semantics -- or you need to extend mono to consume some alternate serialization format that supports your desired semantics. As stated elsewhere in this thread, the easiest answer is to use IKVM to execute your Java bytecode atop Mono. IKVM handles the responsibility of properly representing Java bytecode semantics atop CIL. - Jon _______________________________________________ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
