Re: RFR(s): 8132800: clarify stream package documentation regarding sequential vs parallel modes

On 4 Aug 2015, at 01:09, Stuart Marks wrote: > Hi Tagir, > > Interesting issues. > > Regarding Stream.concat, it may be that, today, changes to the > sequential/parallel execution mode aren't propagated to the streams being > concatenated. The execution mode is propagated if either stream t

Re: RFR(s): 8132800: clarify stream package documentation regarding sequential vs parallel modes

On 31 Jul 2015, at 23:19, Stuart Marks wrote: > Hi all, > > The sequential() and parallel() methods on a stream set the execution mode > for the entire pipeline. Unfortunately this isn't particularly clear from the > documentation. This has been a recurring question. Please review this change

Re: RFR(s): 8132800: clarify stream package documentation regarding sequential vs parallel modes

On 4 Aug 2015, at 09:20, Paul Sandoz wrote: > > On 4 Aug 2015, at 01:09, Stuart Marks wrote: > >> Hi Tagir, >> >> Interesting issues. >> >> Regarding Stream.concat, it may be that, today, changes to the >> sequential/parallel executio

Re: Spliterator documentation on Priority(Blocking)Queue

Hi Tagir, Can you log an issue? Thanks, Paul. On 4 Aug 2015, at 06:47, Tagir Valeev wrote: > Hello! > > The PriorityQueue class iterator() returns elements in no particular order. > This is explicitly stated in JavaDoc for iterator() method [1] as well as > in class description [2]. However i

Re: Spliterator documentation on Priority(Blocking)Queue

On 4 Aug 2015, at 11:18, Tagir Valeev wrote: > Hello, Paul. > > I think I have no access rights to do it. You can do it here: http://bugreport.java.com/ (Write access to the Java Bug System requires OpenJDK author status.) > Should I have to sign an OCA for this? No. > I submitted the

Re: Spliterator documentation on Priority(Blocking)Queue

On 4 Aug 2015, at 13:42, Tagir Valeev wrote: > Hello! > > You can do it here: > > http://bugreport.java.com/ > > (Write access to the Java Bug System requires OpenJDK author status.) > > Thank you for the clarification. I filed the issue with Review ID: JI-9023040. > Thanks, and here it

Re: JDK 9 RFR of JDK-8132854: Adjust tier 1 and 2 definitions for nio-related intrinsics

+1 Paul. On 3 Aug 2015, at 05:19, joe darcy wrote: > Hello, > > With the fix for > >JDK-8076112: Add @HotSpotIntrinsicCandidate annotation to indicate > methods for which Java Runtime has intrinsics > > the sources for the libraries clearly indicate which methods might have > intri

Re: RFR(m) 2: 8072722: add stream support to Scanner

I've updated based on some discussions with Paul Sandoz. The updates since > the previous posting are 1) coordination of spec wording from Matcher; 2) > addition of ConcurrentModificationException; 3) updating tests to use the > streams testing framework; 4) some jav

Re: Collections.emptyList().spliterator() is not ORDERED

6 Sep 2015, at 12:21, Tagir F. Valeev wrote: > Hello! > > As Paul Sandoz pointed out in the "Custom spliterator for > Collections.nCopies(n, obj).stream()" discussion, the > List.spliterator() is specified to be ORDERED. However > Collections.emptyList().spliterator()

Re: Collections.emptyList().spliterator() is not ORDERED

On 7 Sep 2015, at 11:20, Tagir F. Valeev wrote: > PS> In this case we should fix Stream.concat to check if a > PS> spliterator reporting SIZED is empty, which will allow us to optimize the > concatenation [1]. > PS> [1] https://bugs.openjdk.java.net/browse/JDK-8022805 > > That would be even bett

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

HI Mike, This is fundamentally about *integrity* of the runtime. It follows there are security implications, but it’s still fundamentally an integrity issue and guarding an unsafe operation with a Security Manager is unfortunately an insufficient solution. Paul. On 7 Sep 2015, at 18:41, Mike

Re: Suggested fix for JDK-4724038 (Add unmap method to MappedByteBuffer)

On 8 Sep 2015, at 11:30, Andrew Haley wrote: > On 09/08/2015 09:58 AM, Paul Sandoz wrote: > >> This is fundamentally about *integrity* of the runtime. It follows >> there are security implications, but it’s still fundamentally an >> integrity issue and guarding an

Re: RFR(m) 2: 8072722: add stream support to Scanner

On 9 Sep 2015, at 02:53, Stuart Marks wrote: > I think the following covers all of the before, during, and after cases. > > << Scanning starts upon initiation of the terminal stream operation, using > the current state of this scanner. Subsequent calls to any methods on this > scanner other th

Re: RFR(m) 2: 8072722: add stream support to Scanner

On 9 Sep 2015, at 10:04, Chris Hegarty wrote: >> >> << After stream execution completes, this scanner is left in an >> indeterminate state and cannot be reused. >> > > I think this note is good, but the webrev/specdiff uses the term ‘pipeline > execution’. I think ‘stream execution’ is less li

Re: RFR(m) 2: 8072722: add stream support to Scanner

On 10 Sep 2015, at 00:07, Stuart Marks wrote: > > > On 9/9/15 2:32 PM, Stuart Marks wrote: >> I'll change the occurrences of "pipeline execution" to "stream pipeline >> execution" per your exchange with Paul. Looks like there are two such >> occurrences in each of the tokens() and findAll() me

Re: RFR(m) 2: 8072722: add stream support to Scanner

On 10 Sep 2015, at 22:22, Stuart Marks wrote: >>> It'd be better to initialize expectedCount to modCount in constrocutor? > > That's how I had it initially, but at Paul Sandoz' suggestion I delayed the > initialization to the first call to tryAdvance(). Yes

Re: Collections.emptyList().spliterator() is not ORDERED

On 7 Sep 2015, at 15:23, Paul Sandoz wrote: >> By the way, probably it's reasonable then for Arrays.asList to check >> the array length like: >> >> public static List asList(T... a) { >> if(a.length == 0) >> return Collections.empty

Re: RFR: 8136583: Core libraries should use blessed modifier order

On 16 Sep 2015, at 02:42, Martin Buchholz wrote: > Hi, Chris and Paul, > I'd like you to do a very boring code review. > > This change is entirely machine generated. (the script is more interesting) > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/blessed-modifier-order/blessed-modifier-or

Re: Modifier order for 'default' (was: RFR: 8136583: Core libraries should use blessed modifier order)

e the wrong mailinglist). > > Greetings > Bernd > -- > http://bernd.eckenfels.net > > -Original Message- > From: Martin Buchholz > To: core-libs-dev , Chris Hegarty > , Paul Sandoz > Sent: Mi., 16 Sep. 2015 2:54 > Subject: RFR: 8136583: Core librari

Re: [PATCH] Collectors.counting() does unnecessary boxing on every accumulation

Hi Tagir, Thanks, looks good. I created: https://bugs.openjdk.java.net/browse/JDK-8136686 and i also included an update to a test. Assuming no further review comments i will commit tomorrow. Paul. diff -r 4be07e0eb9b6 test/java/util/stream/test/org/openjdk/tests/java/util/stream/CountTest

RFR 8135248: Add utility methods to check indexes and ranges

Hi, Please review the following which adds methods to Arrays to check indexes and ranges: https://bugs.openjdk.java.net/browse/JDK-8135248 http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8135248-array-check-index-range/webrev/ The original motivation was an intrinsic method, Arrays.checkIndex

Re: RFR 8135248: Add utility methods to check indexes and ranges

On 21 Sep 2015, at 15:52, Stephen Colebourne wrote: > While I think I understand the need for the lambda/exception interface > (backwards compatibility) it is definitely weird as a method > signature. Backwards compat has definitely influenced things, but the approach was also considered usefu

Re: RFR 8135248: Add utility methods to check indexes and ranges

On 21 Sep 2015, at 16:17, Roger Riggs wrote: > Hi Paul, > > java.util.Arrays.java: line 5236: new IndexOutOfBoundsException() > - It is always appreciated when debugging to be given a message with the > index that is out of range and the range expected. > Added: ? new IndexOutOfBoundsExcep

Re: RFR 8135248: Add utility methods to check indexes and ranges

On 21 Sep 2015, at 16:45, Remi Forax wrote: > I agree with Stephen. > > Calling the function interface with the name ...Exception seems very wrong to > me. > Agreed, need to think of a better name. One solution is to remove it all together :-) see below. > The convention of ArrayIOOBE or

Re: RFR 8135248: Add utility methods to check indexes and ranges

On 21 Sep 2015, at 18:11, Peter Levart wrote: >> I would be happy to sacrifice the use-case in AbstractStringBuilder for >> using BiFunction, and add appropriate >> constructors or factory methods on the common exception types for method ref >> usage. >> >> Paul. > > Don't forget that Abstrac

Re: RFR 8135248: Add utility methods to check indexes and ranges

Hi Peter, You can find some discussion in the comments of https://bugs.openjdk.java.net/browse/JDK-8042997 which may help. I originally thought we could intrinsify unsigned comparison or have a boolean returning method. Over a series of discussions i was convinced by the current shape that mak

Re: RFR: jsr166 openjdk9 integration

Hi Martin, Thanks so much for doing this. Chris and I will cherry pick the appropriate API changes required for CCC, which i believe only apply to the first three sub-tasks of JDK-8132960 (Flow, CompletableFuture, and ForkJoin), but we should need to double check. We also need to be careful we

Re: RFR 8135248: Add utility methods to check indexes and ranges

Hi Jeff, I did wonder about that when i saw that code too. Without looking at generated machine code i do not know. Paul. On 21 Sep 2015, at 20:12, Jeff Hain wrote: > > Hi. > > > > In your webrev: > > + if ((length | fromIndex | size) < 0 || size > length - fromIndex) > + throw outOfBo

Re: RFR 8135248: Add utility methods to check indexes and ranges

Hi Remi, On 22 Sep 2015, at 08:08, Remi Forax wrote: > Hi Paul, > to summarize, there are a lot of codes that do bound checking in the JDK that > report different kind of exceptions. > Yes, and I suspect it is a similar state of affairs for code outside of the JDK too. > A way to retrofit

Re: RFR 8135248: Add utility methods to check indexes and ranges

___ > From: core-libs-dev on behalf of > Paul Sandoz > Sent: Monday, September 21, 2015 8:42 AM > To: core-libs-dev > Subject: RFR 8135248: Add utility methods to check indexes and ranges > > Hi, > > Please review the following which adds methods to Arrays to chec

Re: RFR 8135248: Add utility methods to check indexes and ranges

, rather than using a wildcard e.g. IDEs could use that information (although IntelliJ does not appear to do so at the moment). Paul. On 21 Sep 2015, at 15:42, Paul Sandoz wrote: > Hi, > > Please review the following which adds methods to Arrays to check indexes and > ranges:

Array equality, comparison and mismatch

Hi, Please review the following which adds methods to Arrays for performing equality, comparison and mismatch: https://bugs.openjdk.java.net/browse/JDK-8033148 http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8033148-Arrays-lexico-compare/webrev/ http://cr.openjdk.java.net/~psandoz/jdk9/JDK-

Re: RFR(S): 8136931: more fine-grained condition checking for BMH species creation

On 22 Sep 2015, at 19:10, Michael Haupt wrote: > Dear all, > > please review this change. > Issue: https://bugs.openjdk.java.net/browse/JDK-8136931 > Webrev: http://cr.openjdk.java.net/~mhaupt/8136931/webrev.00 > > This is actually a change to improve error reporting for identifying the > iss

Re: Array equality, comparison and mismatch

On 23 Sep 2015, at 08:55, Tagir F. Valeev wrote: > Hello! > > Quite interesting feature. Isn't it a typo here? > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8136924-arrays-mismatch-vectorized-unsafe/webrev/src/java.base/share/classes/java/util/ArraysSupport.java.html > > 419if (!Float.isNaN

Re: RFR 8135248: Add utility methods to check indexes and ranges

On 23 Sep 2015, at 01:18, Remi Forax wrote: > Hi Paul, > > > > - Mail original ----- >> De: "Paul Sandoz" >> À: "core-libs-dev" >> Envoyé: Mardi 22 Septembre 2015 12:40:03 >> Objet: Re: RFR 8135248: Add utility methods to ch

Re: Array equality, comparison and mismatch

Hi Peter, On 23 Sep 2015, at 10:09, Peter Levart wrote: > Hi Paul, > > Just some thoughts about nulls... > Thanks, this is helpful. > Simple compare and compareUnsigned methods (without ranges) accept null > arrays. Yes. > They specify that indirectly by stating that they are consistent

Re: RFR: jsr166 openjdk9 integration

Hi, I trawled through the patches and could not find anything obvious that clobbered existing JDK stuff. In the misc/locks patches there are some classes that might contain spec changes: ConcurrentLinkedDeque CopyOnWriteArraySet ScheduledExecutorService ScheduledThreadPoolExecutor L

Re: RFR: jsr166 openjdk9 integration

On 23 Sep 2015, at 21:33, Martin Buchholz wrote: > > > On Wed, Sep 23, 2015 at 3:16 AM, Paul Sandoz wrote: > Hi, > > I trawled through the patches and could not find anything obvious that > clobbered existing JDK stuff. > > In the misc/locks patches there

Re: RFR 8135248: Add utility methods to check indexes and ranges

On 23 Sep 2015, at 18:11, Rémi Forax wrote: >> >> Because i want to support the simple cases without pulling in indy. > > and what about using an anonymous class instead ? > Not an anonymous one, but i think i know what you mean :-) Also, i don’t want to impose a null check of the exception m

specdiff Re: RFR: jsr166 openjdk9 integration

On 23 Sep 2015, at 23:41, Paul Sandoz wrote: >> If you generate a public specdiff (as I believe only Oracle folks can), it >> would be easier for all of us to review the spec changes. >> > > Yes, Roger also suggested the same to me off list. May happ

Re: RFR 8135248: Add utility methods to check indexes and ranges

On 24 Sep 2015, at 11:06, Chris Hegarty wrote: > On 24 Sep 2015, at 08:40, Paul Sandoz wrote: > >> On 23 Sep 2015, at 18:11, Rémi Forax wrote: >>>> >>>> Because i want to support the simple cases without pulling in indy. >>> >&g

Re: RFR: jsr166 openjdk9 integration

I ran the patches through JPRT. I am noticing one test failure that i cannot reproduce locally but reproduces on some test machines. java.lang.Exception: Stack trace at java.lang.Thread.dumpStack(Thread.java:1335) at FlakyThreadFactory.fail(FlakyThreadFactory.java:93) at

Re: RFR [9] 8137056: Move SharedSecrets and interface friends out of sun.misc

On 24 Sep 2015, at 16:16, Chris Hegarty wrote: > In preparation for JEP 260 "Encapsulate Most Internal APIs” [1], > SharedSecrets and friend interfaces should be moved out of > 'sun.misc’ [2] and located in a truly private package. This is so that > they are not part of the proposed to be export

Re: RFR: jsr166 openjdk9 integration

On 24 Sep 2015, at 00:22, Martin Buchholz wrote: > > On Wed, Sep 23, 2015 at 2:41 PM, Paul Sandoz wrote: > On 23 Sep 2015, at 21:33, Martin Buchholz wrote: >> >> >> In Helpers: >> >> 121 private static String newStringUnsafe(char[] chars) { >&

Re: RFR: jsr166 openjdk9 integration

On 24 Sep 2015, at 23:47, Martin Buchholz wrote: > I changed my export script to also publish my mercurial queues patches > directory. > Find it at > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/patches/ Thanks, most helpful, Paul.

Re: RFR 8135248: Add utility methods to check indexes and ranges

On 25 Sep 2015, at 09:39, Remi Forax wrote: > Hi Paul, hi chris, > > - Mail original - >> De: "Chris Hegarty" >> À: "Paul Sandoz" >> Cc: "core-libs-dev" >> Envoyé: Jeudi 24 Septembre 2015 11:06:36 >> Objet: Re: RFR

RFR 8080418 Add Optional.or()

Hi, Please review this change to add a method Optional.or that allows one to better compose optionals: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080418-optional-or/webrev/ I also took the opportunity to clear up the JavaDoc, it was a little inconsistent and i personally found it harder t

Re: RFR 8080418 Add Optional.or()

On 25 Sep 2015, at 14:00, Tagir F. Valeev wrote: > Hello! > > Quite interesting and long awaited features (at least according to > StackOverflow questions). All of them? or just the first? > Isn't it a good idea to provide also a way > to transfer between Optional types like "mapToInt", "map

Re: RFR: jsr166 openjdk9 integration

On 24 Sep 2015, at 19:57, Martin Buchholz wrote: > FlakyThreadFactory fixed: Thanks, verified. Paul. > (It would be nice if hotspot was consistent about the way it failed, > regardless of platform) > "Write once, fail anywhere" > > Index: > src/test/jtreg/util/concurrent/ThreadPoolExecutor/F

Re: RFR 8080418 Add Optional.or()

On 25 Sep 2015, at 15:06, Stephen Colebourne wrote: > On 25 September 2015 at 11:58, Paul Sandoz wrote: >> Please review this change to add a method Optional.or that allows one to >> better compose optionals: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK

Re: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure initialization

Hi, This looks like a partial dup of https://bugs.openjdk.java.net/browse/JDK-8076596 The changes look ok, but I am concerned post initialization there may be code paths taken that require the system class loader to be used but instead the boot stream class loader is used instead. Is that a le

Re: RFR 8080418 Add Optional.or()

> On 26 Sep 2015, at 10:32, Tagir F. Valeev wrote: > > Hello! > >>> Quite interesting and long awaited features (at least according to >>> StackOverflow questions). > > PS> All of them? or just the first? > > The first one is definitely the most requested feature. However, > additional method

Re: RFR 8080418 Add Optional.or()

> On 26 Sep 2015, at 21:36, Chris Hegarty wrote: > > >> On 25 Sep 2015, at 11:58, Paul Sandoz wrote: >> >> Hi, >> >> Please review this change to add a method Optional.or that allows one to >> better compose optionals: >> >> http://

Re: Implementing https://bugs.openjdk.java.net/browse/JDK-5071718

Hi Sven, Your intuition is right, you need to modify associated templates e.g.: jdk/src/java.base/share/classes/java/nio/*-X-Buffer.java.template The best thing to do is pick an existing method common to all buffers (such as the existing slice method), work out how it is implemented and then

Re: RFR 8080418 Add Optional.or()

> On 28 Sep 2015, at 19:45, Stefan Zobel wrote: > > Hi Paul, > > is it a good idea to add the "{@inheritDoc}" to the toString() Javadoc of > Optional (and to retain it in OptionalDouble/Int/Long)? > > As Stuart Marks has observed in the Double/Int/LongSummaryStatistics case > the inherited Obj

Re: RFR 8135248: Add utility methods to check indexes and ranges

> On 29 Sep 2015, at 06:48, John Rose wrote: > > On Sep 28, 2015, at 5:10 PM, Joseph D. Darcy > wrote: >> >> Joining this thread late, I think the range checking methods would have a >> happier life where they are more often found and used if the they live >> som

Re: RFR 8080418 Add Optional.or()

> On 29 Sep 2015, at 11:16, Stefan Zobel wrote: > > Looks good. One more nitpicking. "ifPresent() " in OptionalDouble/Int/Long > still uses the old wording > > > * If a value is present, perform the given action with the value, > * otherwise do nothing. > > > whereas in Optional you have the

Re: RFR 8135248: Add utility methods to check indexes and ranges

> On 29 Sep 2015, at 12:57, Stephen Colebourne wrote: > > Just to note that an ideal location for this would be on a new class, > one that has been discussed before, an "argument checker class". > > See Guava Preconditions: > https://github.com/google/guava/blob/master/guava/src/com/google/comm

Re: RFR 8135248: Add utility methods to check indexes and ranges

> On 29 Sep 2015, at 21:24, Peter Levart wrote: >> Just a few *more* bike sheds to paint :-) I am concerned i will never finish >> this nor other un/related tasks. >> >> For now I am ok with Objects being that "argument checker class” simply >> because it already has a gravitational pull due t

Re: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure initialization

> On 25 Sep 2015, at 17:19, Peter Levart wrote: > > Hi Paul, > > Thanks for looking into this. > Apologies for the late reply. > On 09/25/2015 04:07 PM, Paul Sandoz wrote: >> Hi, >> >> This looks like a partial dup of >> https://bugs.openjdk.

Re: specdiff Re: RFR: jsr166 openjdk9 integration

https://bugs.openjdk.java.net/browse/JDK-8134853 <https://bugs.openjdk.java.net/browse/JDK-8134853> this week. I expect after the JEP is integrated we will need to do another smaller integration to sweep up any further tweaks. Paul. > On Thu, Sep 24, 2015 at 1:35 AM, Paul Sandoz

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On 1 Oct 2015, at 21:25, Alan Bateman wrote: > > On 01/10/2015 18:07, Steve Drach wrote: >> >> Yes, the JEP issue has several subtasks. This one, 8132734, is just for >> java.util.jar.JarFile. There will be a separate webrev for jar tool and >> another one for enhancements to ZipFileSyste

Re: Spin Loop Hint support: Draft JEP proposal

> I wonder how Gil's proposed PerformanceHints.spinLoopHint() is to be called. > Just before entering the spin-loop or at each iteration of the loop? The latter, e.g. see the benchmark code. > Is this some kind of CPU.yield() (by analogy to Thread.yield())? > I was wondering the same, it feel

Re: Spin Loop Hint support: Draft JEP proposal

Hi Gil, Have you investigated the use of this spin loop hint in j.u.concurrent classes and other potential areas in the JDK? I think it would be useful to include some investigation to validate it’s use and then follow up with updates, perhaps separate to this JEP. > On 6 Oct 2015, at 06:32,

Re: Array equality, comparison and mismatch

> On 5 Oct 2015, at 17:35, Chris Hegarty wrote: > > Paul, > > On 22/09/15 17:30, Paul Sandoz wrote: >> Hi, >> >> Please review the following which adds methods to Arrays for performing >> equality, comparison and mismatch: >> >>

Re: RFR 8135248: Add utility methods to check indexes and ranges

> On 30 Sep 2015, at 16:13, Remi Forax wrote: > > > > - Mail original - >> De: "Paul Benedict" >> À: "Peter Levart" >> Cc: "core-libs-dev" >> Envoyé: Mercredi 30 Septembre 2015 16:06:18 >> Objet: Re: RFR 8135248: Add utility methods to check indexes and ranges >> >> Ah, I was going

Re: Array equality, comparison and mismatch

> On 6 Oct 2015, at 10:58, Chris Hegarty wrote: >>> It was not immediately obvious to me that the common prefix can be 0. >>> Should this be called out specifically? >>> >> >> When reading the documentation of compare or mismatch or both? > > mismatch. But maybe this is just me. > I could

Re: RFR [9] 8138978: Examine usages of sun.misc.IOUtils

> On 7 Oct 2015, at 22:28, Alan Bateman wrote: > > > On 07/10/2015 20:57, Chris Hegarty wrote: >> : >> I updated Connection with a readFully that has the same >> semantics as IOUtils. >> >> http://cr.openjdk.java.net/~chegar/8138978/webrev.01/jdk/ >> > I agree with Roger. Couldn't this be c

Re: RFR [9] 8138978: Examine usages of sun.misc.IOUtils

> On 8 Oct 2015, at 10:46, Chris Hegarty wrote: >> It reads at most “seqlen" bytes, so the array may be larger than necessary, >> which might be ok depending on whether one can trust "seqlen”. > > We do no trust ‘seqlen’. :-( > Good! >> The following pattern occurs a few times: >> >> byte[

Re: [concurrency-interest] Spin Loop Hint support: Draft JEP proposal

> On 8 Oct 2015, at 18:33, mark.reinh...@oracle.com wrote: > > 2015/10/8 7:56 -0700, d...@cs.oswego.edu: ... class Thread { // /** * A hint to the platform that the current thread is momentarily * unable to progress. ... add more guidance ... */

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

> On 9 Oct 2015, at 02:31, John Rose wrote: > > It may be instructive to link nulls to Optionals by encoding null-ness using > Optional: > > T nonNullElse(T x, T y) := Optional.ofNullable(x).orElseGet(() -> > Optional.ofNullable(y).get()) > And with the new Optional.or [*] to be added soon

Re: Array equality, comparison and mismatch

> On 22 Sep 2015, at 18:30, Paul Sandoz wrote: > > Hi, > > Please review the following which adds methods to Arrays for performing > equality, comparison and mismatch: > > https://bugs.openjdk.java.net/browse/JDK-8033148 > > http://cr.openjdk.java.net/~p

Optional.or name Re: RFR 8080418 Add Optional.or()

> On 25 Sep 2015, at 12:58, Paul Sandoz wrote: > > Hi, > > Please review this change to add a method Optional.or that allows one to > better compose optionals: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080418-optional-or/webrev/ > > I also took t

Re: Array equality, comparison and mismatch

> On 12 Oct 2015, at 09:47, Andrej Golovnin wrote: > > Hi Paul, > > wouldn't it be better to use Objects#equals(Object, Object) in the > line 3293 in the Arrays class instead of the ternary operator (the > same applies to the line 3238)? > Thanks updated both the Arrays.equals and Arrays.mism

Re: Array equality, comparison and mismatch

> On 12 Oct 2015, at 19:50, Mike Duigou wrote: > > >>> On 22 Sep 2015, at 18:30, Paul Sandoz wrote: >>> Hi, >>> Please review the following which adds methods to Arrays for performing >>> equality, comparison and mismatch: >>> htt

Re: Array equality, comparison and mismatch

> On 13 Oct 2015, at 05:46, Mike Duigou wrote: > >>> - I apologize if this was discussed earlier in the thread but why is the >>> comparison of floats and doubles done by first == operator of the int bits >>> and only then the compare method ? >> I was being consistent with the test used for t

Re: RFR: JDK-8136893: Improve early java.lang.invoke infrastructure initialization

> On 13 Oct 2015, at 13:26, Claes Redestad wrote: >> >> Thus it seems fixMethodType is not necessary. I think this is confirmed when >> looking at up calls to linkMethodHandleConstant and linkCallSite. > > +1 - this should be a separate cleanup, though. > Yes. >> >>> The reasoning is as f

Re: Optional.or name Re: RFR 8080418 Add Optional.or()

> On 13 Oct 2015, at 22:43, Stephen Colebourne wrote: > > I'd prefer to see "this" mentioned: > > "If a value is not present, invoke the specified supplier to provide > the result, otherwise return {@code this}" > > While I understand the original form gave some spec wiggle room, it > also mad

Re: RFC: draft API for JEP 269 Convenience Collection Factories

> On 14 Oct 2015, at 06:18, Stuart Marks wrote: > I'm not entirely sure what to take from this. If it were clearly exponential, > we could say with confidence that above a certain threshold there would be > vanishingly little benefit adding more arguments. But since the curve seems > to flatte

Re: Incomplete JavaDoc for Collections.synchronizedXYZ

Hi Tagir, Agreed. If you wanna send a patch to this list with updates to the other synchronized* methods i can review push it for you. Paul. > On 12 Oct 2015, at 15:18, Tagir F. Valeev wrote: > > Hello! > > With the introduction of Stream API the JavaDoc for > Collections.synchronizedCollect

Re: java.lang.reflect.Method.copyOf

> On 14 Oct 2015, at 12:38, Remi Forax wrote: > > Given that j.l.r.Method is mutable, the best way to have performance is too > encapsulate it in a non mutable class, if possible. > > As far as i know j.l.r.Method was introduced in Java 1.1 as non mutable and > become mutable with Java 1.2, (

Re: java.lang.reflect.Method.copyOf

> On 14 Oct 2015, at 16:15, Remi Forax wrote: > > - Mail original - >> De: "Paul Sandoz" >> Cc: "core-libs-dev" >> Envoyé: Mercredi 14 Octobre 2015 13:46:38 >> Objet: Re: java.lang.reflect.Method.copyOf >> >> >

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On 14 Oct 2015, at 21:12, Steve Drach wrote: > >>> The current test directory contains binary jar files. In fact in all the >>> test directories, there are 52 binary .jar files. >> I know but we need to work to remove those. > > I figured that might be the response, but thought it was worth

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

> On 15 Oct 2015, at 05:00, Xueming Shen wrote: > > I'm not sure if it is a good idea, from performance perspective, to add a > "versionEntry" field into the JarEntry > to support this feature, given most of the jar files might not be > multi-release-jar aware, and the Jar input& > output stre

Re: Array equality, comparison and mismatch

> On 13 Oct 2015, at 12:03, Andrew Haley wrote: > > On 13/10/15 10:22, Paul Sandoz wrote: >> Analysis so far indicate big gains are to be had on larger arrays with >> better or no impact on small arrays if i do the following instead: >> >> i

Re: RFC: draft API for JEP 269 Convenience Collection Factories

> On 15 Oct 2015, at 16:28, Stephen Colebourne wrote: > > I've been working on a Java 8 wrapper class around double[] in my day > job, and added the following factory method: > > /** > * Obtains an instance with entries filled using a function. > * > * The function is passed the array i

Re: 8139891: Prepare Unsafe for true encapsulation

Hi Chris, This looks like a good first step. I am sure hotspot devs will have more concrete review comments, but i like the way the method aliasing (copying the same technique StrictMath -> Math) avoids any changes to the intrinsics, thus the changes are much more localized. It may be worth ha

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

> On 2 Nov 2015, at 00:56, 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. > > http://cr.openjdk.java.net/~chegar/8140687/00/ > +1 Paul.

Re: RFR [9] 8140606: Update library code to use internal Unsafe

> On 28 Oct 2015, at 20:55, Chris Hegarty wrote: > > Following on from 8139891 "Prepare Unsafe for true encapsulation” [1], > the JDK library code should use the internal Unsafe class, and not > sun.misc.Unsafe. > > http://cr.openjdk.java.net/~chegar/8140606/00/ > +1 Paul. > This will be pu

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

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

Re: RFR 8136496 Connection.begin/endRequest

> On 2 Nov 2015, at 18:37, Lance Andersen wrote: > > Hi, > > Need a reviewer for 8136496. The CCC has been approved. > > The webrev can be found at > http://cr.openjdk.java.net/~lancea/8136496/webrev.00/ > Looks ok. Just a minor point: + * @implSpec + * The default implementation

Re: RFR (XS): 8140683: Deduplicate Strings in UnixFileSystem canonical caches

> On 28 Oct 2015, at 21:01, Claes Redestad wrote: > > Hi, > > while investigating startup and footprint for jigsaw, I found this unrelated > oddity where java.io.UnixFileSystem is missing an opportunity to deduplicate > file paths determined to be equal when putting them into its internal cac

Re: RFR 9: 8138566: (Process) java.lang.Process.allChildren specification clarification

> On 31 Oct 2015, at 00:41, Roger Riggs wrote: > > Please review and comment on 3 clarifications to ProcessHandle and Process. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-process-clarify-8138566/ > > 8138566: (Process) java.lang.Process.allChildren specification clarification > -

Re: RFR 9: 8138566: (Process) java.lang.Process.allChildren specification clarification

> On 3 Nov 2015, at 17:21, Roger Riggs wrote: > > Hi Paul, > > Thanks for the review. > > The webrev is updated in place: > http://cr.openjdk.java.net/~rriggs/webrev-process-clarify-8138566/ > > > I added an @apiNote to both onExit methods: > > * The process may be observed to have term

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

Hi, This is a significant body of impressive work, well done all who worked on it. String — 148 * The instance field value is generally opaque to optimizing JIT 149 * compilers. Therefore, in performance-sensitive place, an explicit 150 * check of the static boolean {@code COM

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

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, Integer> counter() { > return stream::count; > } > > .

Re: RFR - 8132734: java.util.jar.* changes to support multi-release jar files

Hi Steve, Hi Steve, I don’t think we need to cache versioned entries (as we discussed a while back). For class loading it’s likely to increase memory costs without any performance benefit (if anything a performance decrease). It’s easy to add back later on if we have data that suggests otherwi

RFR 8141409 Arrays.equals accepting a Comparator

Hi, Please review: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8141409-Arrays-equals-comparator/webrev/ https://bugs.openjdk.java.net/browse/JDK-8141409

  1   2   3   4   5   6   7   8   9   10   >