logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <boa...@gmail.com>
Subject Re: Good news about Reflection.getCallerClass(int) in JDK8.
Date Sun, 09 Feb 2014 20:17:48 GMT
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 <nicholas@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 <nicholas@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 <nicholas@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 <boards@gmail.com>
>>>
>>>
>>>
>>
>>
>> --
>> Matt Sicker <boards@gmail.com>
>>
>>
>>
>
>
> --
> Matt Sicker <boards@gmail.com>
>
>
>


-- 
Matt Sicker <boards@gmail.com>

Mime
View raw message