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
Omitting the "int" parameter would be a bad idea since it would prevent
wrappers. One could imagine a common interface to obtain the caller class where
the proper implementation is chosen via fallback, e.g.
- if available, use our new API (fastest?)
- else, try to use Reflection.getCallerClass (
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,
On Jul 30, 2013, at 7:45 AM, Peter Levart wrote:
> I think there are various techniques to use new API when running on JDK8 and
> still use old API when running on JDK6 or 7. One way is to have 2 classes
> implementing the same interface or extending basic class where one is
> compiled with JD
"For caller-sensitive methods, the approach taken with new
Reflection.getCallerClass() is the right one, I think. There's no need to
support a fragile API when caller-sensitivity is concerned, so the lack of
"int" parameter, combined with annotation for marking such methods is correct
approach,
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-
I think there are various techniques to use new API when running on JDK8
and still use old API when running on JDK6 or 7. One way is to have 2
classes implementing the same interface or extending basic class where
one is compiled with JDK6/7 and the other with JDK8. During runtime the
"correct"
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 wanted
19 matches
Mail list logo
