1 / 14

Administrivia

Administrivia. No class next Monday (May 2) Enjoy extra time on P3. ;-) Reading 3 available “Reflections on Trusting Trust”, Ken Thompson No written summary due. I Dream of JNI. ...but it’s a nightmare. The Gospel According to K&R.

amber
Download Presentation

Administrivia

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Administrivia • No class next Monday (May 2) • Enjoy extra time on P3. ;-) • Reading 3 available • “Reflections on Trusting Trust”, Ken Thompson • No written summary due

  2. I Dream of JNI... ...but it’s a nightmare

  3. The Gospel According to K&R In the Beginning, Kernighan said unto Ritchie, “Let us create C in the image of B after our own whims. And let it have dominion over the I and the O and all the data that runneth upon the bus.” And it was almost, but not quite so, and Kernighan saw that he had his work cut out for him...

  4. Java Native code Interface (JNI) • When you absolutely, positively have to talk to C... • Interfacing to existing libraries • Special OS system calls not accessible from Java • symlink, fcntl, iocntl, etc. • Optimizing critical sections (danger Will Robinson!) • JNI allows Java to call C functions and vice versa • Specific to a particular JVM

  5. Dangers of JNI • Data in C space not garbage collectable • Can get handles to Java data structs and “pin them down” indefinitely • Data in C space not relocatable • Can’t resize Vectors, etc. while C has handle to them • C code not portable • C really, really, really not object oriented • Can easily corrupt Java data structs from C • Much harder to be threaded • Have to work harder to “play nice”

  6. Building a JNI application • Write Java code first • Create “stub” functions for C function names • Mark w/ native keyword • Use static section to load shared library • Compile Java • Extract C header fn. info from .class file w/ javah • Write C function to header spec • Compile C function to shared library (DLL) • Run java program

  7. Native functions • native keyword is java function marker • Similar to abstract -- tells Java that you’re not providing a function body • Unlike abstract, class will still compile • Java assumes it’s not responsible -- function defined elsewhere • native funcs can be public/protected/ private, static/non-static, any args/return type • Not sure about synchronized

  8. Extracting a Header • Java expects native function to translate to a specific C function name/signature • Use javah tool to get header info from .class file • javah -jni MyClass • Produces MyClass.h public native static void doit(); <=> JNIEXPORT void JNICALL Java_SimpleJNI_doit (JNIEnv *, jclass);

  9. Writing the C code • #include <jni.h> • #include <MyClass.h> • Use same function signature that MyClass.h specifies • Note! If you change native func declaration in Java -> change header file -> change C file. Beware! • Access Java data via args to func • Can provide additional C funcs, C local data, etc.

  10. Why shared libraries? • Java doesn’t live in same executable model as C • C: • Compile .c to .o • Link many .o’s into single executable • At runtime, link in (load) shared libraries • Java: • Compile .java to .class • No linkage step • At runtime, JVM loads each relevant .class file • Closest C equiv to Java model is shared lib

  11. Making a shared library • A.k.a., dynamically loadable library (DLL) • On linux/UNIX: libMyLibName.so • On Windows: MyLibName.dll • On Mac OSX: libMyLibName.dylib • Creating them different for each platform/compiler (ugh) • Linux: gcc -shared -fPIC -DPIC -fno-exceptions • Windows: ??? • Mac OSX: gcc -dynamiclib • Have to make sure dynamic loader search path is right

  12. Accessing Java data • Java .class -> .h provides extra args to func signature • JNIEnv *envPtr -- pseudo-“class”: provides Java utility functions • Data allocation/deallocation, access/release, etc. • jclass classPtr -- ptr to class of object that called native method (static case) • jobject objPtr -- “this” -- ptr to object that called native method (non-static case) • Other args/return vals are Java method args

  13. Accessing Java data, II • Atomic types (int, char, float, etc.) directly accessible • Declared jint, jchar, jfloat, etc. • Anything more complex requires hoops... jstring sArg; char *cStr= (char*)(*envPtr)->GetStringUTFChars(envPtr,sArg,0); /* do stuff with cStr */ (*envPtr)->ReleaseStringUTFChars(envPtr,sArg,str);

  14. Accessing Java data, III • GetStringUTFChars() tells Java “C has a pointer to this; don’t garbage collect it and don’t move it”. • Have to explicitly release with ReleaseStringUTFChars • Same rule for any Get*()/Release*() functions • Good rule of thumb: • Call Get*() when enter function/block and Release*() when leaving it • Similar functions for calling methods, accessing object local data/fields, etc.

More Related