Missing method from DLL

63 views
Skip to first unread message

vince

unread,
Feb 3, 2012, 4:47:33 AM2/3/12
to jni4net
Hello,

I'm using jni4net to be able to make calls from Java code to .Net (C#)
DLL.

When I use proxygen, it generates Java classes, but these classes seem
to be missing method or type information.
Before trying jni4net, I used another commercial application to
generate the proxies etc, and it did generate those things that are
missing from the jni4net generation.

I have tried to use a xml configuration file to force generation of
the missing methods, but to no avail (it's kinda hard without a
documentation, so I tried based on
http://code.google.com/p/jni4net/source/browse/trunk/tools/proxygen/jni4net.proxygen.xml?r=258
and http://jni4net.googlecode.com/svn/trunk/jni4net.proxygen/src/config/toolConfig.xsd).

So, I know for sure that the methods in question exist and can
technically be extracted from the source DLL, but it seems that
jni4net can't see them; all I have in the generated file is a
constructor and some glue code methods.

I tried to make proxygen verbose, but the output does not help at all
(it would be nice if it could at least display what it finds in the
source dll).

In the xml config file, I did like this:
<ClrType TypeName="NameSpace.B">
<MethodModifier MethodName="Get_string" Signature="()LSystem/String;"
Return="java.lang.String" Force="true" RenameJVM="getString"/>
</ClrType>

I'm not too sure it's correct; the method in question (in C#) receives
no argument and returns a string.

Do you have any idea, pointers, things to try, etc. that would allow
me to go a little further?

Thanks.

Pavel Šavara

unread,
Feb 3, 2012, 5:10:27 AM2/3/12
to jni...@googlegroups.com
> I have tried to use a xml configuration file to force generation of
> the missing methods,
'Force' attribute is not reliable guy and will go away in next release.

> jni4net can't see them; all I have in the generated file is a

Yes, there are limitations in current version.

> I tried to make proxygen verbose, but the output does not help at all
> (it would be nice if it could at least display what it finds in the
> source dll).

There is source code of proxygen avalable. Add the messages yourself for now.


> In the xml config file, I did like this:
>  <ClrType TypeName="NameSpace.B">
>        <MethodModifier MethodName="Get_string" Signature="()LSystem/String;"
> Return="java.lang.String" Force="true" RenameJVM="getString"/>
>  </ClrType>

I'm not sure what's wrong with the method, if it really that simple signature ?
Is it virtual ? Did you generated base class as well ?


For now, you could edit the generated files and add methods by hands.
For C# part you could even use partial classes.
For java file put your code outside //<generated-proxy> it will be
retained by proxygen.

Pavel

vince

unread,
Feb 7, 2012, 3:12:54 AM2/7/12
to jni4net
Hello,

Just a follow up: it turns out that the methods were indeed not
present in the original C# code of the dll - there are public fields.
I guess the commercial product I had used earlier was creating getter/
setters automatically...

I don't know if you think it's a good idea to generate such setters/
getters; in an case, it would be nice to have a way to access them
from Java, be it as public fields or generated getters. I have
performed a check-out of the trunk sources (0.8.6.0), I can contribute
to it if you wish although I won't have time to do so immediately. I
should probably wait until you release 0.9 anyway since you apparently
rewrote everything :)

Thanks for you reply anyway!
Vincent

Pavel Šavara

unread,
Feb 7, 2012, 4:07:37 AM2/7/12
to jni...@googlegroups.com
Yes, public fields should be in 0.9.

> --
> You received this message because you are subscribed to jni...@googlegroups.com
> http://groups.google.com/group/jni4net?hl=en-GB?hl=en-GB
> http://jni4net.sf.net/

Reply all
Reply to author
Forward
0 new messages