Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / November 2005

Tip: Looking for answers? Try searching our database.

accessing a Java int array from JNI

Thread view: 
spam_to_dev_null@yahoo.com - 04 Nov 2005 00:34 GMT
How can I access an encapsulated Java int array from a
native method, given the Object that declared it?  ie, can
anyone replace the 3rd & 4th lines in the first native method
below with actual code that does the job?

Also, assuming that this problem is solvable, is it possible
to keep an array locked-down in the JVM beyond the scope
of the first native method that was called?  Obviously, my
goal is to write a third native method that can be called by
the Java side whenever it wants to repopulate an array with
data available to the native code but only go through the over-
head of translating the address space one time.  (Yes,
synchronization may be tricky; but for this app, I don't really
care how volitile the data appears to be on the Java side as
long as it gets updated *fast* and without cloning/copying.)

TIA,

// file Main.java

class MyObject
  {
  int myArray[] = new int[500000];
  }

class Main
  {
  public void native doSomething (Object o);
  public void native releaseArray ();

  public static void main (String args[])
     {
     MyObject mo = new MyObject ();
     mo.myArray[4] = 4321;
     doSomething (mo);
     // yada yada ...
     releaseArray ();
     }
  }

// file myjni.cc

include "Main.h"

jbyte *data = NULL;
jarray array;

JNIEXPORT void JNICALL
Java_Main_doSomething (JNIEnv *env, jobject obj, jobject anObject)
  {
  jclass clazz = env -> GetObjectClass (anObject);
  jfieldID fid = env -> GetFieldID (clazz, "myArray", "[I");

// HULP NEEDED HERE!
  jniMagic hulp = env -> CallSomeJNImethodIhaventHeardAbout (fid);
  array = env -> MoreHulpNeededHere (hulp);

  int isCopy;
  data = env -> GetPrimitiveArrayCritical (array, &isCopy);
  if (data[4] > 4000)
     printf ("yeah, verily!\n");
  else
     printf ("boo, hiss!\n");
  }

JNIEXPORT void JNICALL
Java_Main_releaseArray (JNIEnv *env, jobject obj)
  {                                  // is this legal and/or wise?
  if (data != NULL)
     {
     env -> ReleasePrimitiveArrayCritical (array, data, JNI_ABORT);
     data = NULL;
     }
  }
Gordon Beaton - 04 Nov 2005 07:40 GMT
> How can I access an encapsulated Java int array from a native
> method, given the Object that declared it? ie, can anyone replace
> the 3rd & 4th lines in the first native method below with actual
> code that does the job?

The JNI function you're looking for is GetObjectField() (arrays are
Objects).

Note that there is no need to pass your object as an explicit argument
to the native method not declared static. "this" is always passed
anyway (in your example, you get it twice).

> Also, assuming that this problem is solvable, is it possible to keep
> an array locked-down in the JVM beyond the scope of the first native
[quoted text clipped - 5 lines]
> really care how volitile the data appears to be on the Java side as
> long as it gets updated *fast* and without cloning/copying.)

Presumably you can hang on to your native copy as long as you want,
but realize that any changes you make won't propagate back to the
original array until you call ReleaseIntArrayElements(). Otherwise
maybe have a look at Get/SetIntArrayRegion() instead.

/gordon

Signature

[  do not email me copies of your followups  ]
g o r d o n + n e w s @  b a l d e r 1 3 . s e

Chris Uppal - 04 Nov 2005 11:49 GMT
> Also, assuming that this problem is solvable, is it possible
> to keep an array locked-down in the JVM beyond the scope
> of the first native method that was called?

I'm not sure whether that is possible.  It /might/ be, but there are issues.
The get/release JNI functions work with a jobject, and jobects are not valid
past the lifetime of the call to a native method, so you could not use the
/same/ jobject for both get and release.  The JVM /might/ allow you to release
the array data in a separate call with a different jobject that "pointed" to
the same Java array, but I don't think there's any guarantee that it will work.
So at best it's implementation dependent.  Unfortunately, I suspect that it
might be one of those things that /seem/ to work, but still fail intermitently.

You might want to review the recent thread "Passing large C buffers to Java
(via JNI) without copying?" for more options and opinions.

   -- chris


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2009 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.