Yes. The C++ code enforces the restriction. I've edited it, so I know it first hand. :-)
Nick On Feb 9, 2014, at 1:51 PM, Matt Sicker wrote: > Then I'm guessing abuse of JNI is out of the question, too? > > > On 9 February 2014 13:41, Nick Williams <[email protected]> wrote: > There have been extensive discussions about getCallerClass(), which you can > find throughout the archives of the developer's list and the JDK > core-libs-dev list. In very abbreviated form, only privileged, JDK code can > call getCallerClass(). They initially removed getCallerClass(int), but we > convinced them to restore it until they could come up with a public API > replacement in Java 9. > > We cannot do as you suggest. > > Nick > > > On Feb 9, 2014, at 1:39 PM, Matt Sicker wrote: > >> Now I'm not sure if this is official, but I was digging around the JDK8 code >> and found a neat additional method in sun.reflect.Reflection. The old >> getCallerClass(int) method has been deprecated, but instead, there's a >> getCallerClass() method that effectively does the same thing as >> getCallerClass(2). This method is documented as ignoring any reflective >> method calls in the stack. It delegates to a native method call >> (JVM_GetCallerClass(JNIEnv*, int)) which appears to still be >> OpenJDK-specific. >> >> Anyway, this brings up an interesting use-case of the old >> getCallerClass(int) method. From what I've seen in various places in the >> source code, getCallerClass(int) is almost always (if not always) called >> with the value of "2". Thus, what I'd propose is to introduce a >> getCallerClass() method that defaults to the usual stack depth. I'd prefer >> to see this sort of helper class in log4j-api instead of duplicating this >> functionality in at least 2 or 3 separate locations as it is now. >> >> -- >> Matt Sicker <[email protected]> > > > > > -- > Matt Sicker <[email protected]>
