ikvm-developers

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

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

Matthew Mastracci wrote:
> Jeroen Frijters wrote:
>=20
> > It works based on a map.xml file. I've a attached an=20
> > example bean and the xml file that describes the
> > bean. It would be nice to have a tool that uses
> > Introspector.getBeanInfo() (like I did in the main
> > method of MyBean) to interrogate all the classes in
> > a jar and then generate the xml file automatically.
>=20
> This is fantastic...  If this could support methods as well as=20
> properties, I might try to use this to .NETify the API of SWT without=20
> any code changes (binary only port), assuming that SWT=20
> doesn't use a lot of reflection internally.

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#.

Regards,
Jeroen

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

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.