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 XMLStreamRead

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 st

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 speciali

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 might

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 i

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: 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 i

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 the

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

as starters 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 bu

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

collections, this would help us to make 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 &

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

is my first time here in OpenJDK. Regards! 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

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 argument

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 expo

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 `Un

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

sistent with all these methods seems worse than it being inconsistent with 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 Lide

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 unmodifiab

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: 6415694 Clarification in Javadoc for java.rmi.AlreadyBoundException

s Jay -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'

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

gical performance issue that's being mitigated. s'marks [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 Meh

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 b

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 othe

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 confo

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 on

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 conta

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 pac

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" -> "rele

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 r

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

https://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 i

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

ment to justify “low” 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

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] http://cr.openjdk.java.net/~bpb/824618

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 ver

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 t

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 we

Re: Sometimes constraints are questionable

JDK-8210577) which is that OOME is thrown 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'

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: Final call Re: RFR: JDK-8230744 Several classes throw OutOfMemoryError without message

.html> On Jun 3, 2020, at 11:24 AM, Jim Laskey wrote: It's not the goal or role of 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

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 t

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: 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 s

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: http:

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: http://cr.openjdk.java.nhet/~darcy/

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 Ma

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&pr=87&rang

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

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 -

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

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&pr=137&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253066 Stats: 1 line in 1 file change

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

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)

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 p

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 tim

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 // met

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 implementation

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 dese

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: https:

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:

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

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. >> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-A

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 Collect

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 d

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 d

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 directly

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

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 direc

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: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 > Forax](https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14171626&page=com.atlassian.ji

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&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#

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

this method is indeed quite convenient (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: Mer

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

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&pr=1274&range=00 Issue: https

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 inheri

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

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 [v3]

this method is indeed quite convenient (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: Adj

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, somet

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 shouldn

RFR (s): 8217412 deprecate rmic for removal

Hi all, Please review this patch and CSR request for upgrading the deprecation status of the rmic to from ordinary to terminal (i.e., conceptually set forRemoval=true, though there are no actual annotations involved here). There are no code changes, just documentation changes and changes to t

RFR(xs): 8225315 test java/util/ArrayDeque/WhiteBox.java isn't part of the jdk_collections test group

Hi all, This test was added some time ago, but it wasn't added to the jdk_collections test group. Please review the patch appended below, which adds it to the right group. (The test was still run as part of the catch-all jdk_util_other group though.) Bug link: https://bugs.openjdk.java.net/b

Re: RFR(xs): 8225315 test java/util/ArrayDeque/WhiteBox.java isn't part of the jdk_collections test group

On 6/4/19 5:56 PM, Joseph D. Darcy wrote: Should the test be removed from the catch-all group as part of this change? Ah, good question. But the answer is that it doesn't need to be. The "catch-all" group jdk_util_other is defined thus: -- # All util components not part of some other util c

RFR(s): 8205131: remove Runtime trace methods

Hi all, Please review this changeset and CSR request that remove the traceInstructions() and traceMethodCalls() methods from java.lang.Runtime. These methods have been deprecated for removal since Java 9, and they do nothing. I've also removed a couple mentions of these methods from some tests

Re: RFR JDK-8225339 Optimize HashMap.keySet()/HashMap.values()/HashSet toArray() methods

On 6/5/19 7:27 AM, Claes Redestad wrote: On 2019-06-05 15:49, Tagir Valeev wrote: In particular it's never mentioned in HashSet, HashMap or Collection spec that toArray implements a fail-fast behavior: this is said only about the iterator() method. that's not entirely true, since the @imp

Re: RFR JDK-8225339 Optimize HashMap.keySet()/HashMap.values()/HashSet toArray() methods

On 6/5/19 9:25 PM, Tagir Valeev wrote: Thanks for review. Indeed, you have a point about behavioral change. I filed a CSR: https://bugs.openjdk.java.net/browse/JDK-8225393 Great, I've made some edits to the CSR and I've added myself as a reviewer. It should be ready for you to move into the F

Re: Suggestion for a more sensible implementation of EMPTY_MAP

On 6/10/19 7:34 AM, Abraham Marín Pérez wrote: I agree that it makes sense for EMPTY_MAP to have the same logic as Map.of() or unmodifiable(new HashMap()), which means that my suggestion cannot be applied to just EMPTY_MAP... but maybe that’s ok: maybe we can change all of them? If we keep

Re: Kind reminder about JDK-8193031

Hi Sergey, There are some links to a few other discussion threads in the bug report [1]. I've added a link to this one. :-) It's too late for JDK 13, which entered RDP1 today. However, the JDK 14 source base is open, and we can proceed there. In one of the previous discussions, I had sugges

Re: RFR JDK-8225339 Optimize HashMap.keySet()/HashMap.values()/HashSet toArray() methods

Hi Tagir, I reviewed your latest changeset and it looks fine. I ran the changes through our internal test system and the results look good. Since the CSR was approved for JDK 14, and the mainline is now JDK 14 (after the JDK 13 RDP1 fork), you can now push this changeset. Thanks, s'marks O

Re: Kind reminder about JDK-8193031

On 6/13/19 7:48 PM, Tagir Valeev wrote: If ArrayList is the collection which could mostly benefit from this, why not peel off this case and provide special path for ArrayList only? Seems like a reasonable compromise! I'd be interested in what others think. Personally I've never used Collection

Re: Inputs on patch for JDK-8225763? Inflater and Deflater should implement AutoCloseable

On 6/26/19 9:28 PM, Jaikiran Pai wrote: I am looking to contribute a patch for the enhancement noted in https://bugs.openjdk.java.net/browse/JDK-8225763. The change itself looks relatively straightforward to me and here's what I plan to do: 1. Have both java.util.zip.Inflater and java.util.zip.D

Re: RFR (XS) 8224849 : Flag (?U:...) is allowed for non-capturing groups

Hi Ivan, I think this fix is correct and clearly the spec needed to be fixed. Since it is a change to the normative portion of the spec, though, it needs a CSR. This is probably mostly a formality to make sure the change is tracked for TCK purposes. Can you file a CSR for this please? Let me

Re: Suggestion for a more sensible implementation of EMPTY_MAP

On 6/19/19 12:51 AM, Abraham Marín Pérez wrote: private void decorate(Map data) { //... data.computeIfPresent("field", (k, v) -> highlightDifferences(v, otherValue)); //... } At one point an emptyMap() was passed to this method, causing an UOE. [...] On the face of it, the d

Re: EnumSet.class serialization broken - twice

Arh. Yet another serialization bug. But yes, this is a bug. Thanks for finding and diagnosing it. Like Martin, I've often forgotten that classes themselves can be included in a serial stream, as well as instances of those classes. In fact I seem to recall arguing that because EnumSet u

Re: RFR (XS) 8224849 : Flag (?U:...) is allowed for non-capturing groups

On 6/27/19 2:43 PM, Ivan Gerasimov wrote: Yes, good point about the spec change. Here's the CSR filed: https://bugs.openjdk.java.net/browse/JDK-8226914 Can you please review it at your convenience? Thanks for filing this. I've made some minor edits and have marked it reviewed. Note that when

Re: EnumSet.class serialization broken - twice

the above will result in consistent EnumSet.serialVersionUID values for JDK 8 LTS, JDK 11 LTS, and current JDK releases, without having to worry about spec changes for any of the past releases. Let me know how you'd like to proceed. I'm happy to help out with reviewing, filing

Re: Inputs on patch for JDK-8225763? Inflater and Deflater should implement AutoCloseable

ined" issue. If it's simple, great, I'd like to see it happen. But if it leads you off into the weeds, then feel free to drop it. Note: US holiday weekend coming up; replies might take several days. s'marks On 6/29/19 4:16 AM, Jaikiran Pai wrote: On 29/06/19 4:31 PM, Jaiki

Re: EnumSet.class serialization broken - twice - JDK-8227368

ojects/jdk/13/ On 7/7/19 8:11 AM, Peter Levart wrote: On 7/7/19 4:31 PM, Peter Levart wrote: On 6/29/19 2:00 AM, Stuart Marks wrote: Daniel Fuchs pointed me to a weird thing they had to do with the serialVersionUID in one of the JMX classes: https://hg.openjdk.java.net/jdk/jdk/fil

Re: EnumSet.class serialization broken - twice - JDK-8227368

ization compatibility with JDK 8 (see JDK-8227368) might be sufficient. Otherwise, webrev.01 looks fine. On 7/9/19 1:57 AM, Stuart Marks wrote: 2. Create draft CSR. Created: https://bugs.openjdk.java.net/browse/JDK-8227432 I've done some editing on this CSR and I've marked myself as a

  1   2   3   4   5   6   7   8   9   10   >