986> for
Windows 10
*From: *John Rose
*Sent: *Thursday, November 19, 2015 05:45
*To: *David Holmes
*Cc: *OpenJDK Dev list
*Subject: *Re: Proposed API for JEP 259: Stack-Walking API
On Nov 18, 2015, at 6:32 PM, David Holmes <david.hol...@oracle.com> wrote:
>
>>>
:12
To: Timo Kinnunen;John Rose
Cc: OpenJDK Dev list
Subject: Re: Proposed API for JEP 259: Stack-Walking API
On 19/11/2015 11:36 PM, Timo Kinnunen wrote:
> A point in favor of UnsupportedOperationException would be: if in the
> future it becomes possible to have large parts of the JVM w
: John Rose
Sent: Thursday, November 19, 2015 05:45
To: David Holmes
Cc: OpenJDK Dev list
Subject: Re: Proposed API for JEP 259: Stack-Walking API
On Nov 18, 2015, at 6:32 PM, David Holmes <david.hol...@oracle.com> wrote:
>
>>>
>>> Looks good to me too if IllegalSta
le.com>
> Cc: "Mandy Chung" <mandy.ch...@oracle.com>, "OpenJDK Dev list"
> <core-libs-dev@openjdk.java.net>
> Envoyé: Mercredi 18 Novembre 2015 13:26:32
> Objet: Re: Proposed API for JEP 259: Stack-Walking API
>
>
>
> On 11/18/2015 12:2
> On Nov 18, 2015, at 1:11 AM, Peter Levart wrote:
>
> Hi Mandy,
>
> Just one nit...
>
> On 11/17/2015 11:59 PM, Mandy Chung wrote:
>>> Apart from the orphaned paragraph fragment at the end looks good to me, but
>>> that’s just my opinion.
>> I caught that that after
This is the update javadoc of getCallerClass. Thanks for all the feedback and
suggestion. I have to finalize this API today to make the FC date :)
/**
* Gets the {@code Class} object of the caller invoking the method
* that calls this {@code getCallerClass} method.
*
* Reflection
Chung" <mandy.ch...@oracle.com>, "OpenJDK Dev list"
>> <core-libs-dev@openjdk.java.net>
>> Envoyé: Mercredi 18 Novembre 2015 13:26:32
>> Objet: Re: Proposed API for JEP 259: Stack-Walking API
>>
>>
>>
>> On 11/18/2015 12
> On Nov 17, 2015, at 2:09 PM, Peter Levart wrote:
>
> I think that calling getCallerClass() from implementation of Runnable::run
> should expect it to return a system class. It may be Thread.class or
> ThreadPoolExecutor$Worker.class or anything actually.
>
I’m now
) {}).start();
).
Apart from the orphaned paragraph fragment at the end looks good to me, but
that’s just my opinion.
Sent from Mail for Windows 10
From: Mandy Chung
Sent: Tuesday, November 17, 2015 23:43
To: Peter Levart
Cc: OpenJDK Dev list
Subject: Re: Proposed API for JEP 259: Stack
Hi Mandy,
Just one nit...
On 11/17/2015 11:59 PM, Mandy Chung wrote:
Apart from the orphaned paragraph fragment at the end looks good to me, but
that’s just my opinion.
I caught that that after I clicked sent :(
This is a better version.
/**
* Gets the {@code Class} object of the caller
dev@openjdk.java.net>
Envoyé: Mercredi 18 Novembre 2015 08:58:56
Objet: Re: Proposed API for JEP 259: Stack-Walking API
On 18/11/2015 8:42 AM, Mandy Chung wrote:
On Nov 17, 2015, at 2:09 PM, Peter Levart <peter.lev...@gmail.com> wrote:
I think that calling getCallerClass() from imp
On 18/11/2015 8:42 AM, Mandy Chung wrote:
On Nov 17, 2015, at 2:09 PM, Peter Levart wrote:
I think that calling getCallerClass() from implementation of Runnable::run
should expect it to return a system class. It may be Thread.class or
ThreadPoolExecutor$Worker.class
- Mail original -
> De: "David Holmes" <david.hol...@oracle.com>
> À: "Mandy Chung" <mandy.ch...@oracle.com>, "Peter Levart"
> <peter.lev...@gmail.com>
> Cc: "OpenJDK Dev list" <core-libs-dev@openjdk.java.net>
&g
il.com>
Cc: "OpenJDK Dev list" <core-libs-dev@openjdk.java.net>
Envoyé: Mercredi 18 Novembre 2015 08:58:56
Objet: Re: Proposed API for JEP 259: Stack-Walking API
On 18/11/2015 8:42 AM, Mandy Chung wrote:
On Nov 17, 2015, at 2:09 PM, Peter Levart <peter.lev...@gmail.com>
wrote:
I th
> On Nov 18, 2015, at 6:32 PM, David Holmes wrote:
>
>
> I agree with Remi. "state" doesn't have to mean fields - there are numerous
> existing examples in the JDK. Calling a method in a context that is invalid
> is an illegal state to me. IllegalThreadStateException
On Nov 18, 2015, at 6:32 PM, David Holmes wrote:
>
>>>
>>> Looks good to me too if IllegalStateException is used instead of
>>> UnsupportedOperationException.
>>> UnsuppportedOperationException is used when the operation is not
>>> available, here, the same code can
> Apart from the orphaned paragraph fragment at the end looks good to me, but
> that’s just my opinion.
I caught that that after I clicked sent :(
This is a better version.
/**
* Gets the {@code Class} object of the caller invoking the method
* that calls this {@code getCallerClass} method.
On 11/17/2015 09:50 PM, Mandy Chung wrote:
On Nov 17, 2015, at 11:54 AM, Peter Levart wrote:
On 11/16/2015 08:16 PM, Mandy Chung wrote:
On Nov 15, 2015, at 10:59 AM, Peter Levart
wrote:
OTOH in the described cases, a caller of
On 11/16/2015 08:16 PM, Mandy Chung wrote:
On Nov 15, 2015, at 10:59 AM, Peter Levart wrote:
OTOH in the described cases, a caller of walker.getCallerClass() is actually expecting to be called
by a Java method, right? So what would it be if such "caller-sensitive"
> On Nov 17, 2015, at 11:54 AM, Peter Levart wrote:
>
>
>
> On 11/16/2015 08:16 PM, Mandy Chung wrote:
>>> On Nov 15, 2015, at 10:59 AM, Peter Levart
>>> wrote:
>>>
>>> OTOH in the described cases, a caller of walker.getCallerClass() is
>>>
> On Nov 17, 2015, at 1:13 PM, Peter Levart wrote:
>
> But (as described in my other message), Runnable::run is not an entry point.
> Thread::run is. And Thread::run (a Java method) delegates to Runnable::run.
> So in this case Thread.class will be returned as a normal
On 11/17/2015 10:13 PM, Peter Levart wrote:
I will keep returning the thread’s entry point case to return the class of the
runnable instead of returning Thread.class.
But (as described in my other message), Runnable::run is not an entry
point. Thread::run is. And Thread::run (a Java
> On Nov 15, 2015, at 10:59 AM, Peter Levart wrote:
>
> OTOH in the described cases, a caller of walker.getCallerClass() is actually
> expecting to be called by a Java method, right? So what would it be if such
> "caller-sensitive" method demanded to be called by a
about the calling context in effect at the time it is called.
>
>
>
> Sent from Mail for Windows 10
>
>
>
> From: Peter Levart
> Sent: Sunday, November 15, 2015 20:15
> To: Timo Kinnunen;David M. Lloyd;core-libs-dev@openjdk.java.net
> Subject: Re: Proposed API f
Hi Mandy,
On 11/15/2015 12:52 AM, Mandy Chung wrote:
I have been thinking what the users would do when there is no caller.
The JDK use of getCallerClass are to:
1. find the caller's class loader for class loader hierarchy check
2. find the caller’s class loader to load something on behalf of
ker::getCallerClass and further suggests
StackWalker::getCaller should be available for clients as well.
Sent from Mail for Windows 10
From: David M. Lloyd
Sent: Saturday, November 14, 2015 16:02
To: core-libs-dev@openjdk.java.net
Subject: Re: Proposed API for JEP 259: Stack-Walking API
On 11
From: Peter Levart
Sent: Sunday, November 15, 2015 20:15
To: Timo Kinnunen;David M. Lloyd;core-libs-dev@openjdk.java.net
Subject: Re: Proposed API for JEP 259: Stack-Walking API
On 11/15/2015 05:53 PM, Timo Kinnunen wrote:
To be pedantic, there is always a caller, but not every caller
Hi again,
On 11/15/2015 11:12 AM, Peter Levart wrote:
Hi Mandy,
On 11/15/2015 12:52 AM, Mandy Chung wrote:
I have been thinking what the users would do when there is no caller.
The JDK use of getCallerClass are to:
1. find the caller's class loader for class loader hierarchy check
2. find
row an exception in such situations.
Regards, Peter
Sent from Mail for Windows 10
From: David M. Lloyd
Sent: Saturday, November 14, 2015 16:02
To: core-libs-dev@openjdk.java.net
Subject: Re: Proposed API for JEP 259: Stack-Walking API
On 11/13/2015 06:07 PM, Brian Goetz wrote:
I considered Optional&l
On 11/13/2015 06:07 PM, Brian Goetz wrote:
I considered Optional. I believe it is rare to have a JNI
attached thread calling StackWalker::getCallerClass from native. Most
common cases will find a caller class. Returning an Optional will
force most common uses to handle the case if it’s
> On Nov 14, 2015, at 7:01 AM, David M. Lloyd wrote:
>
> On 11/13/2015 06:07 PM, Brian Goetz wrote:
>>> I considered Optional. I believe it is rare to have a JNI
>>> attached thread calling StackWalker::getCallerClass from native. Most
>>> common cases will find
I considered Optional. I believe it is rare to have a JNI attached
thread calling StackWalker::getCallerClass from native. Most common cases will find a
caller class. Returning an Optional will force most common uses to handle the case if
it’s absent. It’s a tradeoff that I think
> On Nov 10, 2015, at 1:07 AM, Peter Levart wrote:
>
> Hi Mandy,
>
> On 11/10/2015 03:20 AM, Mandy Chung wrote:
>> I have updated the APIs to incorporate all the feedback. Thank you all.
>> Let me know if I miss any.
>>
>> Summary:
>> 1. Change to use wildcard
Hi Mandy,
On 11/10/2015 03:20 AM, Mandy Chung wrote:
I have updated the APIs to incorporate all the feedback. Thank you all. Let
me know if I miss any.
Summary:
1. Change to use wildcard walk(Function, ? extends
T> function)
2. Removed the walk method taking IntUnaryOperator
I have updated the APIs to incorporate all the feedback. Thank you all. Let
me know if I miss any.
Summary:
1. Change to use wildcard walk(Function, ? extends
T> function)
2. Removed the walk method taking IntUnaryOperator batchSizeMapper argument
3. Add the new static factory method to
Hi Mandy,
My recommendation is to go with with PECS whenever possible, even if some
aspects are redundant.
Paul.
> On 5 Nov 2015, at 22:48, Mandy Chung wrote:
>
>
>> On Nov 4, 2015, at 5:00 AM, Remi Forax wrote:
>>
>>>
>>> Good point. Damn, i
On 11/04/2015 07:15 PM, Mandy Chung wrote:
[...]
For short-circuiting, I also think it’s reasonable to expect the user know how
many remaining frames it expects to traverse and it may not need to increase
the batch size i.e. it might not need to update the remainingNeeded over time.
The user
- Mail original -
> De: "Mandy Chung" <mandy.ch...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: "Paul Sandoz" <paul.san...@oracle.com>, core-libs-dev@openjdk.java.net
> Envoyé: Jeudi 5 Novembre 2015 22:48
> On Nov 4, 2015, at 5:00 AM, Remi Forax wrote:
>
>>
>> Good point. Damn, i don’t like wildcards :-)
>>
>> The following works fine:
>>
>> static Function counter() {
>> return Stream::count;
>> }
>>
>> But there could also cases where one is stuck
Cimadamore
Sent: Thursday, November 5, 2015 23:34
To: Timo Kinnunen;Remi Forax;Paul Sandoz
Cc: core-libs-dev@openjdk.java.net
Subject: Re: Proposed API for JEP 259: Stack-Walking API
On 04/11/15 11:19, Timo Kinnunen wrote:
> Hi,
>
> I tested your version of the wildcard coun
> On Nov 5, 2015, at 2:43 PM, David M. Lloyd wrote:
>
> On 11/04/2015 07:15 PM, Mandy Chung wrote:
>> [...]
>> For short-circuiting, I also think it’s reasonable to expect the user know
>> how many remaining frames it expects to traverse and it may not need to
>>
n Stream::count;
}
That one is another such example, a bit surprisingly.
So this means you can’t support all clients at the same time.
Sent from Mail for Windows 10
From: Mandy Chung
Sent: Thursday, November 5, 2015 22:49
To: Remi Forax
Cc: core-libs-dev@openjdk.java.net
Subject:
me applicability.
Maurizio
Sent from Mail for Windows 10
From: Remi Forax
Sent: Wednesday, November 4, 2015 10:04
To: Paul Sandoz
Cc: core-libs-dev@openjdk.java.net
Subject: Re: Proposed API for JEP 259: Stack-Walking API
Hi Paul,
The use of BaseStream was just an example, here is an
Sorry for the delay getting back to this.
> On Nov 2, 2015, at 4:46 AM, David M. Lloyd wrote:
>
> I think there are two problems with the current approach:
>
> 1. The function for getting the next batch size is not coupled to the
> function actually doing the work.
> On Nov 4, 2015, at 12:21 AM, Peter Levart wrote:
>
>>
>> I was not thinking of calling StackWalker::getCallerClass from native, but
>> calling some method from native, which then calls
>> StackWalker::getCallerClass. The method itself can not anticipate how it
>>
m: Remi Forax
Sent: Wednesday, November 4, 2015 10:04
To: Paul Sandoz
Cc: core-libs-dev@openjdk.java.net
Subject: Re: Proposed API for JEP 259: Stack-Walking API
Hi Paul,
The use of BaseStream was just an example, here is another one that works only
if the function first parameter type is declare
- Mail original -
> De: "Paul Sandoz" <paul.san...@oracle.com>
> Cc: core-libs-dev@openjdk.java.net
> Envoyé: Mercredi 4 Novembre 2015 10:57:41
> Objet: Re: Proposed API for JEP 259: Stack-Walking API
>
>
> > On 4 Nov 2015, at 10:03, Remi Forax <
> On 4 Nov 2015, at 04:50, Mandy Chung wrote:
>
>
>> On Nov 3, 2015, at 3:28 AM, Paul Sandoz wrote:
>>
>> Hi Mandy,
>>
>> This is very nice work.
>>
>> Comments below, mostly minor stuff.
>>
>
> Thanks for the review.
>
> I fixed most of
On 11/04/2015 09:06 AM, Peter Levart wrote:
What would it be if getCallerClass() returned just
Optional and was left to the user to decide what to do in
corner cases when there is no Java caller?
I considered Optional. I believe it is rare to have a JNI
attached thread
On 11/03/2015 10:33 PM, Mandy Chung wrote:
On Nov 3, 2015, at 4:45 AM, Peter Levart wrote:
Hi Mandy,
Great API.
One thing I noticed is method StackWalker.getCallerClass() which is described
as equivalent to the following:
walk((s) ->
> On 4 Nov 2015, at 10:03, Remi Forax wrote:
>
> Hi Paul,
>
> The use of BaseStream was just an example, here is another one that works
> only if the function first parameter type is declared as '? super
> Stream'.
>
> static Function counter() {
>
ounter());
regards,
Rémi
- Mail original -
> De: "Paul Sandoz" <paul.san...@oracle.com>
> Cc: core-libs-dev@openjdk.java.net
> Envoyé: Lundi 2 Novembre 2015 13:44:24
> Objet: Re: Proposed API for JEP 259: Stack-Walking API
>
> I agree with Maurizio, the
On 04/11/15 02:59, Mandy Chung wrote:
>
>> On Nov 3, 2015, at 2:08 PM, David M. Lloyd
>> wrote:
>>
>>> I considered Optional. I believe it is rare to have a
>>> JNI attached thread calling StackWalker::getCallerClass from
>>> native. Most common cases will find a
Hi Mandy,
This is very nice work.
Comments below, mostly minor stuff.
PlatformLogger.java
(and similar comments for duplicated code in LogRecord.java)
—
542 static final StackWalker stackWalker;
Use capitals for static variable.
556 private boolean
Hi Mandy,
Great API.
One thing I noticed is method StackWalker.getCallerClass() which is
described as equivalent to the following:
walk((s) -> s.map(StackFrame::getDeclaringClass)
.skip(2)
.findFirst()).orElse(Thread.currentThread().getClass());
... the .orElse is
On 11/03/2015 03:33 PM, Mandy Chung wrote:
On Nov 3, 2015, at 4:45 AM, Peter Levart wrote:
Hi Mandy,
Great API.
One thing I noticed is method StackWalker.getCallerClass() which is described
as equivalent to the following:
walk((s) ->
> On Nov 3, 2015, at 4:45 AM, Peter Levart wrote:
>
> Hi Mandy,
>
> Great API.
>
> One thing I noticed is method StackWalker.getCallerClass() which is described
> as equivalent to the following:
>
> walk((s) -> s.map(StackFrame::getDeclaringClass)
>
> On Nov 3, 2015, at 2:08 PM, David M. Lloyd wrote:
>
>> I considered Optional. I believe it is rare to have a JNI attached
>> thread calling StackWalker::getCallerClass from native. Most common cases
>> will find a caller class. Returning an Optional will
> On Nov 3, 2015, at 3:28 AM, Paul Sandoz wrote:
>
> Hi Mandy,
>
> This is very nice work.
>
> Comments below, mostly minor stuff.
>
Thanks for the review.
I fixed most of the comments below. One question:
Is the name “StackStream" inappropriate and its subtypes?
Hi Peter,
You also get Thread.currentThread().getClass() if you call
StackWalker.getCallerClass() from main().
Because who is the caller of main()?
cheers,
-- daniel
On 03/11/15 13:45, Peter Levart wrote:
Hi Mandy,
Great API.
One thing I noticed is method StackWalker.getCallerClass()
On 11/03/2015 02:20 PM, Daniel Fuchs wrote:
Hi Peter,
You also get Thread.currentThread().getClass() if you call
StackWalker.getCallerClass() from main().
Because who is the caller of main()?
I would say there is no Java caller in that case and return
Optional.empty().
No Java caller
I also agree - when an object type "passes through" a method, it's
usually best to use an invariant type variable.
On 11/02/2015 06:44 AM, Paul Sandoz wrote:
I agree with Maurizio, the first signature is good enough.
One could argue that it might be better to apply PECS since it would
oun...@openjdk.java.net> on behalf of Mandy
Chung <mandy.ch...@oracle.com>
Sent: Friday, October 30, 2015 2:04 PM
To: core-libs-dev
Subject: Proposed API for JEP 259: Stack-Walking API
JEP 259: http://openjdk.java.net/jeps/259
Javadoc for the proposed StackWalker API:
http://cr.openjdk.java
it any future
optimization/performance improvement?
Mandy
> Regards,
> Jeroen
>
>> -Original Message-
>> From: core-libs-dev [mailto:core-libs-dev-boun...@openjdk.java.net] On
>> Behalf Of Mandy Chung
>> Sent: Friday, October 30, 2015 20:05
>> To: core-libs-de
nday, November 1, 2015 05:36
To: Timo Kinnunen
Cc: Remi Forax;core-libs-dev@openjdk.java.net
Subject: Re: Proposed API for JEP 259: Stack-Walking API
In fact, T walk(Function<Stream, T> function, …) - without ?
extends T change,
You can do:
Function<Stream, String> funct;
I agree with Maurizio, the first signature is good enough.
One could argue that it might be better to apply PECS since it would encourage
more consistent usage when it is actually required as all too often it’s easy
to forget, and then too late to change. However, i don’t want to encourage the
On 10/30/2015 11:24 PM, Mandy Chung wrote:
On Oct 30, 2015, at 3:38 PM, David M. Lloyd wrote:
(that's what I was looking for before), or maybe even ToIntFunction where X is
something that might inform the next batch size based on the work that has already been
done -
the actual results match what we expected?
TIA!
Sent from Mail for Windows 10
From: Mandy Chung
Sent: Sunday, November 1, 2015 05:36
To: Timo Kinnunen
Cc: Remi Forax;core-libs-dev@openjdk.java.net
Subject: Re: Proposed API for JEP 259: Stack-Walking API
In fact, T walk(Function<S
-dev <core-libs-dev@openjdk.java.net>
> Subject: Proposed API for JEP 259: Stack-Walking API
>
> JEP 259: http://openjdk.java.net/jeps/259
>
> Javadoc for the proposed StackWalker API:
>
> http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker
&
gt; Sent from Mail for Windows 10
>
>
>
> From: Mandy Chung
> Sent: Saturday, October 31, 2015 23:59
> To: Remi Forax
> Cc: core-libs-dev@openjdk.java.net
> Subject: Re: Proposed API for JEP 259: Stack-Walking API
>
>
>
> > On Oct 31, 2015, at 1
Hi Mandy,
- Mail original -
> De: "Mandy Chung" <mandy.ch...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>, "David M. Lloyd" <david.ll...@redhat.com>
> Cc: core-libs-dev@openjdk.java.net
> Envoyé: Vendredi 30 Octobre 2015 2
Hi Mandy, hi all,
- Mail original -
> De: "Mandy Chung" <mandy.ch...@oracle.com>
> À: "David M. Lloyd" <david.ll...@redhat.com>
> Cc: core-libs-dev@openjdk.java.net
> Envoyé: Vendredi 30 Octobre 2015 21:39:38
> Objet: Re: Proposed API for
? extends T>
function, IntUnaryOperator batchSizeMapper)
cheers,
Rémi
- Mail original -
> De: fo...@univ-mlv.fr
> À: "Mandy Chung" <mandy.ch...@oracle.com>
> Cc: core-libs-dev@openjdk.java.net
> Envoyé: Samedi 31 Octobre 2015 19:06:11
> Objet: Re: Propo
On Oct 31, 2015, at 12:51 PM, John Rose wrote:
>
> modules, true polymorphism, value types, native interconnect
P.S. Project refs: Jigsaw, Valhalla (List), Valhalla, Panama.
-
> De: "Peter Levart" <peter.lev...@gmail.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>, "Mandy Chung" <mandy.ch...@oracle.com>
> Cc: core-libs-dev@openjdk.java.net
> Envoyé: Samedi 31 Octobre 2015 20:23:14
> Objet: Re: Proposed API
On Oct 31, 2015, at 11:50 AM, Remi Forax wrote:
>
> I think most of the runtime language developers, myself included will kill to
> have this feature included into the JDK.
> There are several features of dynamic languages that are currently hard to
> implement like type
On 10/31/2015 07:29 PM, Remi Forax wrote:
also instead of Optional.orElse, orElseGet is better because it avoids to
evaluate
Thread.currentThread().getClass() if not necessary.
So the example should be:
walk(s -> s.map(StackFrame::getDeclaringClass)
- Mail original -
> De: "Mandy Chung" <mandy.ch...@oracle.com>
> À: "Remi Forax" <fo...@univ-mlv.fr>
> Cc: core-libs-dev@openjdk.java.net
> Envoyé: Samedi 31 Octobre 2015 23:59:01
> Objet: Re: Proposed API for JEP 259: Stack-Walking API
>
IntToIntFunction => IntUnaryOperator.
Ah that's the one! You know I think that this is more than once that
I looked for, and didn't find, that interface. Some kind of mental
blind spot I guess. :-)
We all look forward to when Valhalla will relegate all of these
hand-specialized
esult;
Isn’t “? extends T” pointless here?
Sent from Mail for Windows 10
From: Mandy Chung
Sent: Saturday, October 31, 2015 23:59
To: Remi Forax
Cc: core-libs-dev@openjdk.java.net
Subject: Re: Proposed API for JEP 259: Stack-Walking API
> On Oct 31, 2015, at 11:29 AM, Remi Forax &
On 10/30/2015 03:26 PM, Remi Forax wrote:
The batchSizeMapper should probably be something better than a
Function, no? All that boxing seems unnecessary... the
next best candidate I can see though is IntToLongFunction. I wonder why
we didn't do an IntToIntFunction in JSR 335.
ker is not configured with CLASS_REFERENCE.
- Mail original -
> De: "David M. Lloyd" <david.ll...@redhat.com>
> À: core-libs-dev@openjdk.java.net
> Envoyé: Vendredi 30 Octobre 2015 20:59:26
> Objet: Re: Proposed API for JEP 259: Stack-Walking API
>
> On 10/30/2015 02:
> On Oct 30, 2015, at 1:26 PM, Remi Forax wrote:
>
> In StackWalker.Option,
> i think that CLASS_REFERENCE can be renamed to KEEP_CLASS_REFERENCE, maybe ?
What about RETAIN_CLASS_REFERENCE?
I have updated the javadoc in place:
On 10/30/2015 03:39 PM, Mandy Chung wrote:
On Oct 30, 2015, at 12:59 PM, David M. Lloyd wrote:
Since this is very likely to be a one-implementation API, is there a reason to
have a separate WalkerOption interface and Option enum? Seems like you could
just skip the
> On Oct 30, 2015, at 3:38 PM, David M. Lloyd wrote:
>
> On 10/30/2015 03:39 PM, Mandy Chung wrote:
>>> On Oct 30, 2015, at 12:59 PM, David M. Lloyd wrote:
>>> Since this is very likely to be a one-implementation API, is there a reason
>>> to
> On Oct 30, 2015, at 12:59 PM, David M. Lloyd wrote:
>
> Clever/interesting way to prevent the stream from being used outside of the
> stack frame it is active in. I was trying to think of a way it could be
> subverted but I haven't come up with one yet.
That’s
> On Oct 30, 2015, at 1:26 PM, Remi Forax wrote:
>
> Hi Mandy, hi David, hi all,
> the API look gorgeous :)
>
Thank you.
> There are some missing wildcards in walk,
> T walk(Function, ? extends T>
> function, IntUnaryOperator batchSizeMapper)
>
> In StackWalker.Option,
On 10/30/2015 02:04 PM, Mandy Chung wrote:
JEP 259: http://openjdk.java.net/jeps/259
Javadoc for the proposed StackWalker API:
http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html
A simple way to walk the stack:
StackWalker walker = new
JEP 259: http://openjdk.java.net/jeps/259
Javadoc for the proposed StackWalker API:
http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html
A simple way to walk the stack:
StackWalker walker = new StackWalker(StackWalker.Option.CLASS_REFERENCE);
walker.walk((s)
89 matches
Mail list logo