Re: RFR: 8180352: Add Stream.toList() method [v3]

On Sat, 21 Nov 2020 11:02:27 GMT, Rémi Forax wrote: >> Stuart Marks has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Adjust List.copyOf to null-check and copy allowNulls lists. >> Fix equals, hashCode,

Re: RFR: 8180352: Add Stream.toList() method [v3]

On Sat, 21 Nov 2020 10:58:49 GMT, Rémi Forax wrote: >> It's an implementation invariant that the internal array be Object[]. Having >> it be something other than Object[] can lead to subtle bugs. See >> [JDK-6260652](https://bugs.openjdk.java.net/browse/JDK-6260652) for example. > > you can

Re: RFR: 8180352: Add Stream.toList() method [v3]

On Mon, 23 Nov 2020 14:06:02 GMT, sergus13 wrote: >> This implementation duplicates the array twice, once in this.toArray() and >> once in the constructor of ArrayList that calls toArray() on >> Collections.ArrayList. >> >> I'm sure there is a better way > > In `ReferencePipeline` class we

Re: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed,… [v2]

On Fri, 20 Nov 2020 19:59:52 GMT, Mandy Chung wrote: >> Alan Bateman has updated the pull request with a new target base due to a >> merge or a rebase. The incremental webrev excludes the unrelated changes >> brought in by the merge/rebase. The pull request contains four additional >> commits

Integrated: 8037384: Fix wording in Javadoc of java.io.Serializable

On Thu, 19 Nov 2020 03:44:10 GMT, Stuart Marks wrote: > 8231547: Serializable class doc should link to serialization specification > > Rewrite a couple confusing sentences in the Serializable class doc. This does > affect normative text, but the edits are primarily to focus

Re: RFR: 8037384: Fix wording in Javadoc of java.io.Serializable [v2]

On Thu, 19 Nov 2020 17:11:04 GMT, Chris Hegarty wrote: >> Stuart Marks has updated the pull request incrementally with one additional >> commit since the last revision: >> >> non-serializable classes => non-serializable superclasses > > src/java.base/share/

Re: RFR: 8037384: Fix wording in Javadoc of java.io.Serializable [v2]

es. Thus, a CSR request shouldn't be > required for this change. > > Also add and adjust some links and link markup to the Java Object > Serialization Specification. Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: non-

Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly [v13]

On Thu, 19 Nov 2020 00:58:21 GMT, Ian Graves wrote: >> The `java.util.Formatter` format specifies support for field widths, >> argument indexes, or precision lengths of a field that relate to the >> variadic arguments supplied to the formatter. These numbers are specified by >> integers,

RFR: 8037384: Fix wording in Javadoc of java.io.Serializable

8231547: Serializable class doc should link to serialization specification Rewrite a couple confusing sentences in the Serializable class doc. This does affect normative text, but the edits are primarily to focus and clarify the text, not to make any semantic changes. Thus, a CSR request

Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly [v12]

On Wed, 18 Nov 2020 22:57:19 GMT, Ian Graves wrote: >> The `java.util.Formatter` format specifies support for field widths, >> argument indexes, or precision lengths of a field that relate to the >> variadic arguments supplied to the formatter. These numbers are specified by >> integers,

Re: RFR: 8180352: Add Stream.toList() method [v3]

onvenient (if the caller can deal with > what this operation returns), as collecting into a List is the most common > stream terminal operation. Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: Adjust List.copyOf to null-check and co

Integrated: 8256152: tests fail because of ambiguous method resolution

On Tue, 17 Nov 2020 20:01:37 GMT, Stuart Marks wrote: > Added a cast in the right place, thanks to @jonathan-gibbons. This pull request has now been integrated. Changeset: 646c2002 Author: Stuart Marks URL: https://git.openjdk.java.net/jdk/commit/646c2002 Stats: 1 line in 1 f

Re: RFR: 8180352: Add Stream.toList() method [v2]

On Tue, 17 Nov 2020 20:04:58 GMT, Stuart Marks wrote: >>> @plevart wrote: >>> >>> > But the question is how does having a separate CollSer.IMM_LIST_NULLS >>> > type prevent that from happening? >>> >>> When a serialized list wit

Re: RFR: 8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly [v9]

On Tue, 17 Nov 2020 21:21:47 GMT, Roger Riggs wrote: >> Ian Graves has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Adding test coverage. Tweaking wording in docs. > > test/jdk/java/util/IllegalFormatException/ArgumentIndexException.java

Re: RFR: 8256152: tests fail because of ambiguous method resolution [v2]

> Added a cast in the right place, thanks to @jonathan-gibbons. Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: cast to double instead of Object - Changes: - all: https://git.openjdk.java.net/jdk/pull/1274/fi

Re: RFR: 8180352: Add Stream.toList() method [v2]

On Tue, 10 Nov 2020 09:34:56 GMT, Peter Levart wrote: >> I can see that having a separate IMM_LIST_NULLS type might be necessary to >> preserve the allows-null/disallows-null behaviour of indexOf and lastIndexOf >> methods... >> >> NOTE ALSO that ListN.equals(o) and ListN.hashCode() are

RFR: 8256152: tests fail because of ambiguous method resolution

Added a cast in the right place, thanks to @jonathan-gibbons. - Commit messages: - 8256152: tests fail because of ambiguous method resolution Changes: https://git.openjdk.java.net/jdk/pull/1274/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=1274=00 Issue:

Re: RFR: 8180352: Add Stream.toList() method [v2]

On Sun, 8 Nov 2020 15:55:58 GMT, Peter Levart wrote: >> Hi Stuart, >> >> I would like to discuss the serialization. You introduce new >> CollSer.IMM_LIST_NULLS type of immutable collection. This means that if this >> change goes into JDK16 for example, JDK15 and before will not be able to >>

Re: RFR: 8180352: Add Stream.toList() method [v2]

onvenient (if the caller can deal with > what this operation returns), as collecting into a List is the most common > stream terminal operation. Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: Merge ListNNullsAllowed into ListN. Upda

Re: RFR: 8180352: Add Stream.toList() method

On Fri, 6 Nov 2020 03:01:42 GMT, Stuart Marks wrote: >> Looking at the linked issue, I see [this comment from Rémi >> Forax](https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14171626=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comm

Re: RFR: 8180352: Add Stream.toList() method

On Wed, 4 Nov 2020 23:18:29 GMT, Paŭlo Ebermann wrote: >> Changes requested by orio...@github.com (no known OpenJDK username). > > Looking at the linked issue, I see [this comment from Rémi >

Re: RFR: 8180352: Add Stream.toList() method

On Thu, 5 Nov 2020 19:47:43 GMT, Paul Sandoz wrote: >> This change introduces a new terminal operation on Stream. This looks like a >> convenience method for Stream.collect(Collectors.toList()) or >> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this >> method directly

Re: RFR: 8180352: Add Stream.toList() method

On Wed, 4 Nov 2020 23:03:02 GMT, Paŭlo Ebermann wrote: >> This change introduces a new terminal operation on Stream. This looks like a >> convenience method for Stream.collect(Collectors.toList()) or >> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this >> method

Re: RFR: 8180352: Add Stream.toList() method

On Wed, 4 Nov 2020 09:46:32 GMT, Zheka Kozlov wrote: >> This change introduces a new terminal operation on Stream. This looks like a >> convenience method for Stream.collect(Collectors.toList()) or >> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this >> method

Re: RFR: 8180352: Add Stream.toList() method

On Tue, 3 Nov 2020 18:53:23 GMT, Stuart Marks wrote: >> Should there be a test that tests the default implementation in >> `j.u.s.Stream`? Or maybe there is and I missed that? > > @dfuch wrote: >> Should there be a test that tests the default implementation in >

Re: RFR: 8180352: Add Stream.toList() method

On 11/3/20 3:10 AM, Florian Weimer wrote: I'd expect a test here that if the list contains a null element, `List::copyOf` throws `NullPointerException`. The new Stream.toList() actually permits null elements (by design) so it goes through a different path than List::copyOf. The new tests'

Re: RFR: 8180352: Add Stream.toList() method

On Tue, 3 Nov 2020 10:06:26 GMT, Daniel Fuchs wrote: >> This change introduces a new terminal operation on Stream. This looks like a >> convenience method for Stream.collect(Collectors.toList()) or >> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this >> method

Re: RFR: 8180352: Add Stream.toList() method

On Tue, 3 Nov 2020 11:05:21 GMT, Stephen Colebourne wrote: >> This change introduces a new terminal operation on Stream. This looks like a >> convenience method for Stream.collect(Collectors.toList()) or >> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this >> method

Re: RFR: 8180352: Add Stream.toList() method

On Tue, 3 Nov 2020 10:58:25 GMT, Stephen Colebourne wrote: >> This change introduces a new terminal operation on Stream. This looks like a >> convenience method for Stream.collect(Collectors.toList()) or >> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this >> method

RFR: 8180352: Add Stream.toList() method

This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]

On Wed, 21 Oct 2020 02:28:30 GMT, Kim Barrett wrote: >> Finally returning to this review that was started in April 2020. I've >> recast it as a github PR. I think the security concern raised by Gil >> has been adequately answered. >>

Re: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]

On Sat, 24 Oct 2020 22:22:56 GMT, Peter Levart wrote: >> Reference instances should not be leaked and so I don't see very common that >> caller of `Reference::get` does not know the referent's type. It also >> depends on the `refersTo` check against `null` vs an object. Any known use >>

Integrated: 8255016: ConstantDescs.FALSE claims it represents TRUE

On Mon, 19 Oct 2020 18:08:28 GMT, Stuart Marks wrote: > This is a fix for "just a typo" or copy/paste error, but it probably requires > a CSR since it changes a normative > portion of the spec. This pull request has now been integrated. Changeset: bf19581a Author:

RFR: 8255016: ConstantDescs.FALSE claims it represents TRUE

This is a fix for "just a typo" or copy/paste error, but it probably requires a CSR since it changes a normative portion of the spec. - Commit messages: - 8255016: ConstantDescs.FALSE claims it represents TRUE Changes: https://git.openjdk.java.net/jdk/pull/744/files Webrev:

Re: RFR: 8254161: Prevent instantiation of EnumSet subclasses through deserialization

On Mon, 12 Oct 2020 13:47:46 GMT, Chris Hegarty wrote: > TL;DR add EnumSet::readObjectNoData() > > EnumSet is an exemplar of the Serialization Proxy Pattern. As such, it > should strictly implement that pattern and demonstrate how best to > defend against inappropriate instantiation through

Re: RFR: 8247402: rewrite the implementation requirements for Map::compute()

On Tue, 13 Oct 2020 13:35:37 GMT, Pavel Rappo wrote: >> The proposed implementation behaves differently from the existing >> implementation in the case of `null` value. That is, >> when `map.containsKey(key) == true && map.get(key) == null`. The difference >> is that the proposed

Re: RFR 8253451: Performance regression in java.util.Scanner after 8236201

Hi Martin, Overall it seems reasonable to replace the \x{HH} construct with a simpler escape sequence. I'm a bit surprised to see the performance impact, but you noticed it, so I'll buy that it's significant. // These must be literalized to avoid collision with regex //

Re: RFR: 8252999: Cleanup: replace .equals("") with .isEmpty() within all codebase

On Fri, 11 Sep 2020 15:17:58 GMT, Bradford Wetmore wrote: >> Ok, sorry for the distraction. > > Our local Santuario maintainer says: > > In general, changes to Apache Santuario should also be made at Apache so we > stay in sync. Hi @doom369, I hope we didn't end up wasting too much of your

Re: 'Find' method for Iterable

On 9/16/20 1:59 PM, Remi Forax wrote: - Mail original - De: "Nir Lisker" À: "core-libs-dev" Envoyé: Lundi 14 Septembre 2020 20:56:27 Objet: 'Find' method for Iterable Hi, This has probably been brought up at some point. When we need to find an item in a collection based on its

Re: RFR: 8252730: jlink does not create reproducible builds on different servers

On Mon, 14 Sep 2020 20:35:24 GMT, Ian Graves wrote: > Related to [JDK-8252730 jlink does not create reproducible builds on different > servers](https://bugs.openjdk.java.net/browse/JDK-8252730). Introduces > ordering based on `Archive` module names to > ensure stable files (and file signatures)

Integrated: 8253066: typo in Stream.mapMulti

On Fri, 11 Sep 2020 22:20:48 GMT, Stuart Marks wrote: > A simple typo fix. This pull request has now been integrated. Changeset: b1b0f0b2 Author: Stuart Marks URL: https://git.openjdk.java.net/jdk/commit/b1b0f0b2 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8253066: t

RFR: 8253066: typo in Stream.mapMulti

A simple typo fix. - Commit messages: - fix typo in Stream.mapMulti Changes: https://git.openjdk.java.net/jdk/pull/137/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=137=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253066 Stats: 1 line in 1 file changed: 0

Re: RFR: 8251495: Clarify DOM documentation

On Wed, 9 Sep 2020 22:56:14 GMT, Joe Wang wrote: > Revert changes made by JDK-8249643, removing the implNote. Marked as reviewed by smarks (Reviewer). - PR: https://git.openjdk.java.net/jdk/pull/100

Integrated: 8157729: examples in LinkedHashMap and LinkedHashSet class doc use raw types

On Tue, 8 Sep 2020 22:32:47 GMT, Stuart Marks wrote: > Add some generics and wrap in `{@code}` to protect angle brackets. This pull request has now been integrated. Changeset: 30fa8d5d Author: Stuart Marks URL: https://git.openjdk.java.net/jdk/commit/30fa8d5d Stats: 10 lines i

Re: RFR: 8157729: examples in LinkedHashMap and LinkedHashSet class doc use raw types [v2]

> Add some generics and wrap in `{@code}` to protect angle brackets. Stuart Marks has updated the pull request incrementally with one additional commit since the last revision: Update copyright years. - Changes: - all: https://git.openjdk.java.net/jdk/pull/87/files -

Re: RFR: 8157729: examples in LinkedHashMap and LinkedHashSet class doc use raw types [v2]

On Tue, 8 Sep 2020 22:58:58 GMT, Lance Andersen wrote: >> Stuart Marks has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update copyright years. > > Marked as reviewed by lancea (Reviewer). Aha, I knew I f

RFR: 8157729: examples in LinkedHashMap and LinkedHashSet class doc use raw types

Add some generics and wrap in `{@code}` to protect angle brackets. - Commit messages: - 8157729: examples in LinkedHashMap and LinkedHashSet class doc use raw types Changes: https://git.openjdk.java.net/jdk/pull/87/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk=87=00

Re: RFR: 8252830: Correct missing javadoc comments in java.rmi module [v3]

On Tue, 8 Sep 2020 19:44:21 GMT, Roger Riggs wrote: >> 8252830: Correct missing javadoc comments in java.rmi module > > Roger Riggs has updated the pull request incrementally with one additional > commit since the last revision: > > Added java.io.Serial to java.rmi.activation.ActivationID

Re: JDK 16 RFR of 8250580: Address reliance on default constructors in java.rmi

Looks good Joe, thanks for doing this cleanup. CSR request reviewed. s'marks On 7/24/20 7:45 PM, Joe Darcy wrote: Hello, Another bug in the quest to remove use of default constructors in the JDK's public API, this time in the java.rmi module:     webrev:

Re: RFR [15/java.xml] 8248884: Regression caused by the update to BCEL 6.0

On 7/6/20 4:37 PM, huizhe.w...@oracle.com wrote: Please refer to the previous review for 8248348. This patch should have been pushed into 15 in the first place. I hope a merge with 16 repo won't cause any trouble/conflict. JBS: https://bugs.openjdk.java.net/browse/JDK-8248884 webrev:

Re: RFR [16/java.xml] 8248348: Regression caused by the update to BCEL 6.0

An unconventional patch over an unusual hashcode/equals implementation is a bit too controversial. I'd like to propose a new patch that focus on the problem at hand, that is re-setting the opcode causes the item in HashSet to get lost because of the changed hash bucket. This patch therefore

Re: RFR [16/java.xml] 8248348: Regression caused by the update to BCEL 6.0

On 6/25/20 4:53 PM, Joe Wang wrote: Please review a fix to a BCEL regression. At issue was the addition of hashCode() method to Instruction.java in BCEL 6.0. This hashCode() method was implemented to return the instruction's opcode that unfortunately is mutable. The problem hasn't showed up

Re: Sometimes constraints are questionable

On 6/5/20 1:48 PM, James Laskey wrote: I’m fixing the two in java.base. The other two are in different modules and would require changes to export. So you can file on those. I've filed https://bugs.openjdk.java.net/browse/JDK-8247373 to enhance the exception message, docs, and to add a

Re: Final call Re: RFR: JDK-8230744 Several classes throw OutOfMemoryError without message

this bug to fix the wrongs of the past, merely add error messages to the exceptions. I raised the discussion as an issue. Clearly there is a correct path to follow. If you think more effort is required then file a bug. :-) Cheers, -- Jim On Jun 2, 2020, at 7:13 PM, Stuart Marks wr

Re: Sometimes constraints are questionable

On 6/3/20 10:36 AM, Stuart Marks wrote: 3) Integer wraparound/overflow during size computation. AS.newLength generates this:     OutOfMemoryError: Required array length too large (3) is the only case generated by the library. In fact, AS.hugeLength() has oldLength and minGrowth

Re: Sometimes constraints are questionable

wn not only when the system is out of memory, but also when some implementation limit is exceeded, whether that limit is in the JVM or in the library. Maybe we should update the documentation of java.lang.OutOfMemoryError to mention this. s'marks Cheers, -- Jim On Jun 2, 202

Re: Sometimes constraints are questionable

On 6/2/20 11:49 PM, David Holmes wrote: IIUC what you are saying is that MAX_ARRAY_LENGTH is treated as a soft-limit. A request for prefGrowth won't be allowed to exceed it. But if minGrowth takes the length passed it then the code tries to do the allocation that large anyway. If it succeeds

Re: Sometimes constraints are questionable

Hi Jim, This was mentioned previously in this thread but not discussed very much. I suggest you take a look at jdk.internal.util.ArraysSupport.newLength(). Ivan Gerasimov and I worked this over fairly closely last year, and I'm pretty sure it does what Martin is saying, which I also think is

Re: RFR: JDK-8230744 Several classes throw OutOfMemoryError without message

On 6/2/20 6:52 AM, Jim Laskey wrote: Revised to reflect requested changes. http://cr.openjdk.java.net/~jlaskey/8230744/webrev-01/index.html On this, if all you're doing is changing exception messages, then I don't care

Re: 8246183: Scanner/ScanTest.java fails due to SIGSEGV in StubRoutines::jshort_disjoint_arraycopy

OK, looks good. Thanks for jumping on this quickly. s'marks On 5/29/20 7:01 PM, Brian Burkhalter wrote: Please review this fix [1] for [2]. It in effect just backs out the recent fix for [3]. I’ll investigate the root cause next week. Thanks, Brian [1]

Re: RFR 15 (S): 8245068: Implement Deprecation of RMI Activation

for the compatibility impact for the JCK folks. I added myself as a reviewer. Release Note: https://bugs.openjdk.java.net/browse/JDK-8246021 Looks fine. Best,  Lance Thanks, s'marks On 5/26/20 12:35 PM, Stuart Marks wrote: Hi all, Here's the implementation of the recently-post

Re: RFR 15 (S): 8245068: Implement Deprecation of RMI Activation

://bugs.openjdk.java.net/browse/JDK-8246021 Thanks, s'marks On 5/26/20 12:35 PM, Stuart Marks wrote: Hi all, Here's the implementation of the recently-posted JEP 385, deprecation of RMI Activation for removal. I'm listing this as S ("small") since conceptually it's fairly sma

Re: RFR 15 (S): 8245068: Implement Deprecation of RMI Activation

Hi Lance, thanks for taking a look at this. On 5/27/20 4:56 AM, Lance Andersen wrote: I think this looks good.  I will add myself as a reviewer for the CSR. I would probably create an issue for the release note and create a draft I believe I was asked for that when I was going through my CSR

Re: RFR 15 (S): 8245068: Implement Deprecation of RMI Activation

On 5/27/20 6:34 AM, Roger Riggs wrote: rmid.properties: 134;  avoid breaking "have\n been" in to separate lines. I would break after the ",". Line break adjusted. module-info.java: 35:  "version" -> "release" for consistency across the messages. package-info.java: 41:  "version" ->

RFR 15 (S): 8245068: Implement Deprecation of RMI Activation

Hi all, Here's the implementation of the recently-posted JEP 385, deprecation of RMI Activation for removal. I'm listing this as S ("small") since conceptually it's fairly small, though there are rather a large number of files changed. Essentially the changes are: - java.rmi.activation

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

The containsAll() and equals() methods both use the membership contract of the receiver, not the argument. Unfortunately, the equals() specification says,    Returns true if the specified object is also a set, the two sets have the    same size, and every member of the specified set is

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

On 5/9/20 7:48 PM, Alan Snyder wrote: A small point… you might want to reconsider your analysis of Set.copyOf(), as it is a static method and there is no receiver. Of course there is no receiver. For static factory methods, and for constructors, I meant the newly created instance is the

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

You say: The issue of membership semantics is part of the original design. I agree, but only to the point of identifying inconsistent membership semantics as a source of non-conformance. What is not part of the original design is allowing a broader range of membership semantics to be

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

On 5/8/20 6:46 PM, Jason Mehrens wrote: I assume Deque/Queue would suffer the same issue as List. It would be nice to some how ensure ArrayDeque.contains is not called as far as the heuristic goes. Looks like PriorityQueue uses equals for contains but that is not to say there are not

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

On 5/6/20 5:05 PM, Alan Snyder wrote: Let me clarify. I was referring to the non-support by the framework, which restricts membership semantics: ...[specification text regarding equals()]... OK, thanks for the clarification. Although the framework provides implementation classes that MAY

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

[1] https://codeblog.jonskeet.uk/2010/07/29/there-s-a-hole-in-my-abstraction-dear-liza-dear-liza/   Alan On May 4, 2020, at 5:25 PM, Stuart Marks <mailto:stuart.ma...@oracle.com>> wrote: On 5/1/20 10:41 PM, Jason Mehrens wrote: 1. I assume you are using "c instanceof List" in

Re: RFR: 6415694 Clarification in Javadoc for java.rmi.AlreadyBoundException

-Stuart Marks wrote: - To: Jayashree Sk1 From: Stuart Marks Date: 05/01/2020 09:32AM Cc: core-libs-dev@openjdk.java.net Subject: [EXTERNAL] Re: RFR: 6415694 Clarification in Javadoc for java.rmi.AlreadyBoundException Hi Jay, OK, welcome! I'll sponsor this changeset for you. It's pretty simple

Re: [15] RFR: 8244459: Optimize the hash map size in LocaleProviderAdapters

Hm, interesting, good catch Peter! Very subtle. The time-honored (int) (expected / 0.75f) + 1 appears in several places around the JDK. I think most people (including me) just copy it, because it's "good enough" for most cases. I'm a little concerned about (expectedSize * 4 + 2) / 3

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

On 5/1/20 10:41 PM, Jason Mehrens wrote: 1. I assume you are using "c instanceof List" instead of "!(c instanceof Set)" to correctly handle IdentitityHashMap.values()? The instanceof List seems like safe choice but it is too bad we can still fool that check by wrapping List as an

Re: RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

the less commonly used TreeSet.retainAll. The conclusion is that I think it would be better if TreeSet or AbstractSet gets an implementation of removeAll which iterates over the argument collection. Best regards, Jens Lideström [1]: https://mail.openjdk.java.net/pipermail/core-libs-dev/2019-July

Re: Collections.synchronizedXXX() and internal mutex (aka SyncRoot)

On 5/1/20 2:02 AM, dmytro sheyko wrote: The checked, synchronized and unmodifiable wrappers in some cases store backing collection in more than one fields. Thus `UnmodifiableList` has 1. its own field `List list` and 2. `Collection c`, which it inherits from `UnmodifiableCollection`. Also

Re: RFR: 6415694 Clarification in Javadoc for java.rmi.AlreadyBoundException

community members. s'marks On 5/1/20 7:57 AM, Roger Riggs wrote: +1, BTW, Stuart you are a Reviewer, no need for a 2nd. Roger On 5/1/20 12:02 AM, Stuart Marks wrote: Hi Jay, OK, welcome! I'll sponsor this changeset for you. It's pretty simple, so I'll just paste the exported changeset below

RFR [15] 6394757: rev2: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

Hi all, I'm taking another swing at this one. I've taken a minimal approach compared to my previous proposals. Briefly, AbstractSet.removeAll switches from iterating this collection and calling contains() on its argument, to iterating the argument and calling this.contains(), if the

Re: RFR: 6415694 Clarification in Javadoc for java.rmi.AlreadyBoundException

! Jay -Stuart Marks wrote: - To: Jayashree Sk1 From: Stuart Marks Date: 04/30/2020 09:22AM Cc: core-libs-dev@openjdk.java.net Subject: [EXTERNAL] Re: RFR: 6415694 Clarification in Javadoc for java.rmi.AlreadyBoundException The change looks fine. Although this is in a normative portion

Re: Collections.synchronizedXXX() and internal mutex (aka SyncRoot)

the fixes more localized and hence safe. That's why I would like to know the reason, why this has not been done earlier, and is there hope/plan this will be done in near future. Thank you, Dmytro On Thu, Apr 30, 2020 at 6:36 AM Stuart Marks <mailto:stuart.ma...@oracle.com>> wro

Re: RFR: 7147994 Hashtable rehash‎(‎) javadoc describes implementation details

to understand the contribution process) Regards! Jay -Stuart Marks wrote: - To: Jayashree Sk1 From: Stuart Marks Date: 04/30/2020 09:53AM Cc: core-libs-dev@openjdk.java.net Subject: [EXTERNAL] Re: RFR: 7147994 Hashtable rehash‎(‎) javadoc describes implementation details The bug report states

Re: RFR: 7147994 Hashtable rehash‎(‎) javadoc describes implementation details

The bug report states that this method specification describes implementation details, with the implication that implementation details should be avoided and that abstract specifications (contracts or invariants) should be provided instead. The alternative wording from the bug report removes

Re: RFR: 6415694 Clarification in Javadoc for java.rmi.AlreadyBoundException

The change looks fine. Although this is in a normative portion of the specification, the nature of the change is purely editorial, so I don't think it needs a CSR. Do you need a sponsor? s'marks On 4/29/20 2:57 AM, Jayashree Sk1 wrote: Hi All, Please find the below changes for the

Re: Collections.synchronizedXXX() and internal mutex (aka SyncRoot)

Hi Dmytro, Callers of an API performing explicit synchronization, along with the synchronized collections wrappers, have mostly fallen into disuse since the introduction of the java.util.concurrent collections. Multiple threads can either interact directly on a concurrent collection, or the

Re: LinkedHashMap/LinkedHashSet enhancement: OrderedMap/OrderedSet

On 4/28/20 9:48 PM, Jason Mehrens wrote: Looks like It is intentional that unmodifiable queues are not present. See: https://bugs.openjdk.java.net/browse/JDK-5030930. The same logic would have been used for when Deque was added in the following release. Good find. Looking at the Queue

Re: LinkedHashMap/LinkedHashSet enhancement: OrderedMap/OrderedSet

Hi Paul, I too hesitate about adding Ordered* interfaces. As I said previously, I don't think they're very useful, and they do seem rather Queue- or Deque-like. Indeed, Tagir was musing the other day on Twitter about a Deque view of LinkedHashSet and possibly LinkedHashMap. I think that

Re: LinkedHashMap/LinkedHashSet enhancement: OrderedMap/OrderedSet

Hi Tagir, A few quick thoughts on this. There does seem to be a conceptual hole here. Most collections implementations have an obvious interface that provides a reasonable abstraction of that implementation. However, one is "missing" for LinkedHashSet, since there's no interface more

Re: Some Classes with a public void close() don't implement AutoCloseable

On 4/22/20 1:42 PM, Joe Darcy wrote: On 4/22/2020 6:12 AM, Alan Bateman wrote: On 22/04/2020 13:50, Andrew Haley wrote: : 1. Should close() always be idempotent, where practical? I would have     thought so, but perhaps there are downsides. 2. Should classes which implement close() with the

Re: Some Classes with a public void close() don't implement AutoCloseable

Hi Johannes, On 4/16/20 3:09 AM, Johannes Kuhn wrote: About java.xml.stream: A XMLStreamReader is for example constructed with:     BufferedReader br = ...;     XMLStreamReader xsr = XMLInputFactory.newDefaultFactory().createXMLEventReader(br); For my IDE this would look like

Re: RFR 15 8242327: List spec should state that unmodifiable lists implement RandomAccess

no assumptions about the identity of the returned instances. * Factories are free to create new instances or reuse existing ones. Therefore, On 4/8/20 2:33 PM, Lance Andersen wrote: Hi Stuart, This looks good On Apr 8, 2020, at 5:01 PM, Stuart Marks <mailto:stuart.ma...@oracle.com>&

RFR 15 8242327: List spec should state that unmodifiable lists implement RandomAccess

Hi all, Please review this small change to the List interface that specifies that unmodifiable lists (returned by List.of et al) implement the RandomAccess marker interface. In fact, they already do; the intent of this section was to specify the user-visible characteristics of such lists, but

Re: JDK 15 RF(pre)R of JDK-8241374: add Math.absExact

Hi Joe, Overall this looks quite good. Thanks for being thorough about this; I certainly would have forgotten about StrictMath. :-) Since this is integer arithmetic, is it true that the StrictMath versions are identical to the Math versions? I have only a couple editorial quibbles. + *

Re: RFR [15] 8161558: ListIterator should not discard cause on exception

On 2/25/20 8:01 AM, fo...@univ-mlv.fr wrote: If the IOOBE is noise, it can be ignored. You are forcing all primary users to ignore something that is useful only for the secondary users. Given that the ratio between primary vs secondary users is at least 100 000 for 1 if not more, that's a

Re: ZoneRules.of() implies that transitionList is a superset of standardOffsetTransitionList but doesn't check that

Was any bug ever filed for this? I looked in JBS and I couldn't find anything that resembled the issue here. Roman, since you don't have an account on JBS (bugs.openjdk.java.net), I'd suggest you file a bug via bugs.java.com. Bugs filed there do eventually get into JBS. (I believe it's

Re: RFR [15] 8161558: ListIterator should not discard cause on exception

On 2/14/20 2:34 PM, fo...@univ-mlv.fr wrote: The thing is that inside the iterator, you already have the right information, so you don't have to pray to have the right info. No, the iterator only can guess at the reason that get() threw the exception. I just disagree on the conclusion,

Re: RFR [15] 8161558: ListIterator should not discard cause on exception

On 2/12/20 2:04 PM, fo...@univ-mlv.fr wrote: I don't disagree with the fact that having the index may help, I disagree with the fact that chaining the IOOBE to the NSEE is the right way to expose that index, crafting an error message with the index is IMO a better idea because you have no

Re: [15] RFR (xs) 8046362 IdentityHashMap.hash comments should be clarified

s '==' which might have as big an impact on performance as sequential vs chained references. Detailed performance comparisons are very difficult given the factors that impact performance, cache sizes, data structure sizes, etc. I'm not sure the wordsmithing adds much to the doc. "JRE" -> &quo

Re: [15] RFR (xs) 8046362 IdentityHashMap.hash comments should be clarified

On 2/10/20 7:52 AM, Martin Buchholz wrote: On Fri, Feb 7, 2020 at 2:47 PM David Holmes wrote: Hi Martin, On 8/02/2020 3:10 am, Martin Buchholz wrote: I explored System.identityHashCode (see below). System.identityHashCode is a VM call that is potentially very expensive. In the

Re: RFR [15] 8161558: ListIterator should not discard cause on exception

Hi Kiran, Thanks for reworking the test. This looks good to me. One small thing: 53 throw new IndexOutOfBoundsException(); This should include the offending index in the IOOBE. This might make Rémi happy. (Then again, it might not.) :-) I think this covers the concerns that

Re: RFR [15] 8161558: ListIterator should not discard cause on exception

Hi Remi, The bug report originally requested that a bunch of different exceptions include a cause. I don't think the cause should be added to all of them. The cases that Kiran is adding are ones where I thought that adding a cause does have value. If someone is using a ListIterator (or a

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