Re: [11] RFR: 4993841: (str) java.lang.Character should have a toString(int) method

Hi Naoto, Thanks for fixing the original issue, and for filing the cleanup followup bug. s'marks On 3/3/18 9:30 AM, naoto.s...@oracle.com wrote: Hi Stuart, Filed an issue for the cleanup: https://bugs.openjdk.java.net/browse/JDK-8198989 Naoto On 3/2/18 5:50 PM, Stuart Marks wrote: Looks

Re: RFR: JDK-8197594: String#repeat

On 2/28/18 6:34 PM, James Laskey wrote: Thanks Stuart. RE apinote, I was trying to follow the pattern of other older method comments (Roman-style.) Comments/Javadoc in most of these older classes are a mix of styles. Question: if you update/clean-up a method in an older class, should you bring

Re: [11] RFR: 4993841: (str) java.lang.Character should have a toString(int) method

Looks good. I note that other codepoint-consuming methods, such as Character.UnicodeBlock.of(cp) Character.UnicodeScript.of(cp) Character.toChars(cp, char[], int) Character.toChars(cp) Character.getName(cp) all throw IAE with no message. It would be nice to add messages to

Re: [11] RFR: 4993841: (str) java.lang.Character should have a toString(int) method

. s'marks Rémi - Mail original - De: "naoto sato" <naoto.s...@oracle.com> À: "Stuart Marks" <stuart.ma...@oracle.com>, "Xueming Shen" <xueming.s...@gmail.com>, "core-libs-dev" <core-libs-dev@openjdk.java.net> Envoyé: Vendred

Re: RFR: JDK-8197594: String#repeat

Hi Jim, Implementation looks good. I'd suggest a couple small editorial changes to the spec: 2966 /** 2967 * Returns a string whose value is the concatenation of this 2968 * string repeated {@code count} times. 2969 * 2970 * If count or length is zero then the empty

Re: RFR: 8197594 - String and character repeat

On 2/18/18 1:37 AM, James Laskey wrote: Didn’t I hear someone mentioning “\U1D11A” at some point? On 2/19/18 7:55 AM, Martin Buchholz wrote: Oops, I already got it wrong - it's already at 6 hex digits because there are 17 planes, not 16.  MAX_CODE_POINT is U+10. Yes, we need a variable

Re: RFR: 8197594 - String and character repeat

To close the loop on this, I've reopened JDK-4993841, which requests adding an API Character.toString(int) which converts an int codepoint value to a String. (This seems like the obvious API, in parallel with Character.toString(char), but of course alternatives could be considered.) s'marks

Re: RFR: 8197594 - String and character repeat

On #2, better to aim for string.ofCodePoint(int) and compose w repeat. > > Down to one method again :) > > Sent from my MacBook Wheel > >> On Feb 16, 2018, at 5:13 PM, Stuart Marks <stuart.ma...@oracle.com> wrote: >> >> Let me put in an argument fo

Re: RFR: 8197594 - String and character repeat

Let me put in an argument for handling code points: 3. public static String repeat(final int codepoint, final int count) Most of the String and Character API handles code points on an equal footing with chars. I think this is important, as over time Unicode is continuing to add

Re: RFR: JDK-8021560,(str) String constructors that take ByteBuffer

On 2/16/18 6:14 AM, Alan Bateman wrote: On 15/02/2018 21:55, Stuart Marks wrote: I'd also suggest adding a CharBuffer constructor:     public String(CharBuffer cbuf) This would be semantically equivalent to     public String(char[] value, int offset, int count) except using the chars from

Re: [11] RFR JDK-8198249: Remove deprecated Runtime::runFinalizersOnExit and System::runFinalizersOnExit

On 2/15/18 3:06 PM, mandy chung wrote: Runtime.runFinalizersOnExit has been deprecated since 1.2 (1998) and deprecated for removal in JDK 9.  We analyzed the maven central artifacts few years ago that show very few uses of it.  I also survey a recent version of most of the maven artifacts that

Re: RFR: JDK-8021560,(str) String constructors that take ByteBuffer

public String(ByteBuffer bytes, Charset cs); public String(ByteBuffer bytes, String csname); I think these constructors make good sense. They avoid an extra copy to an intermediate byte[]. One issue (also mentioned by Stephen Colebourne) is whether we need the csname overload. Arguably it's

Re: RFR (JDK11) 8137326: Methods for comparing CharSequence, StringBuilder, and StringBuffer

Hi Joe, Overall, looks good. Are there any tests of AbstractStringBuilder.compareTo() that exercise comparisons of the Latin1 vs UTF16 coders? A couple people have raised the issue of the SB's implementing Comparable but not overriding equals(). This is unusual but well-defined. I do think

Re: RFR 8196298 Add null Reader and Writer

On 2/1/18 10:35 AM, Patrick Reinhart wrote: Here is my first shot of the actual implementation and tests: http://cr.openjdk.java.net/~reinhapa/reviews/8196298/webrev.00 I looked at the specification of ready() vs the implementation. The spec says that ready(), among other methods, behaves

Re: Collections.addAll: remove outdated performance advice and add a note about atomicity

Links to existing material in OpenJDK: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-December/050326.html https://bugs.openjdk.java.net/browse/JDK-8193031 I agree with the removal of the performance advice. We should also remove "identical"; my suggested replacement was

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

John Rose wrote: Can anyone point out a reason why the value based lists of List.of() should serialize while the value based lists of List.of().subList() should not? Or is there some reason we should not allow subList to produce value based lists? I think one can interpret the @implSpec in

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Finally catching up with this thread Yes, there should be some additional test cases added. When I added the immutable collection classes in JDK 9, I did modify MOAT.java so that its test cases would apply to the new implementations. A few more cases could be added that apply not only to

Re: RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()

On 12/18/17 2:31 AM, Tagir Valeev wrote: I think that both methods could co-exist with slightly different semantics (even though they implementation is identical): ... Think of get() as an assertion-like method: if get() throws, then it's a bug in the code (most likely right in this method).

Re: [10] RFR 8193856 takeWhile produces incorrect result with elements produced by flatMap

On 12/20/17 1:28 PM, Paul Sandoz wrote: Please review this fix for a bug in the stream takeWhile operation: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8193856-takeWhile-incorrect-results/webrev/

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

On 12/7/17 5:03 PM, Martin Buchholz wrote: (I'm still trying to love this new API) The changes to the jsr166 tck are fine. I'm not convinced that the new implementation for ArrayList is progress.  The current implementation of toArray(T[]) does             // Make a new array of a's

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

Frankly, I think the JDK is just sloppy here. Most of the existing implementations didn't use @Override -- possibly because they were introduced before annotations existed -- and later on, whoever implemented the overrides of the Java 8 default methods decided to add @Override.

Re: RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()

On 12/9/17 1:20 AM, Stephen Colebourne wrote: On 8 December 2017 at 00:33, Stuart Marks <stuart.ma...@oracle.com> wrote: Please review this changeset that introduces a new no-arg method orElseThrow() to Optional, as a preferred alternative to the get() method. I am willing to

Re: RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()

rds, Rémi - Mail original ----- De: "Stuart Marks" <stuart.ma...@oracle.com> À: "core-libs-dev" <core-libs-dev@openjdk.java.net> Envoyé: Vendredi 8 Décembre 2017 01:33:41 Objet: RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()

Re: RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()

Please review this changeset that introduces a new no-arg method orElseThrow() to Optional, as a preferred alternative to the get() method. This looks good. The naming is consistent and I think better than the "getWhenPresent" proposed in the original thread. i agree with Alan. Having a

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

On 12/7/17 3:50 PM, Jonathan Bluett-Duncan wrote: Looking over http://cr.openjdk.java.net/~smarks/reviews/8060192/webrev.2/src/java.base/share/classes/java/util/ArrayList.java.cdiff.html, I'm wondering if the method `ArrayList.toArray(IntFunction)` should have an `@Override` to make it

RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()

Hi all, Please review this changeset that introduces a new no-arg method orElseThrow() to Optional, as a preferred alternative to the get() method. Corresponding methods are also added to OptionalDouble, Int, and Long. The orElseThrow() method is functionally identical to get(). It has some

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

[Martin: please review changes to the JSR 166 TCK.] Another updated webrev for this changeset: http://cr.openjdk.java.net/~smarks/reviews/8060192/webrev.2/ This includes an override of toArray(IntFunction) in the implementation of Arrays.asList(), as requested by Tagir Valeev. Overrides

RFR(s): 8177681: Remove methods Runtime.getLocalized{Input,Output}Stream

Hi all, Please review the removal of these methods, which were part of an obsolete internationalization mechanism. They were deprecated in JDK 1.1 and deprecated for removal in JDK 9. As far as I can see, there is no usage of these methods anywhere. Bug link:

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

On 12/5/17 8:41 PM, Bernd Eckenfels wrote: Should the test also check for the case the generator returns under- and oversized arrays? Did you mean that the default implementation (and various overriding implementations) of toArray(generator) should do checks on the array that's returned

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

On 12/5/17 6:54 PM, Tagir Valeev wrote: I think, CopyOnWriteArrayList and a List returned by Arrays.asList deserve specialized implementation as well. Sure, I can add one to Array.asList right away (as part of this changeset). It's even covered by tests already. I'll work with Martin to

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

The signature of the proposed generator is public T[] toArray(IntFunction generator) So I don't think that anything has really changed in this regard; T can still be unrelated to E. Right, the new method doesn't offer any safety compared to toArray(T[]). You can still get

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

Revised webrev based on comments from Martin Buchholz and Paul Sandoz: http://cr.openjdk.java.net/~smarks/reviews/8060192/webrev.1/ I've done a bit of rewriting of the @apiNote sections to clarify the intended use of the various toArray() methods. s'marks

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

On 12/5/17 10:47 AM, Paul Sandoz wrote: 345 * Suppose {@code x} is a collection known to contain only strings. 346 * The following code can be used to dump the collection into a newly 347 * allocated array of {@code String}: Make it an API note? (same for toArray(T[])

Re: RFR 8015667 Stream.toArray(IntFunction) ArrayStoreException should refer to component type of array

Hi Paul, Thanks for picking this up. The change looks good. s'marks On 12/5/17 10:34 AM, Paul Sandoz wrote: Hi, Since Stuart is cleaning up Collection.toArray etc we might as well do the same for Stream.toArray. diff -r df95bd1fd4b1 src/java.base/share/classes/java/util/stream/Stream.java

Re: RFR(s): 8060192: Add default method Collection.toArray(generator)

+// no spec changes relative to supertype +public T[] toArray(IntFunction generator) { You probably at least need @inheritDoc for the unchecked exception throws (as I've forgotten many times) There's a new javadoc option "--override-methods summary" that was recently added

Re: RFR: 8193031: Collections.addAll is likely to perform worse than Collection.addAll

On 12/4/17 7:50 PM, Martin Buchholz wrote: https://bugs.openjdk.java.net/browse/JDK-8193031 http://cr.openjdk.java.net/~martin/webrevs/jdk/Collections-addAll/ * Adds all of the specified elements to the specified collection. * Elements to be added may be specified individually or

RFR(s): 8060192: Add default method Collection.toArray(generator)

Hi all, Please review this small enhancement to add a default method Collection.toArray(generator) that takes a function that creates the destination array. This is analogous to Stream.toArray(generator). Bug: https://bugs.openjdk.java.net/browse/JDK-8060192 Webrev:

Re: RFR: JDK-8192935 Fix EnumSet's SerializationProxy javadoc

If you don't like my alternative, fine; it has its own set of tradeoffs that might be net positive or negative. If you want to proceed with the current approach, then I won't stand in the way. At the very least there should be some boilerplate added to EnumSet that makes it clear

Re: RFR: JDK-8192935 Fix EnumSet's SerializationProxy javadoc

On 12/4/17 12:36 PM, Martin Buchholz wrote: On Mon, Dec 4, 2017 at 12:12 PM, Roger Riggs wrote: The java.time APIs refined the pattern used for Serialization proxies to document the relationship between the original class and its serialization proxies methods.

Re: RFR: JDK-8192935 Fix EnumSet's SerializationProxy javadoc

On 12/1/17 4:42 PM, Martin Buchholz wrote: 1. JDK-8192935 http://cr.openjdk.java.net/~martin/webrevs/openjdk10/EnumSet-SerializationProxy/EnumSet-SerializationProxy.patch --- a/src/java.base/share/classes/java/util/EnumSet.java +++

Re: RFR(s): 8160406: Collection.toArray() spec should be explicit about returning precisely an Object[]

On 11/29/17 7:28 PM, Martin Buchholz wrote: I would make one change. +     * @param the static component type of the array to contain the collection Just drop runtime/static     * @param the component type of the array to contain the collection the "static" is "obvious" and the caller

Re: RFR(s): 8160406: Collection.toArray() spec should be explicit about returning precisely an Object[]

On 11/29/17 5:20 PM, Martin Buchholz wrote: Thanks.  This looks good, and finishes the effort started 12 years ago. Apologies for not having made this spec change myself years ago. I tried to find a less JLSese way to wordsmith it.  Nearby spec talks about the "runtime type" of the array.

RFR(s): 8160406: Collection.toArray() spec should be explicit about returning precisely an Object[]

Hi all, Please review this small spec change / clarification regarding Collection.toArray(). The runtime type of the array returned has always been intended to be exactly Object[] and not an array of some subtype. This requirement is actually implied by the spec already, but in the wrong

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

On 11/29/17 10:09 AM, Martin Buchholz wrote: Guava's "immutable collections" are very popular https://github.com/google/guava/wiki/ImmutableCollectionsExplained and it's not a good idea to fight their advertised notion of "immutable". No generic container class can promise s'marks-style

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

On 11/22/17 8:45 AM, Remi Forax wrote: I think i prefer toImmutableList() than toUnmodifiableList() because the List is truly immutable and not an unmodifiable proxy in front of a mutable List (like Collections.unmodifiableList() does). Immutability is like wine. If you put a spoonful of wine

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

On 11/17/17 9:43 PM, John Rose wrote: Late to the party, but these lines rub me the wrong way: @return the new {@code List} @return the new {@code Set} @return the new {@code Map} The word "new" is a loaded term, which usually means (or can be easily mistaken to mean) that a new object

Re: 8181175 Stream.concat behaves like terminal operation

On 11/20/17 10:34 AM, Paul Sandoz wrote: On 17 Nov 2017, at 17:18, Stuart Marks <stuart.ma...@oracle.com> wrote: The normative text about binding to the source and subsequent modifications to the source possibly not being reflected in the stream makes sense. I'm having trouble underst

Re: 8181175 Stream.concat behaves like terminal operation

Hi Paul, The normative text about binding to the source and subsequent modifications to the source possibly not being reflected in the stream makes sense. I'm having trouble understanding the API note though. What does "optimal" mean? What about concatenating multiple streams would not be

Re: RFR 8191429 List.sort should specify the sort is stable

Hi Paul, The change looks good. s'marks On 11/16/17 1:48 PM, Paul Sandoz wrote: Hi, Please review the change in specification of List.sort to state the sort must be stable (CSR is already approved): Thanks, Paul. diff -r e0041b182e31 src/java.base/share/classes/java/util/List.java ---

Re: Collections.emptyList().sort() does nothing

On 11/15/17 11:52 PM, Tagir Valeev wrote: While this isn't guaranteed by the spec, changing these at this point would be a behavioral incompatibility, so we're unlikely ever to change them. But this behavior will not be specified as well, right? I don't have any plans to change the docs

Re: Collections.emptyList().sort() does nothing

On 11/14/17 7:52 PM, Tagir Valeev wrote: According to `List.sort` specification [1] "This list must be modifiable". According to `Collections.emptyList` specification [2] "Returns an empty list (immutable)." So I assume that `List.sort` cannot be called on `Collections.emptyList` result.

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

Why not using:     coll.stream().collect(Collectors.toImmutableSet()) As Collectors.toImmutableSet() is currently implemented, with serial Stream it will create a single HashSet, add all the elements to it and call Set.of(HashSet.toArray()) with it. Pretty much the same as what Tagir

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

ee Unmodifiable Maps for details. Regards, Stefan 2017-11-01 0:49 GMT+01:00 Stuart Marks <stuart.ma...@oracle.com>: Updated webrev, based on comments from Brian and Roger: http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.2/ s'marks On 10/30/17 3:50 PM, Stuart Marks wrote: (

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

ap and Set constructors. Thanks, Roger On 10/31/2017 7:49 PM, Stuart Marks wrote: Updated webrev, based on comments from Brian and Roger: http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.2/ s'marks On 10/30/17 3:50 PM, Stuart Marks wrote: (also includes 8184690: add Collectors for

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

is the code I want to replace with a private interface, I don't think it's worth fiddling around with at this point. Thanks, s'marks With best regards, Tagir Valeev. With best regards, Tagir Valeev. On Wed, Nov 1, 2017 at 12:49 AM, Stuart Marks <stuart.ma...@oracle.com> wrote: Up

Re: Confusion (or bugs) regarding the 'UNORDERED' Collector Characteristic

On 10/27/17 1:56 PM, Chris Dennis wrote: I’m very confused about what was intended with the ‘UNORDERED’ Collector characteristic. My logical inference was that unordered as a Collector characteristic meant that the result of this collector applied to any stream was independent of the order

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

On 10/31/17 5:52 PM, Bernd Eckenfels wrote: Having a List.of(List) copy constructor would save an additional array copy in the collector Which uses (List)List.of(list.toArray()) The quickest way to get all the elements from the source collection is to call toArray() on it. Some copy

Re: ThreadPoolExecutor and finalization

On 10/31/17 6:58 PM, David Holmes wrote: I'm not sure why you say this isn't helpful. It's clearly not helpful to *clients* of TPE; but since finalize() is protected, the warning is clearly directed at subclasses, and it provides information about migrating away from finalization. Should say

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

Updated webrev, based on comments from Brian and Roger: http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.2/ s'marks On 10/30/17 3:50 PM, Stuart Marks wrote: (also includes 8184690: add Collectors for collecting into unmodifiable List, Set, and Map) Hi all, Here's an updated

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

erging of values. Collectors:1606:  impl note:  With three different NPE throws, it is helpful to use the 2-arg form of requireNonNull to indicate which parameter offends. Will update. Thanks, s'marks Roger On 10/30/2017 6:50 PM, Stuart Marks wrote: (also includes 8184690: add Collect

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

imagine similar private interfaces to avoid excess copies, but I think they each still need to build up full intermediate HashSet/HashMap in order to get rid of duplicates. s'marks On 10/30/2017 6:50 PM, Stuart Marks wrote: (also includes 8184690: add Collectors for collecting into unmodif

Re: ThreadPoolExecutor and finalization

On 10/30/17 10:21 AM, Martin Buchholz wrote: The initiative is to identify and remediate existing uses of finalization in the JDK. I've been skeptical about this initiative as stated. I would not have deprecated finalize(). We will never remove finalize() from the JDK, and I don't see how

Re: [Bug][JDK10] Fix duplicated "a" occurrences in docs

No, Roger checked in the "the the" patch before Christophe posted a "a a" followup patch. :-) s'marks On 10/30/17 6:00 PM, David Holmes wrote: Does this duplicate the the patch Christoph sent regarding the the? ;-) Roger was handling that one. David On 31/10/2017 10

Re: [Bug][JDK10] Fix duplicated "a" occurrences in docs

Hi all, Please review the patch below. I'm sending this for review because it's expanded considerably beyond the original patch that Christoph had submitted. I ran a full-text search over the java.base source files looking for "the the" and "a a" and it found a bunch of additional occurrences

Re: [Bug][JDK10] Fix duplicated "a" occurrences in docs

I'll take this one. I just ran across another minor error I wanted to fix so I'll piggyback mine on yours. https://bugs.openjdk.java.net/browse/JDK-8190382 Thanks for pointing these out! s'marks On 10/30/17 9:05 AM, Christoph Dreis wrote: The attached patched seems to have been dropped.

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

mutated because one of the objects in the collection is mutable. I'm sure *you* aren't confused by the issues. But I spend a lot of effort explaining these issues to the general public, so I think the change is worthwhile. s'marks Thanks, Roger On 9/21/2017 2:55 PM, Stuart Marks wrote: On 9/21/17 5:4

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

l n. Yes, these are preliminary implementations, to which many optimizations can be applied. s'marks Thanks, Roger On 9/21/2017 2:55 PM, Stuart Marks wrote: On 9/21/17 5:42 AM, Alan Bateman wrote: On 21/09/2017 01:02, Stuart Marks wrote: http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.0/ I re

Re: RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

On 9/21/17 5:42 AM, Alan Bateman wrote: On 21/09/2017 01:02, Stuart Marks wrote: http://cr.openjdk.java.net/~smarks/reviews/8177290/webrev.0/ I read through the updated/new definitions and they read well. Great. For the copyOf methods then I can't immediately tell from the javadoc

RFR(m): 8177290 add copy factory methods for unmodifiable List, Set, Map

(also includes 8184690: add Collectors for collecting into unmodifiable List, Set, and Map) Hi all, Please review the following changeset with specification changes to support the following: * new List.copyOf(), Set.copyOf(), and Map.copyOf() "copy factory" methods * new

RFR(s): 8186851 fix misspellings of "dependent" and "independent" in the JDK repo

Hi all, I was irked by some misspellings so I decided to create a quick fix. Webrev: http://cr.openjdk.java.net/~smarks/reviews/8186851/webrev.0/ Bug: https://bugs.openjdk.java.net/browse/JDK-8186851 Most of the changes are in core libs and in Swing, so I'm posting to both lists.

Re: RFR(s) #2: 6344935: (spec) clarify specifications for Object.wait overloads

On 8/25/17 11:34 AM, Martin Buchholz wrote: Stuart, you have my blessing to commit what you have, even though both your reviewers are still nitpicking that wait loop. OK, thanks, I was thinking the same thing. :-) s'marks

Re: RFR 8186539 [testlibrary] : TestSocketFactory should allow triggers before match/replace

On 8/21/17 2:08 PM, Roger Riggs wrote: Please review a rmi testlibrary enhancement to allow a trigger byte sequence before the match and replace. It improves the ease with which stream contents can be identified when streams contain IP addresses and sequence numbers that change from run to

Re: RFR(s) #2: 6344935: (spec) clarify specifications for Object.wait overloads

On 8/20/17 6:32 PM, David Holmes wrote: You're a brave man :) "It's a dirty job, but somebody's gotta do it." :-) I have a personal interest in this, as back in the 1.3 days I was trying to nail down some multi-threaded code, and I found the wait() docs to be quite lacking. In particular,

RFR(s) #2: 6344935: (spec) clarify specifications for Object.wait overloads

Hi all, Well nothing is ever simple, is it? Prompted by David Holmes' comments, I looked at the other overloads of wait(), and I agree that they're in need of cleanup. I decided to put the most complete version of the specification into the wait(timeout, nanos) overload, and then I simply

Re: RFR(xs): 6344935: Clarify Object.wait javadoc with respect to spurious wakeups

In general, I'm in favor of ensuring that wording in various bits of the specification is well aligned. I don't see specifically what would need to be improved in this case, though. Can we align the wording with existing wording in either LockSupport or Condition? The various

RFR(xs): 6344935: Clarify Object.wait javadoc with respect to spurious wakeups

This is an old spec bug. The Object.wait spec lists several different reasons a thread could be awakened, but it omits spurious wakeup -- even though spurious wakeup is described later on. The fix is simply to add spurious wakeup to the list. There is some discussion in the original bug

Re: RFR: JDK-8185994: Fix a11y and HTML issues in the java.base/java.io and java.base/java.nio packages

On 8/9/17 5:14 PM, Jonathan Gibbons wrote: Please review this proposed change to address accessibility and HTML issues in the java.base java.io and java.nio[.*] packages. In general, the changes consist of * update tables to add scope=row|col as appropriate. In some cases, slightly more

Re: RFR: JDK-8186052: Fix a11y and HTML issues in the java.base/java.lang[.*] packages

On 8/9/17 5:11 PM, Jonathan Gibbons wrote: Please review this proposed change to address accessibility and HTML issues in the java.base java.lang[.*] packages. In general, the changes consist of * update tables to add scope=row|col as appropriate. In some cases, slightly more surgery was

Re: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator

On 8/1/17 11:56 PM, Ivan Gerasimov wrote: I've tried to go one step further and created even more abstract comparator: It uses a supplied predicate to decompose the input sequences into odd/even subsequences (e.g. alpha/numeric) and then uses two separate comparator to compare them.

Re: [10] RFR 8134512 : provide Alpha-Numeric (logical) Comparator

Hi Ivan, I think this is an interesting avenue to explore adding to the platform. The idea of sorting this way is pretty subtle and it seems to come up frequently, so it seems valuable. There are some issues that warrant further discussion, though. Briefly: 1. Should this be in the JDK? 2.

Re: RFR 9+-: 8180582: The bind to rmiregistry is rejected by registryFilter even though registryFilter is set

-max-8180582/index.html Thanks, Roger On 5/31/17 7:09 PM, Stuart Marks wrote: Hi Roger, RegistryImpl change looks fine. I have a quibble on the regex used in the test. 162 Matcher m = Pattern 163 .compile(".*maxdepth=(\\d*)") 164 .matcher(Objects.requireN

Re: RFR 9+-: 8180582: The bind to rmiregistry is rejected by registryFilter even though registryFilter is set

Hi Roger, RegistryImpl change looks fine. I have a quibble on the regex used in the test. 162 Matcher m = Pattern 163 .compile(".*maxdepth=(\\d*)") 164 .matcher(Objects.requireNonNullElse(registryFilter, "")); 165 int depthOverride = m.find()

Re: [REVISED] JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time

On 5/25/17 8:32 AM, Brian Burkhalter wrote: This is a continuation / merge of two previous RFRs: 6791812: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047787.html 8180767: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-May/047809.html An updated patch which

Re: JDK 10 RFR of 8180767: A return value of zero from java.io.File#lastModified() is ambiguous

On 5/23/17 8:03 AM, Brian Burkhalter wrote: Or perhaps per Alan’s comments below change the current wording Where it is required to distinguish an I/O exception from the case where 0L is returned, or where several attributes of the same file are required at the same time, or where the time

Re: JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time

On 5/23/17 8:21 AM, Brian Burkhalter wrote: So I guess this might be satisfy your and Stuart’s comments: --- a/src/java.base/share/classes/java/io/File.java +++ b/src/java.base/share/classes/java/io/File.java @@ -932,7 +932,9 @@ * @return A long value representing the time the file was

Re: JDK 10 RFR of 8180767: A return value of zero from java.io.File#lastModified() is ambiguous

On 5/22/17 1:45 PM, Brian Burkhalter wrote: On May 22, 2017, at 1:42 PM, Martin Buchholz wrote: I have no opinion on how to address the problem - just pointing out that the problem is real. I might choose an even less likely value than 1 if I were to switch from 0.

Re: JDK 9 doc-api-only RFR of 6791812: (file spec) Incompatible File.lastModified() and setLastModified() for negative time

On 5/19/17 11:59 AM, Brian Burkhalter wrote: https://bugs.openjdk.java.net/browse/JDK-6791812 --- a/src/java.base/share/classes/java/io/File.java +++ b/src/java.base/share/classes/java/io/File.java @@ -932,7 +932,9 @@ * @return A long value representing the time the file was *

Re: JDK 9 RFR(s): 8177788 migrate collections docs into jdk doc-files

On 5/19/17 10:18 AM, Martin Buchholz wrote: Not sure what "the internationalization facility" is. My view is that this package has "some" collection classes and "some" classes related to internationalization. I'll reword that to mention "some internationalization support classes" or something

JDK 9 RFR(s): 8177788 migrate collections docs into jdk doc-files

Hi all, Please review this updated webrev [1] to migrate some collections technotes/guides into the JDK's javadoc doc-files. This is an update of a webrev, previously reviewed. [2] In response to some comments from Mandy, I've removed the collections version history from this changeset.

Re: JDK 9 doc-api-only RFR of 7086489: File.lastModified should accuracy as well as resolution

On 5/17/17 1:28 PM, Brian Burkhalter wrote: This wording "the unit of time of the return value is a millisecond” sounds weird. I would have written "the unit of time of the return value is milliseconds.” OK. How about then (ignore formatting)? * @apiNote * While the unit of time of

Re: JDK 9 doc-api-only RFR of 7086489: File.lastModified should accuracy as well as resolution

This is for JDK 9, right, so we want only non-normative doc changes? I'd think this should be an @apiNote instead of @implSpec. The @apiNote clarifies but doesn't change the semantics, whereas @implSpec can impose requirements on the implementation and is thus normative. The intent of the

JDK 9 RFR(xs): 8180137: fix broken link in java.lang.Iterable

Hi all, Another quick doc change. This one removes a link from Iterable to technotes/guides and adjusts adjacent wording to match. Patch below. Bug link: https://bugs.openjdk.java.net/browse/JDK-8180137 Thanks, s'marks # HG changeset patch # User smarks # Date 1494544788 25200 # Thu

JDK 9 RFR(xs): 8180128: small errors in String javadoc

Hi all, Please review a couple really small fixes to the String javadoc. 1) The String(byte[], int, int, int) constructor refers to converting bytes to chars as specified "in the method above" except that the method "above" has never converted bytes to chars as far as I can see. It really

JDK 9 RFR(m): 8150488: Scanner.findAll() can return infinite stream if regex matches zero chars

Hi all, Please review this fix [1] for JDK-8150488 [2] to prevent Scanner.findAll() from returning an infinite stream of zero-length matches in certain cases. This was previously an issue that simply documented this limitation. In the review for that issue [3], Timo K convinced me that this

Re: JDK 9 RFR(s): 8167981: Optional: add notes explaining intended use

On 4/20/17 10:03 AM, Martin Buchholz wrote: This looks good. I don't think there's any need anymore to have fully qualified class names in @links, so just: {@link #orElseGet(Supplier) orElseGet} (but there's a global cleanup there) Thanks for reviewing. Yes, "java.util.function.Supplier"

Re: JDK 9 RFR(s): 8167981: Optional: add notes explaining intended use

e alternative of returning Double,not double. “… and where using the default value (@code {0.0d}) is likely to cause errors." ? Paul. (More generally, it seems like Optional would have more value if there was compiler enforcement of its never-null-ness.) On Tue, Apr 18, 2017 at 6:

JDK 9 RFR(s): 8167981: Optional: add notes explaining intended use

Hi all, Please review this small set of non-normative documentation changes for java.util.Optional and related classes. The notes describe the primary intent of Optional to be used as a return value, and recommend avoiding using null as the value of a variable of Optional type. Also, a note

Re: JDK 9 RFR(s): 8177789 fix collections framework links to point to java.util package doc

On 4/15/17 10:34 AM, Martin Buchholz wrote: Just commit your changes; they look fine; we will merge into jsr166 CVS. OK, will do, thanks. I have the usual doc-related gripes ... all the docs for openjdk should be checked into mercurial so they can be maintained along with the classes they

JDK 9 RFR(s): 8177789 fix collections framework links to point to java.util package doc

Hi all, Please review this changeset that fixes up links around the JDK that point to the old Collections technotes/guides area. This changeset points them to the java.util package summary instead. Most of the changes here simply adjust a link location. The file that's different is

Re: JDK 9 RFR(s): 8150488: add note to Scanner.findAll()regardingpossible infinite streams

On 4/6/17 6:38 AM, Timo Kinnunen wrote: IMHO there should be a notice added in findAll which excludes the behavior of the stream after an empty match from any compatibility requirements while the notice remains in place. This would be to ensure that findAll and the stream it returns can be

<    2   3   4   5   6   7   8   9   10   11   >