You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Matt Sicker <bo...@gmail.com> on 2014/02/09 20:39:02 UTC
Good news about Reflection.getCallerClass(int) in JDK8.
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 <bo...@gmail.com>
Re: Good news about Reflection.getCallerClass(int) in JDK8.
Posted by Matt Sicker <bo...@gmail.com>.
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 <ni...@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 <ni...@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 <ni...@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 <bo...@gmail.com>
>>>
>>>
>>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Good news about Reflection.getCallerClass(int) in JDK8.
Posted by Nick Williams <ni...@nicholaswilliams.net>.
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 <ni...@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 <ni...@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 <bo...@gmail.com>
>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: Good news about Reflection.getCallerClass(int) in JDK8.
Posted by Matt Sicker <bo...@gmail.com>.
So does JDK8 add that security restriction to getCallerClass(int) as well?
On 9 February 2014 13:57, Nick Williams <ni...@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 <ni...@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 <bo...@gmail.com>
>>
>>
>>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Good news about Reflection.getCallerClass(int) in JDK8.
Posted by Nick Williams <ni...@nicholaswilliams.net>.
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 <ni...@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 <bo...@gmail.com>
>
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
Re: Good news about Reflection.getCallerClass(int) in JDK8.
Posted by Matt Sicker <bo...@gmail.com>.
Then I'm guessing abuse of JNI is out of the question, too?
On 9 February 2014 13:41, Nick Williams <ni...@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 <bo...@gmail.com>
>
>
>
--
Matt Sicker <bo...@gmail.com>
Re: Good news about Reflection.getCallerClass(int) in JDK8.
Posted by Nick Williams <ni...@nicholaswilliams.net>.
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 <bo...@gmail.com>