On Jul 30, 2013, at 4:11 PM, Nick Williams
wrote:
> Quick question for those of you that know anything about @CallerSensitive...
>
> After looking at the code and experimenting some, I've discovered that
> getCallerClass() doesn't actually keep going until it finds the first method
> without
On 07/31/2013 03:18 PM, Nick Williams wrote:
Okay, but I don't think @CallerSensitive is necessary to prevent
MethodHandles from spoofing caller classes. I'll admit I don't know
very much about MethodHandle, what it does, or how its invocation
methods are different from Method.invoke(). In the
I have patch for a public API for this just about complete. I'm going to re-run
unit tests tonight and then submit it. But I need some help.
I quickly figured out that I can't just `hg diff` from the root directory,
because of the whole "forrest" thing. Ick.
So, is there a specific way that I n
eeds code that it can pass a number into.
Nick
On Jul 30, 2013, at 7:17 AM, Peter Levart wrote:
>
> On 07/27/2013 09:01 PM, Nick Williams wrote:
>> All,
>>
>> In the last two months, there have been a number of discussions surrounding
>> stack traces, Class
Okay, but I don't think @CallerSensitive is necessary to prevent MethodHandles
from spoofing caller classes. I'll admit I don't know very much about
MethodHandle, what it does, or how its invocation methods are different from
Method.invoke(). In the code that I copied into this email from jvm.cp
Quick question for those of you that know anything about @CallerSensitive...
After looking at the code and experimenting some, I've discovered that
getCallerClass() doesn't actually keep going until it finds the first method
without @CallerSensitive. It only returns the caller of the caller. So,
annotated @CallerSensitive. In these cases, use of any new public
>> API must use reflection (sudo code: If Java 8, use new public
>> caller-sensitive API), so it needs code that it can pass a number into.
>>
>> Nick
>>
>> On Jul 30, 2013, at 7:17 AM, Peter Lev
that it can pass a number into.
Nick
On Jul 30, 2013, at 7:17 AM, Peter Levart wrote:
>
> On 07/27/2013 09:01 PM, Nick Williams wrote:
>> All,
>>
>> In the last two months, there have been a number of discussions surrounding
>> stack traces, Classes on the stac
Hi Nick,
The @CallerSensitive annotation is an annotation that prevents some
other infrastructure, namely the MethodHandles, to "spoof" caller classes.
Try this:
MethodHandles.Lookup lookup =
MethodHandles.lookup().in(Object.class);
MethodHandle mh = lookup.findStatic(Class.c
On 07/30/2013 06:46 PM, MacGregor, Duncan (GE Energy Management) wrote:
I can understand the worry about exposing @CallerSensitive methods, at
least for the case of lookup.in() as I'm sure it could be used to open an
exciting can of worms, but the current limitation doesn't feel quite
right. I w
Am 30.07.2013 17:58, schrieb Charles Oliver Nutter:
[...]
> Third, for language runtimes like Groovy, it seems to me that only
> *effort* is required to handle the passing down of the caller class.
> If we look at the facts, we see that getCallerClass is needed to skip
> intermediate frames by the
On 30/07/2013 16:58, "Charles Oliver Nutter" wrote:
>On Tue, Jul 30, 2013 at 7:17 AM, Peter Levart
>wrote:
>>Now that is the question for mlvm-dev mailing list: Isn't preventing
>>almost
>> all Lookup objects obtained by Lookup.in(RequestedLookupClass.class)
>>from
>> obtaining MHs of @CallerS
On Tue, Jul 30, 2013 at 7:17 AM, Peter Levart wrote:
> For outside JDK use, I think there are two main needs, which are actually
> distinct:
>
> a) the caller-sensitive methods
> b) anything else that is not caller-sensitive, but wants to fiddle with the
> call-stack
>
> For caller-sensitive metho
Am 30.07.2013 16:16, schrieb Peter Levart:
>
> On 07/30/2013 03:19 PM, Jochen Theodorou wrote:
>> Am 30.07.2013 14:17, schrieb Peter Levart:
>> [...]
>>> So what would give Groovy or other language runtimes headaches when all
>>> there was was a parameter-less getCallerClass() API? Aren't the
>>> i
On 07/30/2013 03:19 PM, Jochen Theodorou wrote:
Am 30.07.2013 14:17, schrieb Peter Levart:
[...]
So what would give Groovy or other language runtimes headaches when all
there was was a parameter-less getCallerClass() API? Aren't the
intermediate frames inserted by those runtimes controlled by t
Am 30.07.2013 14:17, schrieb Peter Levart:
[...]
> So what would give Groovy or other language runtimes headaches when all
> there was was a parameter-less getCallerClass() API? Aren't the
> intermediate frames inserted by those runtimes controlled by the
> runtimes? Couldn't the "surface" runtime-
Am 30.07.2013 14:17, schrieb Peter Levart:
[...]
> So what would give Groovy or other language runtimes headaches when all
> there was was a parameter-less getCallerClass() API? Aren't the
> intermediate frames inserted by those runtimes controlled by the
> runtimes? Couldn't the "surface" runtime-
two months, there have been a number of discussions surrounding
stack traces, Classes on the stack trace, and caller classes [1], [2], [3].
These are all related discussions and the solution to them is equally related,
so I wanted to consolidate it all into this one discussion where I hope w
On 07/27/2013 09:01 PM, Nick Williams wrote:
All,
In the last two months, there have been a number of discussions surrounding
stack traces, Classes on the stack trace, and caller classes [1], [2], [3].
These are all related discussions and the solution to them is equally related,
so I
19 matches
Mail list logo
