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

Hi Mandy, I like the API shape and this capability is very much needed. Thanks! It does bring something related to mind and that is that the current Java ecosystem is already very dependent on accurate stack frames (i.e. not removing them when inlining) and with this API this will probably only

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

In fact, T walk(Function, T> function, …) - without ? extends T change, You can do: Function, String> funct; CharSequence chars = sw.walk(funct, i -> i); I think it’s right to declare the return type of the function is "? extends T”. Mandy > On Oct 31, 2015, at 5:01 PM, Timo Kinnun

Re: Optional.or() doesn't use a wildcard in its signature

Hi Vitaly, Exactly, I was just trying to point out the method signature seems broken anyway. Regards, Michael On 31 Oct 2015 11:59, "Vitaly Davidovich" wrote: > This would require Supplier>, not Supplier Optional>. > > sent from my phone > On Oct 31, 2015 2:49 PM, "Michael Nascimento" wrote: >

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

Hi, Regarding “ I was pondering it and that’s why not changed in the last update. I agree with the upper bounded wildcard "? extends T” for the return type of the function. “ How does changing the type from “T” to “? extends T” aid the method caller in any way? If the caller has a Function

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 interf

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

- 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 Forax wrote: > > > > Hi Mandy, > > I've crawled th

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

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

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Hi, And, going back nearly to the beginning of the thread, some folks are familiar with T firstNonNull(T, T) proposed from Guava. But since the exercise was turned into simplify: (x != null) ? x : requireNonNull(y); My favorite at this point is to identify the thread as a failed attempt

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

OK, it's Halloween, so a certain amount of bikeshed vandalism might be allowable. I will to select my spray-paint color from the following paint-store aisle: http://www.thesaurus.com/browse/deter There's something in there to charm everyone. Personally,

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

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

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

It's hard to escape bikeshedding, everyone's subconsciously favorite pastime. :) To me, checkNull still means there's an error path somewhere there (I've seen plenty of internal validation/util APIs where check methods throw if arg is null). To me, we're saying "here's a method that returns defau

Re: Optional.or() doesn't use a wildcard in its signature

This would require Supplier>, not Supplier>. sent from my phone On Oct 31, 2015 2:49 PM, "Michael Nascimento" wrote: > If this instance is an Optional , passing an > Optional will fail to compile. > > Regards, > Michael > On 31 Oct 2015 11:21, "Stefan Zobel" wrote: > > > 2015-10-31 19:11 GMT+0

Re: Optional.or() doesn't use a wildcard in its signature

Hum, it's quite embarrassing, you're right :) In fact, it's more than that because i now remember that Paul already answer that to me :( Thanks, Stefan. (I like your email address BTW) - Mail original - > De: "Stefan Zobel" > À: "core-libs-dev@openjdk.java.net Libs" > Envoyé: Samedi 3

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

How about Objects.ifNull? Short and sweet. I don't like requireXXX for this semantic either. sent from my phone On Oct 31, 2015 3:45 PM, "John Rose" wrote: > On Oct 31, 2015, at 4:17 AM, Remi Forax wrote: > > > > Hi John, > > I think there is a good reason to not reuse/enhance the requireNonNu

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 specialization, stack r

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On Oct 31, 2015, at 4:17 AM, Remi Forax wrote: > > Hi John, > I think there is a good reason to not reuse/enhance the requireNonNull prefix, > requireNonNull here is used to check a precondition or an invariant (a > contract), hence a name that starts with 'require' like in Eiffel. > (BTW re-rea

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

You're right, the JVM never stops to amaze me ! It's not that hard to believe, Thread.currentThread and Object.getClass() are both intrinsics and the current thread pointer is stored at the bottom (top) of the stack and getClass is just an indirection. thanks, Rémi - Mail original --

Re: Optional.or() doesn't use a wildcard in its signature

If this instance is an Optional , passing an Optional will fail to compile. Regards, Michael On 31 Oct 2015 11:21, "Stefan Zobel" wrote: > 2015-10-31 19:11 GMT+01:00 Remi Forax : > > > Hi all, hi Paul, > > > > I've just seen that Optional.or is declared as > > public Optional or(Supplier> sup

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

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(). In the doc of StackWalker, in the first example, the local variable

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

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 30, 2015, at 12:59 PM, David M. Lloyd > > wrote: > >

Re: Optional.or() doesn't use a wildcard in its signature

2015-10-31 19:11 GMT+01:00 Remi Forax : > Hi all, hi Paul, > > I've just seen that Optional.or is declared as > public Optional or(Supplier> supplier) { > instead of > public Optional or(Supplier> supplier) { > > regards, > Rémi > I don't get it. Optional is final anyway. Can you explain? T

Optional.or() doesn't use a wildcard in its signature

Hi all, hi Paul, I've just seen that Optional.or is declared as public Optional or(Supplier> supplier) { instead of public Optional or(Supplier> supplier) { regards, Rémi

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

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 1:26 PM, Remi Forax wrote: > > >

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

Hi John, I think there is a good reason to not reuse/enhance the requireNonNull prefix, requireNonNull here is used to check a precondition or an invariant (a contract), hence a name that starts with 'require' like in Eiffel. (BTW re-reading this thread, Brian already said that) requireNonNullEls

Re: RFR 9: 8138963 : java.lang.Objects new method to default to non-null

On Oct 30, 2015, at 12:07 PM, Roger Riggs wrote: > > The longer names disambiguate adequately but add to the bulk of the code. > I see maturing systems end up being weighed down by the seemingly necessary > qualification. I agree with your statement of the problem, but (personally) am less repu