JNI RegisterNatives from java side

[Ali]

I am looking for an equivalent of RegisterNatives method in JNI which
can be used in java and not C.

Going a bit deeper, there is this JNI dll which has a standard java
format for its methods (Java_packageName_className) and for several
reasons I have to map the methods to some java classes in another
package and with different names.

A quick solution would be using RegisterNatives in the JNI dll and
manually specifying the class, however, one rule of the game is to not
touch the jni dll source code.

Now I wonder if there is any equivalent of RegisterNatives which can
be used in the java files. Any decent examples are well appreciated.

 

[Gordon Beaton]

I am looking for an equivalent of RegisterNatives method in JNI which
can be used in java and not C.

Going a bit deeper, there is this JNI dll which has a standard java
format for its methods (Java_packageName_className) and for several
reasons I have to map the methods to some java classes in another
package and with different names.

A quick solution would be using RegisterNatives in the JNI dll and
manually specifying the class, however, one rule of the game is to
not touch the jni dll source code.

Now I wonder if there is any equivalent of RegisterNatives which can
be used in the java files. Any decent examples are well appreciated.

I know of no way to do the equivalent of RegisterNatives from Java,
however if the new class is a subclass of the original, it will
inherit the existing methods.

Or you could use compostion, and invoke the original native methods
from similarly named methods in your new class. That's not much more
work per method than declaring it as a native method would have been.

Finally , you could write a new DLL that properly "belongs" to the new
class but is dependent on the original DLL. From its JNI_Onload,
invoke RegisterNatives.

/gordon

 

[Gordon Beaton]

Or you could use compostion,

I seem to have spelled "delegation" wrong here...

/gordon

 

[saveez]

Gordon,

I didn't quite get what you mean by delegation here.

Assume we have this method in the dll:

Java_somePackage_SomeClass_someMethod

and this method in the java side:

anotherPackage.AnotherClass.anotherMethod

Now, what's the event? who's the listener? Could you provide a minimum
example.

 

[Gordon Beaton]

Assume we have this method in the dll:

Java_somePackage_SomeClass_someMethod

and this method in the java side:

anotherPackage.AnotherClass.anotherMethod

Now, what's the event? who's the listener? Could you provide a
minimum example.

If your DLL contains that method, the corresponding class looks
something like this (for the sake of the example I've also added a
static method and some arguments):

public class SomeClass {
public native void someMethod(int foo);
public static native void someStaticMethod(String gurka);
}

Keep an instance of SomeClass in your AnotherClass objects. Call its
methods when yours are called:

public class AnotherClass {
SomeClass sc = new SomeClass();

public native void anotherMethod(int bar) {
sc.someMethod(bar);
}

public static void anotherStaticMethod(String baz) {
Someclass.someStaticMethod(baz);
}
}

/gordon

 

[Gordon Beaton]

public native void anotherMethod(int bar) {
sc.someMethod(bar);
}

That should have been:

public void anotherMethod(int bar) {
sc.someMethod(bar);
}

(cut'n'paste error...)

/gordon

 

[saveez]

Thanks for the intuitive example Gordon. I understand you suggest to
use a proxy class to handle this problem.

Now, this question could be kind of irrelevant. Is there any way to
'hide' the proxy class inside the actual class? I am asking this as it
is important for this case to have both classes in *one* java
compilation unit, ie in the same file.

 

[Gordon Beaton]

Thanks for the intuitive example Gordon. I understand you suggest to
use a proxy class to handle this problem.

Now, this question could be kind of irrelevant. Is there any way to
'hide' the proxy class inside the actual class? I am asking this as it
is important for this case to have both classes in *one* java
compilation unit, ie in the same file.

You can include both classes in one source file, as long as only one
of them is public.

Note that you can't make the original class an inner class of the new
one, or its DLL will need to change.

/gordon