Re: Proposed API for JEP 259: Stack-Walking API

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: > >>>

RE: Proposed API for JEP 259: Stack-Walking API

: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

RE: Proposed API for JEP 259: Stack-Walking API

: 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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

> 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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

> 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

RE: Proposed API for JEP 259: Stack-Walking API

) {}).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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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

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 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

Re: Proposed API for JEP 259: Stack-Walking API

- 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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

> 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

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 IllegalStateException is used instead of >>> UnsupportedOperationException. >>> UnsuppportedOperationException is used when the operation is not >>> available, here, the same code can

Re: Proposed API for JEP 259: Stack-Walking API

> 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.

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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"

Re: Proposed API for JEP 259: Stack-Walking API

> 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 >>>

Re: Proposed API for JEP 259: Stack-Walking API

> 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

Re: Proposed API for JEP 259: Stack-Walking API

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

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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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

RE: Proposed API for JEP 259: Stack-Walking API

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

RE: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

> 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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

> 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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

- 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

Re: Proposed API for JEP 259: Stack-Walking API

> 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

RE: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

> 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 >>

RE: Proposed API for JEP 259: Stack-Walking API

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:

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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.

Re: Proposed API for JEP 259: Stack-Walking API

> 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 >>

RE: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

- 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 <

Re: Proposed API for JEP 259: Stack-Walking API

> 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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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) ->

Re: Proposed API for JEP 259: Stack-Walking API

> 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() { >

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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) ->

Re: Proposed API for JEP 259: Stack-Walking API

> 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) >

Re: Proposed API for JEP 259: Stack-Walking API

> 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

Re: Proposed API for JEP 259: Stack-Walking API

> 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?

Re: Proposed API for JEP 259: Stack-Walking API

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()

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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;

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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 -

RE: Proposed API for JEP 259: Stack-Walking API

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

RE: Proposed API for JEP 259: Stack-Walking API

-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 &

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

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

Re: Proposed API for JEP 259: Stack-Walking API

? 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

Re: Proposed API for JEP 259: Stack-Walking API

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.

Re: Proposed API for JEP 259: Stack-Walking API

- > 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

Re: Proposed API for JEP 259: Stack-Walking 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

Re: Proposed API for JEP 259: Stack-Walking API

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)

Re: Proposed API for JEP 259: Stack-Walking API

- 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 >

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

RE: Proposed API for JEP 259: Stack-Walking API

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 &

Re: Proposed API for JEP 259: Stack-Walking API

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.

Re: Proposed API for JEP 259: Stack-Walking API

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:

Re: Proposed API for JEP 259: Stack-Walking API

> 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:

Re: Proposed API for JEP 259: Stack-Walking API

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

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

Re: Proposed API for JEP 259: Stack-Walking API

> 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

Re: Proposed API for JEP 259: Stack-Walking API

> 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,

Re: Proposed API for JEP 259: Stack-Walking API

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

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 the stack: StackWalker walker = new StackWalker(StackWalker.Option.CLASS_REFERENCE); walker.walk((s)