Oh ok, got it. So I can assume there will be a public API to replace it proposed for Java 9, implemented in a non-standard package in Java 10, and finally part of the standard API in Java 11. ;)
On 9 February 2014 14:04, Nick Williams <nicho...@nicholaswilliams.net>wrote: > No. Originally it /deleted/ getCallerClass(int) and replaced it with > getCallerClass(). This happened in Java 1.7.0_21. But that broke about a > billion open source projects, so we tried for months to convince them to > create a public API to replace it. I even submitted a proposal and patch, > which they ultimately rejected. They did, however, agree to restore > getCallerClass(int) in a deprecated but unrestricted state in 1.7.0_40+ and > 1.8.0_+ until they could create a public API to replace it in Java 9. > > Like I said ... go through the archives. :-) > > N > > > On Feb 9, 2014, at 1:58 PM, Matt Sicker wrote: > > So does JDK8 add that security restriction to getCallerClass(int) as well? > > > On 9 February 2014 13:57, Nick Williams <nicho...@nicholaswilliams.net>wrote: > >> 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 <nicho...@nicholaswilliams.net>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 <boa...@gmail.com> >>> >>> >>> >> >> >> -- >> Matt Sicker <boa...@gmail.com> >> >> >> > > > -- > Matt Sicker <boa...@gmail.com> > > > -- Matt Sicker <boa...@gmail.com>
