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
On 02/08/2013 14:15, Nick Williams wrote:
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
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
On 8/1/13 3:58 PM, Nick Williams wrote:
>
> On Aug 1, 2013, at 8:01 AM, Dalibor Topic wrote:
>
>> On 7/30/13 2:01 PM, Jörn Huxhorn wrote:
>>> See http://code.ohloh.net/search?s=Reflection.getCallerClass for a rough
>>> estimate about the impact of this change.
>>
>> Eh, no. Try
>> http://code.
On Aug 1, 2013, at 8:01 AM, Dalibor Topic wrote:
> On 7/30/13 2:01 PM, Jörn Huxhorn wrote:
>> See http://code.ohloh.net/search?s=Reflection.getCallerClass for a rough
>> estimate about the impact of this change.
>
> Eh, no. Try
> http://code.ohloh.net/search?s=%22Reflection.getCallerClass%28%
On 7/30/13 2:01 PM, Jörn Huxhorn wrote:
> See http://code.ohloh.net/search?s=Reflection.getCallerClass for a rough
> estimate about the impact of this change.
Eh, no. Try
http://code.ohloh.net/search?s=%22Reflection.getCallerClass%28%22&pp=0&fl=Java&ff=1&mp=1&ml=1&me=1&md=1&filterChecked=true
i
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
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
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,
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
intermediate frame
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-insert
On Tue, Jul 30, 2013 at 8:25 AM, Nick Williams <
[email protected]> wrote:
> 42 MILLION uses of Reflection.getCallerClass(int) on Ohloh!?!? Holy crap...
>
Considering that the Ohloh search results page also bolds occurrences of
"Reflection", "class" and "get" for that search [
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
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 (
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"
"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,
42 MILLION uses of Reflection.getCallerClass(int) on Ohloh!?!? Holy crap...
In case anyone is interested, I am almost finished implementing the public API
StackTraceFrame and associated C/C++ code. It has been an eye-opening
experience, but I think I have it figured out now. I just have to write
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
This whole issue started with the "fix" of
http://bugs.sun.com/view_bug.do?bug_id=8016814 because, obviously, throwing an
UnsupportedOperationException is a straightforward and reasonable way of fixing
an off-by-one problem with the description "returns the wrong stack frame" (see
http://mail.o
On Jul 29, 2013, at 11:59 PM, Joseph Darcy wrote:
>
> On 7/29/2013 9:31 PM, Alan Bateman wrote:
>> On 29/07/2013 19:17, David M. Lloyd wrote:
>>>
>>> Your phrasing makes me think I missed something: is the
>>> Reflection.getCallerClass() method being removed due to some technical
>>> issue th
On 7/29/2013 9:31 PM, Alan Bateman wrote:
On 29/07/2013 19:17, David M. Lloyd wrote:
Your phrasing makes me think I missed something: is the
Reflection.getCallerClass() method being removed due to some
technical issue that it can only be somehow emulated as a
workaround? Or is it just a ge
On 29/07/2013 19:17, David M. Lloyd wrote:
Your phrasing makes me think I missed something: is the
Reflection.getCallerClass() method being removed due to some technical
issue that it can only be somehow emulated as a workaround? Or is it
just a general cleanup effort?
The sun.reflect.Refl
On 07/29/2013 08:38 PM, Alan Bateman wrote:
On 29/07/2013 15:48, Paul Benedict wrote:
+1 with Nick. There's no point in submitting a patch unless someone
who is
in charge of Core Libs Dev is willing to first offer technical direction.
Where does Oracle want to go with the solution? There are no
On 29/07/2013 15:48, Paul Benedict wrote:
+1 with Nick. There's no point in submitting a patch unless someone who is
in charge of Core Libs Dev is willing to first offer technical direction.
Where does Oracle want to go with the solution? There are no official
responses -- it's been quiet on thei
Answers:
1) Seems reasonable enough.
2) I think this will be quite complicated in practice. First, we don't
want to obliterate performance, so we need some way to only assemble
this information if necessary (assembling two stack traces is likely to
be twice as expensive as assembling one, af
Okay. Some questions then:
1) Instead of Executable, StackTraceFrame could simply have the method name.
Using Executable would be more future-proof (I anticipate someone wanting to
know that someday), so if it turns out it's available I'd prefer to use it, but
if it's not physically available t
I don't see how Throwables could be deserialized with the proposed
changes to that class (Class.forName() only works when everything is
visible from one class loader - a trivial case which is rarely true in
practice, especially in an app server situation). I think you'd have to
leave that part
I would happily contribute a patch if I were able to. However, I have almost no
idea what I'm doing on the native side, and I spent three hours perusing the
Mercurial repository and still can't figure out where anything is.
Even so, I would be willing to try. But I can't just blindly make up a p
I expect that at this stage, patches speak louder than words :)
On 07/29/2013 03:57 PM, Jörn Huxhorn wrote:
I second all of that.
It was my understanding that the whole purpose of EA and DP was pinpointing
problems like these before they hit consumers. What's the point of them if
feedback can
I second all of that.
It was my understanding that the whole purpose of EA and DP was pinpointing
problems like these before they hit consumers. What's the point of them if
feedback can't cause the reverting of a breaking change?
If this is not rectified then the old "Java is slow"-mantra will
Some interesting things to note:
1) Someone has been asking for a public API replacement for getCallerClass()
since Java 4 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4851444). I
/would/ have been asking for this for that long, except I haven't needed it
until recently and assumed it al
+1
On 29. Juli 2013 at 15:50:36, Paul Benedict ([email protected]) wrote:
If it is not possible in the remaining dev time for JDK8 to expose
Reflection.getCallerClass() functionality through some public API, why must
-Djdk.reflect.allowGetCallerClass be discontinued so soon? Why the hot
The numbers are from this link:
http://stackoverflow.com/questions/421280/in-java-how-do-i-find-the-caller-of-a-method-using-stacktrace-or-reflection
Even if this benchmark suffers from micro-benchmark issues:
a slow-down of 10x would be bad, a slow-down of 100x would be a catastrophe.
I'd sugge
I wasn't the one who ran the test, so I don't know for sure. My theory
was that getCallerClass() returns a single frame, but the
SecurityManager must allocate an array of appropriate size (which
involves some overhead) and then return all of the frames. I chalked
the difference up to that. My concl
I find it very interesting that reflection is no less than two orders of
magnitude faster than the security manager solution. How big was the
stack in these tests? It makes me wonder if maybe the implementation of
the security manager's getContext() method should be reevaluated a bit.
On 07/
Just so that everyone understands how important this subject is, this change to
getCallerClass(...) is being labeled a "disaster" for logging frameworks
everywhere. Here's a benchmark for getting Classes from the following methods:
> 1,000,000 calls of all alternatives were measured as follows :
38 matches
Mail list logo
