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

I’m not quite sure I follow you, so my apologies if I misunderstood you. What I’m trying to point out is that changing the type from “T” to “? extends T” doesn’t add any expressiveness in this method. These two signatures are both equally expressive for users of this API: public T

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

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

2015-11-01 1:12 GMT+01:00 Michael Nascimento : > Hi Vitaly, > > Exactly, I was just trying to point out the method signature seems broken > anyway. > > Regards, > Michael Hi Michael, I don't think the signature is broken. An Optional is not a subtype of Optional. So even if

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

2015-11-01 15:41 GMT+01:00 Vitaly Davidovich : > One could argue that this is perfectly sound to do given Optional is > readonly, we just can't express this variance cleanly in java (i.e. without > upcast). > Sure, as in Scala's Option[+A]. I should have said "... from a

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

2015-11-01 1:12 GMT+01:00 Michael Nascimento : > Hi Vitaly, > > Exactly, I was just trying to point out the method signature seems broken > anyway. > Rethinking it, I believe you are right. public Optional or(Supplier supplier) would be more general and still be

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

One could argue that this is perfectly sound to do given Optional is readonly, we just can't express this variance cleanly in java (i.e. without upcast). sent from my phone On Nov 1, 2015 7:31 AM, "Stefan Zobel" wrote: > 2015-11-01 1:12 GMT+01:00 Michael Nascimento

Re: [9] RFR 8141082: Add java/nio/Buffer/Basic.java to ProblemList.txt for 64-bit Linux

On 30/10/2015 19:39, joe darcy wrote: Hi Brian, Looks fine. (I don't see existing uses of the exact clauses "linux-amd64" and "linux-x64" in the problem list, but if you've verified those clauses work as expected I think is is good to go back.) This is core functionality so if this test

Re: RFR: String Density/Compact String JEP 254 (update)

On 11/1/15 10:18 AM, Alan Bateman wrote: On 30/10/2015 21:30, Xueming Shen wrote: Hi, Thanks for the comments/suggestions. Here are the updated webrevs with minor changes here and there based on the feedback. I spent time going through the changes in jdk repo and it looks very good. One

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

Hi Chris, hotspot and jdk changes look fine to me. Thanks, David On 2/11/2015 9:56 AM, Chris Hegarty wrote: In line with the intended location for other VM annotations, see 8138732 [1], @sun.misc.Contended should be moved to the jdk.internal.vm.annotation package.

Re: RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

> On 2 Nov 2015, at 12:54 a.m., David Holmes wrote: > > Hi Chris, > > hotspot and jdk changes look fine to me. Thanks for looking at this David. -Chris. > Thanks, > David > >> On 2/11/2015 9:56 AM, Chris Hegarty wrote: >> In line with the intended location for

Re: RFR: String Density/Compact String JEP 254 (update)

On 30/10/2015 21:30, Xueming Shen wrote: Hi, Thanks for the comments/suggestions. Here are the updated webrevs with minor changes here and there based on the feedback. I spent time going through the changes in jdk repo and it looks very good. One thing that isn't clear to me is why

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

On 31 October 2015 at 20:29, Roger Riggs wrote: > 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 : >

RFR [9] 8140687: Move @Contended to the jdk.internal.vm.annotation package

In line with the intended location for other VM annotations, see 8138732 [1], @sun.misc.Contended should be moved to the jdk.internal.vm.annotation package. http://cr.openjdk.java.net/~chegar/8140687/00/ -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8138732