JNI generic type of jobject

Hello,

I use JNI calls for some Java classes. Some Java classes are generic
classes like:

class mytestclass<T> {

public native void mymethod();

}

The stub shows:

JNIEXPORT void JNICALL Java_mytestclass_mymethod(JNIEnv* p_env, jobject
p_object)

How can I get from the jobject which object type is the generic
parameter T? Because I would
like to create different codes if I do something like:

mytestclass<int> x = new mytestclass<int>();
x.mymethod();

mytestclass<String> x = new mytestclass<String>();
x.mymethod();

Thanks

Phil

On 10/04/2011 02:23 PM, Philipp Kraus wrote:
> Hello,
>
> I use JNI calls for some Java classes. Some Java classes are generic
> classes like:
>
> class mytestclass<T> {
>
> public native void mymethod();
>
> }
>
> The stub shows:
>
> JNIEXPORT void JNICALL Java_mytestclass_mymethod(JNIEnv* p_env, jobject
> p_object)
>
> How can I get from the jobject which object type is the generic
> parameter T? Because I would
> like to create different codes if I do something like:
>
> mytestclass<int> x = new mytestclass<int>();
> x.mymethod();
>
> mytestclass<String> x = new mytestclass<String>();
> x.mymethod();
>
> Thanks
>
> Phil
>
>

No such thing is possible. Generics are a compile time thing. At runtime
only the raw types are available.

Silvio

On 2011-10-04 14:28:14 +0200, Silvio said:

> On 10/04/2011 02:23 PM, Philipp Kraus wrote:
>> Hello,
>>
>> I use JNI calls for some Java classes. Some Java classes are generic
>> classes like:
>>
>> class mytestclass<T> {
>>
>> public native void mymethod();
>>
>> }
>>
>> The stub shows:
>>
>> JNIEXPORT void JNICALL Java_mytestclass_mymethod(JNIEnv* p_env, jobject
>> p_object)
>>
>> How can I get from the jobject which object type is the generic
>> parameter T? Because I would
>> like to create different codes if I do something like:
>>
>> mytestclass<int> x = new mytestclass<int>();
>> x.mymethod();
>>
>> mytestclass<String> x = new mytestclass<String>();
>> x.mymethod();
>>
>> Thanks
>>
>> Phil
>>
>>
>
> No such thing is possible. Generics are a compile time thing. At
> runtime only the raw types are available.

Why? jobject is a pointer to the Java object that calls the JNI
function, JNIEnv is also a pointer to the running
environment, so I should get the type of the generic parameter, because
the runtime / object knows them
so within the JNI call the parameter must exists.

I can also run in the Java class T.getClass().getName() and the Java
code returns the name of the type
the JNI call should do the same like JNIEnv->GetObjectClass(
jobject.getTemplateVar(0) ) but I need
the name / call of the "getTemplateVar(int)" function which gets an
object to the first template parameter
of the Java object

Thanks

Phil

On 10/4/11 5:28 AM, Silvio wrote:
> On 10/04/2011 02:23 PM, Philipp Kraus wrote:
>> Hello,
>>
>> I use JNI calls for some Java classes. Some Java classes are generic
>> classes like:
>>
>> class mytestclass<T> {
>>
>> public native void mymethod();
>>
>> }
>>
>> The stub shows:
>>
>> JNIEXPORT void JNICALL Java_mytestclass_mymethod(JNIEnv* p_env, jobject
>> p_object)
>>
>> How can I get from the jobject which object type is the generic
>> parameter T? Because I would
>> like to create different codes if I do something like:
>>
>> mytestclass<int> x = new mytestclass<int>();
>> x.mymethod();
>>
>> mytestclass<String> x = new mytestclass<String>();
>> x.mymethod();
>>
>> Thanks
>>
>> Phil
>>
>>
>
> No such thing is possible. Generics are a compile time thing. At runtime
> only the raw types are available.
>
> Silvio

int is not a valid generic type parameter, as int is a primitive and
generic types must by Object types.

Also, generics are not the same as C++ templates. There isn't different
code created for each concrete usage. Its all exactly the same code.

If you are doing different behavior based on the compile time type, then
you need to do a little bit more work to implement the strategy pattern.

class MyTestClass<T> {
private MyMethodStrategy<T> strategy;

public mymethod() {
strategy.mymethod(this);
}
}

interface MyMethodStrategy<T> {
void mymethod(MyTestClass<T> testClass);
}


class MyStringMethodStrategy implement MyMethodStrategy<String> {
public native void mymethod(MyTestClass<String> testClass);
}


class MyIntegerMethodStrategy implement MyMethodStrategy<Integer> {
public native void mymethod(MyTestClass<Integer> testClass);
}


Then you will have two different native methods to implement each strategy.

On 2011-10-04 16:53:22 +0200, Daniel Pitts said:

> On 10/4/11 5:28 AM, Silvio wrote:
>> On 10/04/2011 02:23 PM, Philipp Kraus wrote:
>>> Hello,
>>>
>>> I use JNI calls for some Java classes. Some Java classes are generic
>>> classes like:
>>>
>>> class mytestclass<T> {
>>>
>>> public native void mymethod();
>>>
>>> }
>>>
>>> The stub shows:
>>>
>>> JNIEXPORT void JNICALL Java_mytestclass_mymethod(JNIEnv* p_env, jobject
>>> p_object)
>>>
>>> How can I get from the jobject which object type is the generic
>>> parameter T? Because I would
>>> like to create different codes if I do something like:
>>>
>>> mytestclass<int> x = new mytestclass<int>();
>>> x.mymethod();
>>>
>>> mytestclass<String> x = new mytestclass<String>();
>>> x.mymethod();
>>>
>>> Thanks
>>>
>>> Phil
>>>
>>>
>>
>> No such thing is possible. Generics are a compile time thing. At runtime
>> only the raw types are available.
>>
>> Silvio
>
> int is not a valid generic type parameter, as int is a primitive and
> generic types must by Object types.
>
> Also, generics are not the same as C++ templates. There isn't
> different code created for each concrete usage. Its all exactly the
> same code.
>
> If you are doing different behavior based on the compile time type,
> then you need to do a little bit more work to implement the strategy
> pattern.
>
> class MyTestClass<T> {
> private MyMethodStrategy<T> strategy;
>
> public mymethod() {
> strategy.mymethod(this);
> }
> }
>
> interface MyMethodStrategy<T> {
> void mymethod(MyTestClass<T> testClass);
> }
>
>
> class MyStringMethodStrategy implement MyMethodStrategy<String> {
> public native void mymethod(MyTestClass<String> testClass);
> }
>
>
> class MyIntegerMethodStrategy implement MyMethodStrategy<Integer> {
> public native void mymethod(MyTestClass<Integer> testClass);
> }
>
>
> Then you will have two different native methods to implement each strategy.

This a very good solution, I implement my own pattern
Thanks

Daniel Pitts wrote:
>> Philipp Kraus wrote:
>>> I use JNI calls for some Java classes. Some Java classes are generic
>>> classes like:
>>>
>>> class mytestclass<T> {
>>>
>>> public native void mymethod();
>>>
>>> }
>>>
>>> The stub shows:
>>>
>>> JNIEXPORT void JNICALL Java_mytestclass_mymethod(JNIEnv* p_env, jobject
>>> p_object)
>>>
>>> How can I get from the jobject which object type is the generic
>>> parameter T? Because I would
>>> like to create different codes if I do something like:
>>>
>>> mytestclass<int> x = new mytestclass<int>();
>>> x.mymethod();
>>>
>>> mytestclass<String> x = new mytestclass<String>();
>>> x.mymethod();
>>
> int is not a valid generic type parameter, as int is a primitive and
> generic types must be Object types.
>
> Also, generics are not the same as C++ templates. There isn't different
> code created for each concrete usage. Its all exactly the same code.
>
> If you are doing different behavior based on the compile time type, then
> you need to do a little bit more work to implement the strategy pattern.
>
> class MyTestClass<T> {
> private MyMethodStrategy<T> strategy;
>
> public mymethod() {
> strategy.mymethod(this);
> }
> }
>
> interface MyMethodStrategy<T> {
> void mymethod(MyTestClass<T> testClass);
> }
>
>
> class MyStringMethodStrategy implement MyMethodStrategy<String> {
> public native void mymethod(MyTestClass<String> testClass);
> }
>
>
> class MyIntegerMethodStrategy implement MyMethodStrategy<Integer> {
> public native void mymethod(MyTestClass<Integer> testClass);
> }
>
>
> Then you will have two different native methods to implement each strategy.

Kudos for a great answer!
+1

This pattern or ones like it are frequent and very helpful in generics programming.

--
Lew

On 10/4/11 12:01 PM, Lew wrote:
> Daniel Pitts wrote:
>>> Philipp Kraus wrote:
>>>> I use JNI calls for some Java classes. Some Java classes are generic
>>>> classes like:
>>>>
>>>> class mytestclass<T> {
>>>>
>>>> public native void mymethod();
>>>>
>>>> }
>>>>
>>>> The stub shows:
>>>>
>>>> JNIEXPORT void JNICALL Java_mytestclass_mymethod(JNIEnv* p_env, jobject
>>>> p_object)
>>>>
>>>> How can I get from the jobject which object type is the generic
>>>> parameter T? Because I would
>>>> like to create different codes if I do something like:
>>>>
>>>> mytestclass<int> x = new mytestclass<int>();
>>>> x.mymethod();
>>>>
>>>> mytestclass<String> x = new mytestclass<String>();
>>>> x.mymethod();
>>>
>> int is not a valid generic type parameter, as int is a primitive and
>> generic types must be Object types.
>>
>> Also, generics are not the same as C++ templates. There isn't different
>> code created for each concrete usage. Its all exactly the same code.
>>
>> If you are doing different behavior based on the compile time type, then
>> you need to do a little bit more work to implement the strategy pattern.
>>
>> class MyTestClass<T> {
>> private MyMethodStrategy<T> strategy;
>>
>> public mymethod() {
>> strategy.mymethod(this);
>> }
>> }
>>
>> interface MyMethodStrategy<T> {
>> void mymethod(MyTestClass<T> testClass);
>> }
>>
>>
>> class MyStringMethodStrategy implement MyMethodStrategy<String> {
>> public native void mymethod(MyTestClass<String> testClass);
>> }
>>
>>
>> class MyIntegerMethodStrategy implement MyMethodStrategy<Integer> {
>> public native void mymethod(MyTestClass<Integer> testClass);
>> }
>>
>>
>> Then you will have two different native methods to implement each strategy.
>
> Kudos for a great answer!
> +1
>
> This pattern or ones like it are frequent and very helpful in generics programming.
>
They also provide greater flexibility for pluggable (user-defined)
behavior. When applicable, I often replace protected methods with
strategy interfaces. Especially if any two protected methods are
independent of one another in the same class. Truth be told, I usually
don't create protected methods at all any more, unless they are in some
sort of adapter class for a "un-handled use-case" or some such.