Re: [Ikvm-developers] Re: Converting JavaBeans into .Net classes

[Matthew M. <ma...@ac...>]

Jeroen Frijters wrote:

>The map.xml doesn't (and won't) support modifying methods in this way,
>but even if it did it would be an incredibly painful way of
>accomplishing this. You're much better of "simply" wrapping the API in
>C#.
>  
>
I wasn't considering hand-generating the map, but rather using 
reflection to generate an appropriate map based on a set of rules 
(pascal-casing, combine properties, create property getters for boolean 
is*() methods, etc.).  It's effectively equivalent to generating C# 
stubs via codegen (or the like), but saves the extra function call from 
the wrapper to the native Java class.

I imagine that even a sealed, concrete C# class with non-virtual methods 
would have a small overhead in calling, though in most cases this would 
likely negligible (small functions would likely be inlined anyways).  
For a "vanity" coding problem like correcting coding styles, this 
performance hit seems like a bit of a waste.

I can see that this is pushing the limits of IKVM's mission and probably 
doesn't fit in with the rest of IKVM's functionality - it's probably a 
good target for another, separate open source project.  I'm always 
impressed by the vast array of open-source Java applications that are 
available.  Having a way of porting them and making them more available 
to .NET developers might help developers to choose an IKVM'd version of 
the Java DLL, rather than resorting to a Java to .NET port and diluting 
the resources available to enhance the original project.

Thanks,
Matt.