On 9/18/2013 9:22 AM, Nick Williams wrote:
Okay. Again, sorry for my absence. This wraps up my feedback for now. I now
await responses from Mandy.
On Sep 17, 2013, at 3:53 PM, Mandy Chung wrote:
You asked at a good time. I discussed this with John Rose last couple days on
this topic. He
On Sep 20, 2013, at 2:09 AM, Mandy Chung wrote:
On 9/18/2013 9:22 AM, Nick Williams wrote:
Okay. Again, sorry for my absence. This wraps up my feedback for now. I now
await responses from Mandy.
On Sep 17, 2013, at 3:53 PM, Mandy Chung wrote:
You asked at a good time. I discussed this
On 20. September 2013 at 09:28:52, Nick Williams
(nicholas+open...@nicholaswilliams.net) wrote:
This will give you an idea the API we are thinking about:
http://cr.openjdk.java.net/~mchung/jdk8/webrevs/walkstack-webrev/
Just to be clear, this means the patch I worked on for a month has been
Am 20.09.2013 09:28, schrieb Nick Williams:
[...]
This is all well and good, but some of us just need a simple array. This seems
like over-engineering. I just want an array of StackFrameInfos/StackTraceFrames.
if you need the full stack, then misusing a Predicate and a dummy
Consumer to
Am 20.09.2013 09:09, schrieb Mandy Chung:
[...]
Stack is a stream that allows you to walk partial stack (e.g. find
caller) or full stack trace (e.g. throwable). The filtering and mapping
operations are lazy to avoid having the VM eagerly copying the entire
stack trace data even for the short
Am 20.09.2013 10:50, schrieb Jörn Huxhorn:
[...]
But I have serious doubts that *this* is going to be more efficient than just
iterating over an array.
+1
Feel free to add all that functionality but all we are asking for right now is
access to the call stack array in a way that is as fast,
On 09/20/2013 09:28 AM, Nick Williams wrote:
On Sep 20, 2013, at 2:09 AM, Mandy Chung wrote:
On 9/18/2013 9:22 AM, Nick Williams wrote:
Okay. Again, sorry for my absence. This wraps up my feedback for now. I now
await responses from Mandy.
On Sep 17, 2013, at 3:53 PM, Mandy Chung wrote:
On 20. September 2013 at 11:03:49, Jochen Theodorou (blackd...@gmx.org) wrote:
Am 20.09.2013 10:50, schrieb Jörn Huxhorn:
[...]
But I have serious doubts that *this* is going to be more efficient than just
iterating over an array.
+1
Feel free to add all that functionality but all we are
On 09/20/2013 10:57 AM, Jochen Theodorou wrote:
Am 20.09.2013 09:28, schrieb Nick Williams:
[...]
This is all well and good, but some of us just need a simple array.
This seems like over-engineering. I just want an array of
StackFrameInfos/StackTraceFrames.
if you need the full stack, then
On 20. September 2013 at 11:35:24, Peter Levart (peter.lev...@gmail.com) wrote:
On 09/20/2013 10:57 AM, Jochen Theodorou wrote:
Am 20.09.2013 09:28, schrieb Nick Williams:
[...]
This is all well and good, but some of us just need a simple array.
This seems like over-engineering. I just
On 09/20/2013 10:58 AM, Jochen Theodorou wrote:
Am 20.09.2013 09:09, schrieb Mandy Chung:
[...]
Stack is a stream that allows you to walk partial stack (e.g. find
caller) or full stack trace (e.g. throwable). The filtering and mapping
operations are lazy to avoid having the VM eagerly copying
Am 20.09.2013 11:34, schrieb Peter Levart:
[...]
ListStackFrameInfo frames = new ArrayList();
Thread.walkStack(frames::add);
No so awfull.
as I said, it is unclear to me as of if walkStack walks the whole stack
or not. Your code implies it does. If It does, I don't see the advantage
of
Am 20.09.2013 12:05, schrieb Peter Levart:
[...]
The use-cases described used getCallerClass(int depth) repeatedly to
find a caller by iterating over a range of depths and calling
getCallerClass(depth). You can use either Thread.walkStack or
Thread.firstCaller for implementing those use-cases.
On 09/20/2013 12:56 PM, Jochen Theodorou wrote:
Am 20.09.2013 11:34, schrieb Peter Levart:
[...]
ListStackFrameInfo frames = new ArrayList();
Thread.walkStack(frames::add);
No so awfull.
as I said, it is unclear to me as of if walkStack walks the whole
stack or not. Your code implies it
On 09/20/2013 01:19 PM, Jochen Theodorou wrote:
that is I think a usecase for some... as I said, getCallerClass(int)
is not really ideal for us either. More ideal in this style would be
for us
public static T T findCaller(PredicateStackFrameInfo predicate,
On 09/20/2013 10:45 AM, Peter Levart wrote:
On 09/20/2013 12:56 PM, Jochen Theodorou wrote:
Am 20.09.2013 11:34, schrieb Peter Levart:
[...]
ListStackFrameInfo frames = new ArrayList();
Thread.walkStack(frames::add);
No so awfull.
as I said, it is unclear to me as of if walkStack walks the
Jochen,
On 9/20/13 4:19 AM, Jochen Theodorou wrote:
Am 20.09.2013 12:05, schrieb Peter Levart:
[...]
The use-cases described used getCallerClass(int depth) repeatedly to
find a caller by iterating over a range of depths and calling
getCallerClass(depth). You can use either Thread.walkStack or
On 9/20/13 1:58 AM, Jochen Theodorou wrote:
Am 20.09.2013 09:09, schrieb Mandy Chung:
[...]
Stack is a stream that allows you to walk partial stack (e.g. find
caller) or full stack trace (e.g. throwable). The filtering and mapping
operations are lazy to avoid having the VM eagerly copying the
Am 20.09.2013 20:46, schrieb Mandy Chung:
[...]
Exposing a StackStream API means that you need to eagerly walk the stack
and copy the stack frames to it before it returns. I agree it is a much
more flexible API. On the other hand, stack walking is sequential and
ordered and a stack stream will
Am 20.09.2013 17:45, schrieb Peter Levart:
[...]
I think the reasoning behind call-back API is that it moves the logic to
construct a suitable data structure to the Java side, skipping
intermediary representations and conversions.
StackFrameInfo is already a conversion for me. I see some value
Am 20.09.2013 18:38, schrieb Peter Levart:
[...]
As I understand the Thread.firstCaller() does exactly that.
findFirstCallerMatchingPredicate. Choosen name abbreviation is maybe
not making the semantic immediately obvious.
then sorry, I overlooked that in the link
though the usage of this is
Am 20.09.2013 20:46, schrieb Mandy Chung:
[...]
I have some trouble in expressing the skipToSecondPredicate without side
effect in lambda. With the help from Paul Sandoz (thanks Paul), if I
had a stack stream, Thread.getCaller() method would be like this:
stream.filter(e - return
On 9/20/2013 2:46 PM, Jochen Theodorou wrote:
Exposing a StackStream API means that you need to eagerly walk the stack
and copy the stack frames to it before it returns. I agree it is a much
more flexible API. On the other hand, stack walking is sequential and
ordered and a stack stream will
On 09/21/2013 01:58 AM, Mandy Chung wrote:
On 9/20/2013 2:46 PM, Jochen Theodorou wrote:
Exposing a StackStream API means that you need to eagerly walk the
stack
and copy the stack frames to it before it returns. I agree it is a
much
more flexible API. On the other hand, stack walking is
On 9/20/2013 5:25 PM, Remi Forax wrote:
What you can do is to call a function that will take the stream as
argument and close the stream after its use and before returning.
R R processStackStream(FunctionStackStream, R fun) {
StackStream stackStream = new
On Sep 18, 2013, at 9:30 AM, Nick Williams wrote:
On Sep 3, 2013, at 7:02 PM, Mandy Chung wrote:
So for log4j to work with security manager installed, it would have
torequire the application to grant certain permissions - can you confirm?
Maybe one of the other Log4j guys listening
On Sep 3, 2013, at 7:02 PM, Mandy Chung wrote:
Nick,
I skimmed through the changes. Congratulations for your first patch making
changes in both hotspot and jdk code.
Thanks. And, again, apologies for my extended absence.
In my mind, the Log4J use case accessing Class instance to obtain
On Sep 9, 2013, at 12:57 PM, Peter Levart wrote:
On 09/09/2013 07:02 PM, David Chase wrote:
Take this lightly informed suggestion with a grain of salt, but why not, for
purposes of performance and security,
change the logging-specific getCallerClass methods so that their class
Okay. Again, sorry for my absence. This wraps up my feedback for now. I now
await responses from Mandy.
On Sep 17, 2013, at 3:53 PM, Mandy Chung wrote:
On 9/17/13 10:32 AM, cowwoc wrote:
Hi,
Has this been any new progress on this thread?
On Sep 4, 2013, at 6:23 PM, Mandy Chung wrote:
On 9/1/2013 1:16 AM, Nick Williams wrote:
Class? getCallerClass(): Retrieves the class of the caller of the method
calling getCallerClass(). This is identical to the new
Reflection#getCallerClass() added in Java 7u25/8.
Class?
On Sep 18, 2013, at 11:28 AM, Mandy Chung wrote:
On 9/18/2013 9:20 AM, Nick Williams wrote:
On Sep 9, 2013, at 4:41 PM, Mandy Chung wrote:
On 9/9/13 10:02 AM, David Chase wrote:
Take this lightly informed suggestion with a grain of salt, but why not,
for purposes of performance and
Hi,
Has this been any new progress on this thread?
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/thread.html#20480
I'd like to second Jörn concerns that shipping JDK8 (less than a
month to go!) without a fix would be extremely problematic. The
performance
On 9/17/13 10:32 AM, cowwoc wrote:
Hi,
Has this been any new progress on this thread?
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/thread.html#20480
I have sent my feedback a couple weeks ago on this proposed patch but
haven't heard back from Nick.
You asked
Nick,
Do you have any information to some of the questions I asked below that
can help the API discussion?
We need to decide on the permission check and also the hotspot change
has to be integrated and the jdk change will need to wait until it shows
in a promoted build. Schedule-wise, to
On 09/08/2013 09:34 PM, Mandy Chung wrote:
On 9/4/2013 6:02 PM, David M. Lloyd wrote:
This seems reasonable on the surface but falls over once you capture
the caller for more than one purpose. For example, say a logging
framework captures the caller for the purpose of supplementing log
Take this lightly informed suggestion with a grain of salt, but why not, for
purposes of performance and security,
change the logging-specific getCallerClass methods so that their class
references are instead wrapped in some sort of proxy object that only forwards
certain operations quickly
After some thought the below idea seems not good. Currently j.l.Class
objects can be used to transfer privilige from code that can obtain
them to code that can't (like MHs for example). So doing what I proposed
would disable this ability.
Regards, Peter
Hi,
This is a good idea. It got me
On 09/09/2013 07:02 PM, David Chase wrote:
Take this lightly informed suggestion with a grain of salt, but why not, for
purposes of performance and security,
change the logging-specific getCallerClass methods so that their class
references are instead wrapped in some sort of proxy object that
On 9/9/13 10:02 AM, David Chase wrote:
Take this lightly informed suggestion with a grain of salt, but why not, for
purposes of performance and security,
change the logging-specific getCallerClass methods so that their class
references are instead wrapped in some sort of proxy object that only
On 09/09/2013 04:56 PM, Mandy Chung wrote:
On 9/9/13 10:01 AM, David M. Lloyd wrote:
I'm not sure if we can be very certain about the depth in a runtime
environment (non-debugging) unless it requires all VM implementation to
support a reliable way to return a frame at a given depth.
The stack
On 9/4/2013 6:02 PM, David M. Lloyd wrote:
This seems reasonable on the surface but falls over once you capture
the caller for more than one purpose. For example, say a logging
framework captures the caller for the purpose of supplementing log
information. But you call this logging
On 09/04/2013 06:23 PM, Mandy Chung wrote:
On 9/1/2013 1:16 AM, Nick Williams wrote:
Class? getCallerClass(): Retrieves the class of the caller of the
method calling getCallerClass(). This is identical to the new
Reflection#getCallerClass() added in Java 7u25/8.
Class? getCallerClass(int):
On 02/09/2013 18:45, Nick Williams wrote:
:
I didn't decide to ignore the security concerns, I just don't see any security
concerns. As has been /clearly/ established in the last three months,
frameworks have been using getCallerClass for years, if not a decade. It has
never caused a
On 09/03/2013 11:07 AM, Alan Bateman wrote:
On 02/09/2013 18:45, Nick Williams wrote:
:
I didn't decide to ignore the security concerns, I just don't see any
security concerns. As has been /clearly/ established in the last
three months, frameworks have been using getCallerClass for years, if
On Sep 3, 2013, at 4:07 AM, Alan Bateman wrote:
On 02/09/2013 18:45, Nick Williams wrote:
:
I didn't decide to ignore the security concerns, I just don't see any
security concerns. As has been /clearly/ established in the last three
months, frameworks have been using getCallerClass for
It's simple enough to just create an accessor object and add a security
check on creation. There does not need to be a significant jam-up over
this issue afaict.
On 09/03/2013 07:24 AM, Nick Williams wrote:
On Sep 3, 2013, at 4:07 AM, Alan Bateman wrote:
On 02/09/2013 18:45, Nick Williams
On 03/09/2013 13:24, Nick Williams wrote:
:
As regards frameworks using sun.reflect.Reflection.getCallerClass directly then
it's as I said previously, they are probably not run with a security manager
very often (at least not unless the policy is configured to allow direct access
to sun.*).
Nick,
I skimmed through the changes. Congratulations for your first patch
making changes in both hotspot and jdk code.
In my mind, the Log4J use case accessing Class instance to obtain
additional information for diagnosability is different than the use case
of obtaining the caller's class
Just realize that I missed a few words in a sentence that could mislead
what I really mean correction below.
On 9/3/2013 5:02 PM, Mandy Chung wrote:
Nick,
I skimmed through the changes. Congratulations for your first patch
making changes in both hotspot and jdk code.
In my mind, the
On 01/09/2013 21:04, Nick Williams wrote:
:
So David says he thinks he can find someone at RedHat to sponsor this, assuming
it looks good.
Nick
I see the patch is accessible now.
From a quick scan then it appears that you've decided to ignore the
security concerns so I don't think anyone
On 02/09/2013 09:33, Alan Bateman wrote:
From a quick scan then it appears that you've decided to ignore the
security concerns so I don't think anyone can (or should) sponsor this
patch until there is further discussion on the API and the security
implications.
I've barely looked through the
On 2. September 2013 at 10:33:59, Alan Bateman (alan.bate...@oracle.com) wrote:
On 01/09/2013 21:04, Nick Williams wrote:
:
So David says he thinks he can find someone at RedHat to sponsor this,
assuming it looks good.
Nick
I see the patch is accessible now.
From a quick scan then
On 02/09/2013 15:08, Jörn Huxhorn wrote:
:
Nick also explained a performance issue in Thread#getStackTrace() and
Throwable#getStackTrace(). Keeping that in mind, I'm not sure if going for start
small (i.e. leaving that issue alone) would be a wise decision.
It was a non goal of JEP 176 to
On 09/02/2013 03:56 PM, Tom Hawtin wrote:
On 02/09/2013 09:33, Alan Bateman wrote:
From a quick scan then it appears that you've decided to ignore the
security concerns so I don't think anyone can (or should) sponsor this
patch until there is further discussion on the API and the security
On Sep 2, 2013, at 9:59 AM, Alan Bateman wrote:
It was a non goal of JEP 176 to provide @CallerSensitive as a public API. So
the suggestion to start out small was to leave that out and focus on some of
the use-cases initially. I don't think this suggestion is unreasonable as it
allows the
On 09/02/2013 06:45 PM, Nick Williams wrote:
On Sep 2, 2013, at 9:59 AM, Alan Bateman wrote:
It was a non goal of JEP 176 to provide @CallerSensitive as a public API. So
the suggestion to start out small was to leave that out and focus on some of
the use-cases initially. I don't think this
I have completed and am proposing a patch for replacing
sun.reflect.Reflection#getCallerClass(...) with a public API in Java 8. I saw
no point in duplicating an issue, even though it's over 10 years old, so I'm
indicating that this is a patch for 4851444
On 01/09/2013 09:16, Nick Williams wrote:
:
I believe I have followed all of the procedures as closely as possible. I await
feedback and hope for some support on this, so that we can get a public
replacement for this method in Java 8. Let me know if you have any questions.
You may need to
This looks pretty awesome!
There are just two small things I'd suggest:
Rename
StackTraceFrame[] getCurrentStackTrace()
to
StackTraceFrame[] getStackFrames() (I'd prefer this one…)
or
StackTraceFrame[] getStackTraceFrames() (…while this one is probably more
accurate.)
or
StackTraceFrame[]
Interesting. I can access HTTPS in all of my browsers. OT, to help my figure
out what's up with my HTTPS, what browsers and versions are y'all using, Jörn
and Alan?
N
On Sep 1, 2013, at 10:40 AM, Jörn Huxhorn wrote:
This looks pretty awesome!
There are just two small things I'd suggest:
As Jörn pointed out, you can also use HTTP. Could you tell me which
browser/version you're using? I'd love to figure out what's up with my HTTPS. I
can access it in all my browsers.
I understand your point about making CallerSensitive public being a non-goal of
JEP 176. But, if we're going to
On 09/01/2013 09:50 AM, Nick Williams wrote:
Interesting. I can access HTTPS in all of my browsers. OT, to help my
figure out what's up with my HTTPS, what browsers and versions are
y'all using, Jörn and Alan?
I get the same problems with Firefox 23 on Linux. This will help you
debug some
Thanks for the help, everyone! The Qualys SSL Labs tool was invaluable.
Apparently using -SSLv3 in the SSLCipherSuite setting in Apache also disables
TLSv1.0 and TLSv1.2, breaking most clients. Not very intuitive, but I got it
sorted out so that I'm supporting only TLSv1.0 through TLSv1.2,
63 matches
Mail list logo
