diff --git a/docs/html/training/articles/perf-jni.jd b/docs/html/training/articles/perf-jni.jd index 1a40f62376799..5a9fa1e04b463 100644 --- a/docs/html/training/articles/perf-jni.jd +++ b/docs/html/training/articles/perf-jni.jd @@ -635,20 +635,31 @@ avoid some problems.
FindClass find my class?(Most of this advice applies equally well to failures to find methods
+with GetMethodID or GetStaticMethodID, or fields
+with GetFieldID or GetStaticFieldID.)
Make sure that the class name string has the correct format. JNI class
names start with the package name and are separated with slashes,
such as java/lang/String. If you're looking up an array class,
you need to start with the appropriate number of square brackets and
must also wrap the class with 'L' and ';', so a one-dimensional array of
-String would be [Ljava/lang/String;.
String would be [Ljava/lang/String;.
+If you're looking up an inner class, use '$' rather than '.'. In general,
+using javap on the .class file is a good way to find out the
+internal name of your class.
+
+If you're using ProGuard, make sure that +ProGuard didn't +strip out your class. This can happen if your class/method/field is only +used from JNI.
If the class name looks right, you could be running into a class loader
issue. FindClass wants to start the class search in the
class loader associated with your code. It examines the call stack,
which will look something like:
Foo.myfunc(Native Method) - Foo.main(Foo.java:10) - dalvik.system.NativeStart.main(Native Method)+ Foo.main(Foo.java:10)
The topmost method is Foo.myfunc. FindClass
finds the ClassLoader object associated with the Foo
@@ -656,12 +667,9 @@ class and uses that.
This usually does what you want. You can get into trouble if you
create a thread yourself (perhaps by calling pthread_create
-and then attaching it with AttachCurrentThread).
-Now the stack trace looks like this:
dalvik.system.NativeStart.run(Native Method)- -
The topmost method is NativeStart.run, which isn't part of
-your application. If you call FindClass from this thread, the
+and then attaching it with AttachCurrentThread). Now there
+are no stack frames from your application.
+If you call FindClass from this thread, the
JavaVM will start in the "system" class loader instead of the one associated
with your application, so attempts to find app-specific classes will fail.