David Holmes writes: > I filed a documentation bug against this method because it implied that it > was only called by SecurityManager.getClassContext() when in fact it is also > calld by Class and ClassLoader directly. This makes it awkward for > VMSecurityManager.getClassContext() to know how many stack frames it needs > to pop to return the "true" caller. > > But looking at how Class and ClassLoader use this method we have code of the > form: > > Class c = VMSecurityManager.getClassContext()[1]; > ClassLoader cl = c.getClassLoader(); > > getClassContext() is only being used to find the class of the immediate > caller. This is horrendously inefficient in terms of time and space. Might I > suggest that a method be added to Class/VMClass or VMClassLoader or > VMSecurityManager to simply return a single Class from the current calling > context: > > /** > * Return the Class of the method at the given position on the call > stack. This is > * logically equivalent to > <tt>VMSecurityManager.getClassContext()[pos]</tt> but does > * not need to traverse the whole call stack nor construct an array. > * @param pos the position in the callstack: 0 is the caller of this > method, 1 the > * caller of that method, etc. > * @return the Class of the method at the given position in the callstack > * @throws IllegalArgumentException if <tt>pos</tt> is negative or > greater than the > * depth of the call stack. > */ > static native Class getClassFromContext(int pos); > > That also simplifies VMSecurityManager.getClassContext() because it now > knows that its caller is always SecurityManager.getClassContext().
This seems like a reasonable idea. In several cases we need to say "who is our caller?" and some VM assistance is useful here. Andrew. _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
