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

[Jeroen F. <je...@su...>]

Matthew Mastracci wrote:
> Jeroen Frijters wrote:
> >The map.xml doesn't (and won't) support modifying methods in=20
> >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#.
> > =20
> I wasn't considering hand-generating the map, but rather using=20
> reflection to generate an appropriate map based on a set of rules=20
> (pascal-casing, combine properties, create property getters=20
> 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.

OK, sorry I misunderstood you. I'm still a bit doubtful as to whether
that would be worthwhile, adding properties is one thing, but renaming
methods simply to following the .NET convention seems like an awful lot
of trouble.

> I imagine that even a sealed, concrete C# class with=20
> 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). =20
> For a "vanity" coding problem like correcting coding styles, this=20
> performance hit seems like a bit of a waste.

Yeah, but on the other hand, if you (manually) build the C# wrappers you
can also implement more complicated .NET specific coding styles/idioms
(e.g. IEnumerable, IDispose).

> I can see that this is pushing the limits of IKVM's mission=20
> 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=20
> the resources available to enhance the original project.

I absolutely agree that it would be very nice to have some tools
complementary to IKVM to make the experience of using Java libraries
from .NET better.

Regards,
Jeroen