: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 writ
LinkId=550986> 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 wrote:
>
>>>
>>> Looks good to me
: 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 wrote:
>
>>>
>>> Looks good to me too if IllegalStateExcepti
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 work or not depending how it
> 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 would also work. But
> U
On 18/11/2015 10:26 PM, Peter Levart wrote:
On 11/18/2015 12:22 PM, Remi Forax wrote:
- Mail original -
De: "David Holmes"
À: "Mandy Chung" , "Peter Levart"
Cc: "OpenJDK Dev list"
Envoyé: Mercredi 18 Novembre 2015 08:58:56
Objet: Re: Propose
state seems natural
> to me.
>
> Rémi
>
> - Mail original -
>> De: "Peter Levart"
>> À: "Remi Forax" , "David Holmes"
>> Cc: "Mandy Chung" , "OpenJDK Dev list"
>>
>> Envoyé: Mercredi 18 No
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 frames,
> 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 I clicked sent :(
>>
>>
Envoyé: Mercredi 18 Novembre 2015 13:26:32
> Objet: Re: Proposed API for JEP 259: Stack-Walking API
>
>
>
> On 11/18/2015 12:22 PM, Remi Forax wrote:
> > - Mail original -
> >> De: "David Holmes"
> >> À: "Mandy Chung" , "
- Mail original -
> De: "David Holmes"
> À: "Mandy Chung" , "Peter Levart"
>
> Cc: "OpenJDK Dev list"
> Envoyé: Mercredi 18 Novembre 2015 08:58:56
> Objet: Re: Proposed API for JEP 259: Stack-Walking API
>
> On 18/11/20
On 11/18/2015 12:22 PM, Remi Forax wrote:
- Mail original -
De: "David Holmes"
À: "Mandy Chung" , "Peter Levart"
Cc: "OpenJDK Dev list"
Envoyé: Mercredi 18 Novembre 2015 08:58:56
Objet: Re: Proposed API for JEP 259: Stack-Walking API
On 18
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 i
) {}).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
> 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 convinced that it’s not
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 or anything actually.
> 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 caller (which it
> real
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 walker.getCallerClass() is actually expecting to be called
> 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 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 metho
> 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
>>> actually expecting to be called by a Java method,
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" method demanded
to be call
ffect 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 for JEP 259: Stack-Walking API
> 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 Java method and throw
> Ill
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 is
ch 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>. I belie
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 th
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
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 t
> 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 a caller class. Returning an
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 absent
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 it’s bett
> 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 walk(Function, ?
>> extends
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 batchSizeMapper
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 cre
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 don’t like wildcards :-)
>>>
>>> The followin
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 counter and it appears to be
> incompatible wi
ther 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: Re: Proposed API for JEP 259: Stack-Walking
> 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
>> increase the batch size i.e. i
n, T> function,
IntUnaryOperator sizing) {
and
T powerWalk(Function, ? extends T> function,
IntUnaryOperator sizing) {
Should result in having same applicability.
Maurizio
Sent from Mail for Windows 10
From: Remi Forax
Sent: Wednesday, November 4, 2015 10:04
To: Paul Sandoz
Cc: core-l
- Mail original -
> De: "Mandy Chung"
> À: "Remi Forax"
> Cc: "Paul Sandoz" , core-libs-dev@openjdk.java.net
> Envoyé: Jeudi 5 Novembre 2015 22:48:45
> Objet: Re: Proposed API for JEP 259: Stack-Walking API
>
>
> > On Nov 4,
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
> 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, Long> counter() {
>> return Stream::count;
>> }
>>
>> But there could also cases where one is stuck using a wildcard:
>>
>> Fu
> 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
>> will be called. Most metho
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. I think it is just as lik
- Mail original -
> De: "Paul Sandoz"
> 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 wrote:
> >
> > Hi
mismatch;
java.util.function.Function,java.lang.Long> cannot
be converted to
java.util.function.Function,T>)
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-Walkin
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 caller class. Returning
>>>
.walk(counter());
regards,
Rémi
- Mail original -
> De: "Paul Sandoz"
> 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 first signature is good enough.
>
> 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, Integer> counter() {
> return stream::count;
> }
>
> .
> 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 the comments below. One question:
>
> Is the na
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 calling StackWalker
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) -> s.map(StackFrame::getDeclaringClass)
> 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? I prefer StackStream
t
> 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 force most common
>> uses to han
> 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)
> .skip(2)
> .findFirst()).
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) -> s.map(StackFrame::getDeclaringClass)
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 mea
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() which
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 presumab
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 lookingForLogger
tober 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.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html
&g
n/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-dev
>&
Thanks for the feedback, Paul and Maurizio, that’s very helpful.
I slightly opt for consistency with other areas and go with #2.
Mandy
> On Nov 2, 2015, at 4:44 AM, Paul Sandoz wrote:
>
> I agree with Maurizio, the first signature is good enough.
>
> One could argue that it might be better to
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.net/~mchung/jdk9/jep259/api/java/lang/StackWalker.html
A simple way to walk
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 encourag
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 - maybe even a Stream that
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
ply assign the value returned from walk to a CharSequence variable:
String result = sw.walk(funct, i -> i);
CharSequence chars = result;
Isn’t “? extends T” pointless here?
Sent from Mail for Windows 10
From: Mandy Chung
Sent: Saturda
ail 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, T> function, …) - without ?
extends T change,
You can do:
Fu
-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.net/~mchung/jdk9/jep259/api/java/lang/StackWalker
> .html
>
> A simple way to wal
om: 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 wrote:
> >
> > Hi Mandy,
lt;
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 wrote:
>
&
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 interf
- Mail original -
> De: "Mandy Chung"
> À: "Remi Forax"
> 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
>
>
> > On Oct 31, 2015, at 11:29 AM, Remi Fo
> On Oct 31, 2015, at 11:29 AM, Remi Forax wrote:
>
> Hi Mandy,
> I've crawled the code and the documentation again.
>
> In the doc and in the code, a lambda with one parameter doesn't require
> parenthesis around the parameter,
> (s) -> s.doSomething()
> should be
> s -> s.doSomething().
>
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.
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)
.findFirst()).orEl
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 specialization, stack r
l original -
> De: "Peter Levart"
> À: "Remi Forax" , "Mandy Chung"
> Cc: core-libs-dev@openjdk.java.net
> Envoyé: Samedi 31 Octobre 2015 20:23:14
> Objet: Re: Proposed API for JEP 259: Stack-Walking API
> On 10/31/2015 07:29 PM, Remi Forax
nature of walk() is:
T walk(Function, ? extends T>
function, IntUnaryOperator batchSizeMapper)
cheers,
Rémi
- Mail original -
> De: fo...@univ-mlv.fr
> À: "Mandy Chung"
> Cc: core-libs-dev@openjdk.java.net
> Envoyé: Samedi 31 Octobre 2015 19:06:11
> Objet
Hi Mandy, hi all,
- Mail original -
> De: "Mandy Chung"
> À: "David M. Lloyd"
> Cc: core-libs-dev@openjdk.java.net
> Envoyé: Vendredi 30 Octobre 2015 21:39:38
> Objet: Re: Proposed API for JEP 259: Stack-Walking API
>
>
> > On Oct 3
Hi Mandy,
- Mail original -
> De: "Mandy Chung"
> À: "Remi Forax" , "David M. Lloyd"
> Cc: core-libs-dev@openjdk.java.net
> Envoyé: Vendredi 30 Octobre 2015 23:35:02
> Objet: Re: Proposed API for JEP 259: Stack-Walking API
>
>
> 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 have a separate WalkerOption interface and Option e
> 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:
http://cr.openjdk.java.net/~mchung/jdk9/jep259/api/java/lang/Stac
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 interface.
Locals and oper
r is not configured with CLASS_REFERENCE.
- Mail original -
> De: "David M. Lloyd"
> À: 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:04 PM, Mandy Chung wrote:
&
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 StackWalker(StackWalke
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. Or maybe the stre
> 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,
> i think that CLAS
> 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 John’s suggestion (John alway
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) ->
92 matches
Mail list logo
