On 5/11/2011 5:39 AM, Alan Bateman wrote:
On 04/11/2011 12:03, Heiko Wagner wrote:
Hi Tom, thanks for your reply. I am using JNI in a different,propably
never
designed to be used that way, kind of scenario. I use JNI to bring
Java to a
legacy Smalltalk based product[1].
The Smalltalk code does directly invoke the JNI calls from its own
Smalltalk
VM main thread. So the Java VM is not aware of the calling thread and
has no
call stack information. Currently, I am using
ClassLoader.getSystemClassLoader(), which perfectly works for me. I
have no
idea if this makes sense in gerneal, but for me a
MissingResourceBundleException in my use case, would be what I propably
would have expected, instead of a ArrayIndexOutOfBoundsException, so
maybe a
additional size check on the call stack array size would make sense.
The thread must be known to the VM as otherwise you wouldn't have a
JNIEnv and wouldn't be able to call the method (so I'll bet the thread
is attaching via AttachCurrentThread somewhere).
As to the ArrayIndexOutOfBoundsException, that does seem to be a bug as
I assume that getClassContext is returning an array of one element
corresponding to the caller frame (getBundle in this case).
There are a handful of places in the JDK where this kind of stack-based
check is used and the assumption is always that there is a "client" Java
caller in the stack. Given this kind of code is unaware of the context
in which it is called in general, what exception would you throw if you
find there is no Java client caller? In the current case the specs for
getBundle state that it is the equivalent of calling the
classloader-taking form with the expression
this.getClass().getClassLoader(). But in the current case there is no
this, no current class and no current classloader - so what exception do
you throw? "new RuntimeException("Expected Java caller not found")?
I don't think throwing MissingResourceBundleException is the right way
to go here because it hides the mis-use of this API.
David
-Alan.
