JNI and static methods

[alansam]

I've just discovered a strange restriction in NetRexx that prevents creating JNI interfaces as static methods.

In Java the following is an acceptable construct:

private static native String jniFunc(String s);

but in NetRexx the following definition (a transliteration of above):

method jniFunc(s = String) private native static returns String

generates a compilation error.

$ nrc -keepasjava -savelog RJNIDemo

NetRexx portable processor, version NetRexx 3.01, build 40-20120823-0156

Copyright (c) RexxLA, 2011,2012.  All rights reserved.

Parts Copyright (c) IBM Corporation, 1995,2008.

Program RJNIDemo.nrx

  11 +++ method jniFunc(s = String) private native static returns String

     +++                                           ^^^^^^

     +++ Error: Only one modifier keyword is allowed ('native' has already been used)

Compilation of 'RJNIDemo.nrx' failed [one error]

The doc. does indeed confirm that native and static are mutually exclusive but I'm not convinced that it's a reasonable restriction.  In the real world it's not unreasonable (and probably more realistic) for JNI functions to be static than bound to an instance of an object.

Has anyone else come across this restriction and if so are there any simple work-rounds?

Regards,
Alan.

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[George Hovey-2]

Can you 'fudge' it by modifying the generated Java source?  Unlovely, of course.

On Sat, Sep 1, 2012 at 3:44 PM, Alan Sampson <[hidden email]> wrote:

I've just discovered a strange restriction in NetRexx that prevents creating JNI interfaces as static methods.

In Java the following is an acceptable construct:

private static native String jniFunc(String s);

but in NetRexx the following definition (a transliteration of above):

method jniFunc(s = String) private native static returns String

generates a compilation error.

$ nrc -keepasjava -savelog RJNIDemo

NetRexx portable processor, version NetRexx 3.01, build 40-20120823-0156

Copyright (c) RexxLA, 2011,2012.  All rights reserved.

Parts Copyright (c) IBM Corporation, 1995,2008.

Program RJNIDemo.nrx

  11 +++ method jniFunc(s = String) private native static returns String

     +++                                           ^^^^^^

     +++ Error: Only one modifier keyword is allowed ('native' has already been used)

Compilation of 'RJNIDemo.nrx' failed [one error]

The doc. does indeed confirm that native and static are mutually exclusive but I'm not convinced that it's a reasonable restriction.  In the real world it's not unreasonable (and probably more realistic) for JNI functions to be static than bound to an instance of an object.

Has anyone else come across this restriction and if so are there any simple work-rounds?

Regards,
Alan.

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

--
"One can live magnificently in this world if one knows how to work and how to love."  --  Leo Tolstoy

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

Worth checking the generated code in any case .. I may have assumed and made all native methods static (but I would have thought I would have documented that, if so).

 

Mike

---

From: [hidden email] [mailto:[hidden email]] On Behalf Of George Hovey
Sent: 02 September 2012 02:09
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] JNI and static methods

Can you 'fudge' it by modifying the generated Java source?  Unlovely, of course.

On Sat, Sep 1, 2012 at 3:44 PM, Alan Sampson <[hidden email]> wrote:

I've just discovered a strange restriction in NetRexx that prevents creating JNI interfaces as static methods.

In Java the following is an acceptable construct:

private static native String jniFunc(String s);

but in NetRexx the following definition (a transliteration of above):

method jniFunc(s = String) private native static returns String

generates a compilation error.

$ nrc -keepasjava -savelog RJNIDemo

NetRexx portable processor, version NetRexx 3.01, build 40-20120823-0156

Copyright (c) RexxLA, 2011,2012.  All rights reserved.

Parts Copyright (c) IBM Corporation, 1995,2008.

Program RJNIDemo.nrx

  11 +++ method jniFunc(s = String) private native static returns String

     +++                                           ^^^^^^

     +++ Error: Only one modifier keyword is allowed ('native' has already been used)

Compilation of 'RJNIDemo.nrx' failed [one error]

The doc. does indeed confirm that native and static are mutually exclusive but I'm not convinced that it's a reasonable restriction.  In the real world it's not unreasonable (and probably more realistic) for JNI functions to be static than bound to an instance of an object.

Has anyone else come across this restriction and if so are there any simple work-rounds?

Regards,
Alan.

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

--
"One can live magnificently in this world if one knows how to work and how to love."  --  Leo Tolstoy

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[alansam]

On 1 September 2012 23:59, Mike Cowlishaw <[hidden email]> wrote:

Worth checking the generated code in any case .. I may have assumed and made all native methods static (but I would have thought I would have documented that, if so).

 

Mike

I'd already checked, the resulting method isn't static; I modified the NetRexx to remove the static modifier so it would compile:

method jniFunc(s = String) private native returns String

the generated Java is:

private native java.lang.String jniFunc(java.lang.String s);

and passing the results through javah creates the following C prototype in the header file:

JNIEXPORT jstring JNICALL Java_RJNIDemo_jniFunc

  (JNIEnv *, jobject, jstring);

as opposed to the pure Java static version:

private static native String jniFunc(String s);

which javah turns into:

JNIEXPORT jstring JNICALL Java_RJNIDemo_jniFunc

  (JNIEnv *, jclass, jstring);

The difference is that the second argument to the static method is a jclass where the non-static method gets a jobject.  Makes sense; static methods get a ref. to the class, non-static get a ref. to an object.

I also built both the Java and NetRexx versions into dynamic libraries; they both work.

While I can work around the problem with code I'm in control of, it places a limitation on NetRexx's ability to link to 3rd party JNI libraries that provide static methods.

Alan.

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[Mike Cowlishaw]

OK, thanks -- looks like a subtlety I was unaware of  (I don't think I ever used native methods).

 

Sounds like a language addition is needed.  Probably rather than allow two modifiers it would be better to add a new modifier ('nativestatic'?) just as 'constant' means static & final.

 

Mike

 

 

---

From: [hidden email] [mailto:[hidden email]] On Behalf Of Alan Sampson
Sent: 02 September 2012 09:52
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] JNI and static methods

On 1 September 2012 23:59, Mike Cowlishaw <[hidden email]> wrote:

Worth checking the generated code in any case .. I may have assumed and made all native methods static (but I would have thought I would have documented that, if so).

 

Mike

I'd already checked, the resulting method isn't static; I modified the NetRexx to remove the static modifier so it would compile:

method jniFunc(s = String) private native returns String

the generated Java is:

private native java.lang.String jniFunc(java.lang.String s);

and passing the results through javah creates the following C prototype in the header file:

JNIEXPORT jstring JNICALL Java_RJNIDemo_jniFunc

  (JNIEnv *, jobject, jstring);

as opposed to the pure Java static version:

private static native String jniFunc(String s);

which javah turns into:

JNIEXPORT jstring JNICALL Java_RJNIDemo_jniFunc

  (JNIEnv *, jclass, jstring);

The difference is that the second argument to the static method is a jclass where the non-static method gets a jobject.  Makes sense; static methods get a ref. to the class, non-static get a ref. to an object.

I also built both the Java and NetRexx versions into dynamic libraries; they both work.

While I can work around the problem with code I'm in control of, it places a limitation on NetRexx's ability to link to 3rd party JNI libraries that provide static methods.

Alan.

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

[ThSITC]

*I* would suggest simply 1 new keyword: *native*!

native static *might be*

 ***more human reading****

than *nativestatic*,

**********************************************************************************************
* which is *not yet defined* as an english word in my *english* Webster Thesaurus
**********************************************************************************************

<grin>

Bye,
Massa Thomas ;-)
=======================================================================
Am 03.09.2012 08:58, schrieb Mike Cowlishaw:

OK, thanks -- looks like a subtlety I was unaware of  (I don't think I ever used native methods).

 

Sounds like a language addition is needed.  Probably rather than allow two modifiers it would be better to add a new modifier ('nativestatic'?) just as 'constant' means static & final.

 

Mike

 

 

---

From: [hidden email] [[hidden email]] On Behalf Of Alan Sampson
Sent: 02 September 2012 09:52
To: IBM Netrexx
Subject: Re: [Ibm-netrexx] JNI and static methods

On 1 September 2012 23:59, Mike Cowlishaw <[hidden email]> wrote:

Worth checking the generated code in any case .. I may have assumed and made all native methods static (but I would have thought I would have documented that, if so).

 

Mike

I'd already checked, the resulting method isn't static; I modified the NetRexx to remove the static modifier so it would compile:

method jniFunc(s = String) private native returns String

the generated Java is:

private native java.lang.String jniFunc(java.lang.String s);

and passing the results through javah creates the following C prototype in the header file:

JNIEXPORT jstring JNICALL Java_RJNIDemo_jniFunc

  (JNIEnv *, jobject, jstring);

as opposed to the pure Java static version:

private static native String jniFunc(String s);

which javah turns into:

JNIEXPORT jstring JNICALL Java_RJNIDemo_jniFunc

  (JNIEnv *, jclass, jstring);

The difference is that the second argument to the static method is a jclass where the non-static method gets a jobject.  Makes sense; static methods get a ref. to the class, non-static get a ref. to an object.

I also built both the Java and NetRexx versions into dynamic libraries; they both work.

While I can work around the problem with code I'm in control of, it places a limitation on NetRexx's ability to link to 3rd party JNI libraries that provide static methods.

Alan.

--
Can't tweet, won't tweet!

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/

_______________________________________________
Ibm-netrexx mailing list
[hidden email]
Online Archive : http://ibm-netrexx.215625.n3.nabble.com/