On Tue, 22 Apr 2025 18:56:40 GMT, Stuart Marks wrote:
>> src/java.base/share/classes/java/lang/IO.java line 41:
>>
>>> 39: * The {@link #readln()} and {@link #readln(String)} methods decode
>>> bytes read from
>>> 40: * {@code System.in} into chara
On Wed, 16 Apr 2025 17:37:07 GMT, David Beaumont wrote:
>> Increasing timeout for deadlock detection and adjusting for the timeout
>> factor in higher tiers.
>
> David Beaumont has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Removing test
On Tue, 22 Apr 2025 13:53:14 GMT, Daniel Fuchs wrote:
>> test/jdk/java/util/logging/LoggingDeadlock5.java line 127:
>>
>>> 125: // in higher tiers, so it's necessary to be a bit pessimistic
>>> here.
>>> 126: private final static Duration JOIN_WAIT =
>>> 127: Dur
m encoding
> * Update property test
Stuart Marks has updated the pull request incrementally with one additional
commit since the last revision:
Yet another minor bit of wordsmithing.
-
Changes:
- all: https://git.openjdk.org/jdk/pull/24738/files
- new: https://git.ope
On Thu, 17 Apr 2025 18:59:33 GMT, Stuart Marks wrote:
> * Windows and Unix: set sprops.stdin_encoding if connected to a console
> * Add specs for stdin.encoding
> * Adjust specs to change "undefined" to "unspecified"
> * Rewrite System.in spec to refer to new pr
On Wed, 23 Apr 2025 01:34:42 GMT, Naoto Sato wrote:
>> Stuart Marks has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update sun.stdout/err.encoding comments; tweak Windows file handle
>> variable name.
&g
m encoding
> * Update property test
Stuart Marks has updated the pull request incrementally with one additional
commit since the last revision:
Update sun.stdout/err.encoding comments; tweak Windows file handle variable
name.
-
Changes:
- all: https://git.openjdk.o
On Wed, 23 Apr 2025 12:54:29 GMT, Alan Bateman wrote:
>> src/java.base/share/classes/jdk/internal/util/SystemProps.java line 92:
>>
>>> 90:
>>> 91: // Encoding properties for stdin, stdout, and stderr. For
>>> stdout and stderr,
>>> 92: // check "sun.*.encoding" properties befo
* Windows and Unix: set sprops.stdin_encoding if connected to a console
* Add specs for stdin.encoding
* Adjust specs to change "undefined" to "unspecified"
* Rewrite System.in spec to refer to new property and to clarify usage with
classes that perform encoding
* Update property test
---
s stdin.encoding} property. If this
>> property is not present,
>
> @stuart-marks Are you planning to propose/integrate pull/24738 in advance of
> the JEP update? Asking because this paragraph will need to be adjusted if
> pull/24738 doesn't go in first.
Depends on how close you
On Thu, 17 Apr 2025 23:07:35 GMT, Brian Burkhalter wrote:
>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with two
> additional commits since the last revision:
>
> - 8354724: Increment copyright year in Reader
> - 835
On Wed, 16 Apr 2025 13:20:33 GMT, Alan Bateman wrote:
>> Stuart Marks 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 contai
On Thu, 17 Apr 2025 22:13:06 GMT, Brian Burkhalter wrote:
>> Implement the requested methods and add a test thereof.
>
> Brian Burkhalter has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8354724: Change the test to reuse a ByteBuffer when wr
On Sat, 12 Apr 2025 02:19:35 GMT, Stuart Marks wrote:
> Remove the #ifdef MACOSX from platform-independent System.c, which (on Mac)
> sets native.encoding from sprops.encoding or (on non-Mac Unix and Windows)
> sets native.encoding from sprops.sun_jnu_encoding. After this rem
On Thu, 17 Apr 2025 00:26:49 GMT, Stuart Marks wrote:
>> I belive they can be removed as they are no where used (and I don't think it
>> will be used for `stdin.encoding` either) So I prefer removing those unused
>> code now.
>
> OK, I've done so. Now testing
e other possibilities
> here, such as changing the interface to SetupI18nProps(). I'm open to
> suggestions.
Stuart Marks has updated the pull request incrementally with one additional
commit since the last revision:
Remove encoding parameter from SetupI18nProps.
-
Ch
On Wed, 16 Apr 2025 20:46:04 GMT, Naoto Sato wrote:
>> The main focus of this commit is to straighten out the logic between the
>> platform-specific and platform-independent layers.
>>
>> In the previous state of this file, tracing the origin of the properties on
>> Windows, I ended up followi
On Wed, 16 Apr 2025 14:43:45 GMT, Roger Riggs wrote:
>> Stuart Marks 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 addi
On Tue, 15 Apr 2025 17:12:18 GMT, Naoto Sato wrote:
>> src/java.base/share/native/libjava/System.c line 151:
>>
>>> 149: /* basic encoding properties, always non-NULL */
>>> 150: PUTPROP(propArray, _native_encoding_NDX, sprops->encoding);
>>> 151: PUTPROP(propArray, _sun_jnu_encoding
e other possibilities
> here, such as changing the interface to SetupI18nProps(). I'm open to
> suggestions.
Stuart Marks 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.
On 4/15/25 5:30 AM, Ron Pressler wrote:
On 15 Apr 2025, at 10:51, fo...@univ-mlv.fr wrote:
>> +1 for readAllInputLines() and readInputString() on Process.
Wouldn’t it make more sense to add these to BufferedReader?
Yes. Process already has four Reader-based overloads:
- inputReader()
-
On 4/14/25 11:52 PM, Cay Horstmann wrote:
* How exactly do I use getInputStream()/inputReader() with *extreme care*, as the
API doc warns me?
Ah. This is referring to the following note in the Process.getInputStream()
method spec:
API Note:
Use getInputStream() and inputReader() with
Remove the #ifdef MACOSX from platform-independent System.c, which (on Mac)
sets native.encoding from sprops.encoding or (on non-Mac Unix and Windows) sets
native.encoding from sprops.sun_jnu_encoding. After this removal, the
native.encoding property will be set from sprops.encoding and the
sun
On 4/14/25 1:48 PM, Remi Forax wrote:
From: "Ron Pressler"
This does what you want (and could even be combined to a single expression):
Process p = new ProcessBuilder("ls", "-al").start();
String result = p.inputReader().lines().collect(Collectors.joining("\n"));
and it’s even nicer
On Tue, 8 Apr 2025 08:50:37 GMT, kabutz wrote:
> One of the features of the LinkedBlockingDeque is that it is a doubly-linked
> node queue, with pointers in each node to "prev" and "next", which allows
> remove() in the Iterator to remove the node in constant time. However, in the
> JavaDoc of
On Thu, 10 Apr 2025 22:24:04 GMT, Brent Christian wrote:
>> Certain specific types of tests involving GC and reference processing need
>> to account for the delay between a GC completing (during which the GC clears
>> a Reference), and the Reference being added to its associated queue. At
>> p
On Thu, 10 Apr 2025 22:18:20 GMT, Brent Christian wrote:
>> test/lib/jdk/test/whitebox/WhiteBox.java line 570:
>>
>>> 568:* This method should usually be called after a call to
>>> WhiteBox.fullGC().
>>> 569:*/
>>> 570: public static void waitForReferenceProcessing() {
>>
>> Referenc
On Mon, 7 Apr 2025 18:49:33 GMT, Chen Liang wrote:
>> I used "internal objects" because I wanted to avoid naming concrete classes,
>> which might or might not be used. Previous drafts mentioned BufferedReader,
>> InputStreamReader, and CharsetDecoder.
>>
>> I could replace "internal objects" w
On Fri, 4 Apr 2025 23:42:26 GMT, Stuart Marks wrote:
> Some of the code that creates various encoding properties at JVM
> initialization time, such as file.encoding and native.encoding, could use
> some cleaning up. Cleanup is fairly minimal and should be mostly
> behavior-preserv
On Sat, 5 Apr 2025 02:31:21 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/IO.java line 122:
>>
>>> 120: public static void print(Object obj) {
>>> 121: System.out.print(obj);
>>> 122: System.out.flush();
>>
>> Is it worth using a local variable to avoid cal
On Thu, 10 Apr 2025 18:14:52 GMT, Stuart Marks wrote:
>> Some of the code that creates various encoding properties at JVM
>> initialization time, such as file.encoding and native.encoding, could use
>> some cleaning up. Cleanup is fairly minimal and should be mostly
>
java line 45:
>
>> 43: * UTF-8 is used instead. These internal objects are created upon the
>> first call to
>> 44: * either of the {@code readln} methods and are stored for subsequent
>> reuse by these
>> 45: * methods.
>
> @stuart-marks Can we rephr
On Thu, 10 Apr 2025 18:11:06 GMT, Stuart Marks wrote:
>> src/java.base/share/classes/jdk/internal/util/SystemProps.java line 79:
>>
>>> 77: // Platform defined encodings cannot be overridden on the
>>> command line
>>> 78: put(props, "
On Thu, 10 Apr 2025 08:31:40 GMT, Alan Bateman wrote:
>> Stuart Marks has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix comment from file.encoding to native.encoding
>
> src/java.base/share/classes/jdk/
ng_NDX.
>
> * In SystemProps.Raw.cmdProperties(), adjust the HashMap size computation.
> This should actually avoid resizing of the HashMap (unlike the earlier code).
>
> * Adjust various comments in several places for clarity and correctness.
Stuart Marks has updated the pu
On Wed, 9 Apr 2025 17:02:52 GMT, Stuart Marks wrote:
>> The readln methods handle malformed-input and unmappable-character errors by
>> dropping, and using a replacement value. So erroneous input doesn't throw
>> IOError with a CharacterCodingException as the cause.
On Tue, 8 Apr 2025 11:00:27 GMT, David Beaumont wrote:
> 8353683: j.u.l.Handler classes create deadlock risk via synchronized
> publish() method.
>
> 1. Remove synchronization of calls to publish() in Handlers in
> java.util.logging package.
> 2. Add explanatory comments to various affected me
On Wed, 9 Apr 2025 10:36:53 GMT, Alan Bateman wrote:
>> The IOError was carried over from Console.readLine(), which throws IOError
>> on error. Of course we're decoupled from Console now, but that was the
>> original reason.
>>
>> My guess is that Console methods throw IOError because (a) they
On Wed, 9 Apr 2025 10:46:40 GMT, Alan Bateman wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Rewrite bits about charset decoding, removing mention of "internal
>> objects."
>
> src/java.base/share/classes/java/lang
ng_NDX.
>
> * In SystemProps.Raw.cmdProperties(), adjust the HashMap size computation.
> This should actually avoid resizing of the HashMap (unlike the earlier code).
>
> * Adjust various comments in several places for clarity and correctness.
Stuart Marks has updated the pu
probably fine and less error prone to simply use `synchronized` that
> something more complex.
>
> But, given we'll hopefully have `@StableValue` soon, maybe we could use that?
> What do you think @stuart-marks?
>
> Thanks!
It's even more complex than `volatile`. If a t
On Mon, 7 Apr 2025 17:15:34 GMT, Naoto Sato wrote:
>> Stuart Marks has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix comment from file.encoding to native.encoding
>
> src/java.base/share/native/libjav
On Mon, 7 Apr 2025 19:44:40 GMT, Stuart Marks wrote:
>> Can we rephrase the 1st sentence to read:
>> "The `readln()` and `readln(String)` methods in this class decode bytes read
>> from `System.in` into characters."
>>
>> And remove the last "the
On Mon, 7 Apr 2025 09:18:37 GMT, Alan Bateman wrote:
>> This implementation is not to be emulated by beginners. If an Exception.is
>> thrown here, a user might be tempted to add handlers in their code, while
>> this is an issue with the setup.
>
> Someone is bound to ask why the readln method t
On Sat, 5 Apr 2025 00:55:55 GMT, Luca Kellermann wrote:
>> Jan Lahoda has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Use local variable for System.out in print().
>
> src/java.base/share/classes/java/lang/IO.java line 122:
>
>> 120:
On Thu, 3 Apr 2025 21:03:08 GMT, Stuart Marks wrote:
> Back out commit for
> [JDK-8349206](https://bugs.openjdk.org/browse/JDK-8349206) because of build
> failure.
>
> This reverts commit ebcb9a8b128cc6411610566c8368db63d25a5127.
This pull request has now been integra
Various behavior-preserving code cleanups related to system properties related
to character encodings.
-
Commit messages:
- More minor cleanups, reversion of some extra changes.
- WIP: add some non-null asserts and comments on sprops encoding members
- A couple small tweaks.
- Me
Back out commit for [JDK-8349206](https://bugs.openjdk.org/browse/JDK-8349206)
because of build failure.
This reverts commit ebcb9a8b128cc6411610566c8368db63d25a5127.
-
Commit messages:
- 8353684: BACKOUT 8349206: j.u.l.Handler classes create deadlock risk via
synchronized publish
On Wed, 2 Apr 2025 21:59:32 GMT, David Beaumont wrote:
>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized
>> publish() method.
>>
>> 1. Remove synchronization of calls to publish() in Handlers in
>> java.util.logging package.
>> 2. Add explanatory comments to various affec
On Fri, 11 Oct 2024 15:49:33 GMT, Chen Liang wrote:
>> Please review this patch that:
>> 1. Implemented `forEach` to optimize for 1 or 2 element collections.
>> 2. Implemented `spliterator` to optimize for a single element.
>>
>> The default implementations for multiple-element immutable collect
Hi,
Our goal with the IO class is to have it add as few mechanisms as possible. Anything
it can do, one should easily be able to do with existing classes like PrintStream or
BufferedReader. So, we wouldn't add a varargs method to IO itself without having one
in PrintStream or something.
Now,
On Mon, 3 Mar 2025 10:15:53 GMT, David Beaumont wrote:
>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized
>> publish() method.
>>
>> 1. Remove synchronization of calls to publish() in Handlers in
>> java.util.logging package.
>> 2. Add explanatory comments to various affec
On Thu, 27 Feb 2025 19:43:34 GMT, Liam Miller-Cushon wrote:
>> This change overrides mutator methods in the implementation returned by
>> `Map.of().entrySet()` to throw `UnsupportedOperationException`.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to
> a merge o
On Fri, 28 Feb 2025 14:23:49 GMT, David Beaumont wrote:
>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized
>> publish() method.
>>
>> 1. Remove synchronization of calls to publish() in Handlers in
>> java.util.logging package.
>> 2. Add explanatory comments to various affe
On Thu, 27 Feb 2025 17:15:56 GMT, David Beaumont wrote:
>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized
>> publish() method.
>>
>> 1. Remove synchronization of calls to publish() in Handlers in
>> java.util.logging package.
>> 2. Add explanatory comments to various affe
On Thu, 27 Feb 2025 17:15:56 GMT, David Beaumont wrote:
>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized
>> publish() method.
>>
>> 1. Remove synchronization of calls to publish() in Handlers in
>> java.util.logging package.
>> 2. Add explanatory comments to various affe
On Tue, 25 Feb 2025 01:21:40 GMT, Stuart Marks wrote:
>> David Beaumont has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Tweaking @implNote for better rendering.
>
> src/java.logging/share/classes/java/u
On Thu, 27 Feb 2025 13:51:27 GMT, Jason Mehrens wrote:
>> David Beaumont has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Rewording notes and spec changes in docs.
>> Small change to read formatter once in streamhander methods.
>> Rev
On Wed, 12 Feb 2025 19:55:29 GMT, Stuart Marks wrote:
> A couple adjustments to the specs for four methods of StringBuilder and
> StringBuffer so that they no longer require new Strings to be created, just a
> String with the right contents. No implementation changes. Note that the
On Fri, 14 Feb 2025 15:07:58 GMT, David Beaumont wrote:
>> Well spotted :) Yes, it's a theoretical risk, but not at the same level as
>> that of log record formatting.
>>
>> My original draft push of this PR had comments about lock expectations here,
>> but I was asked to not change the JavaDo
On Mon, 24 Feb 2025 13:08:49 GMT, David Beaumont wrote:
>> 8349206: j.u.l.Handler classes create deadlock risk via synchronized
>> publish() method.
>>
>> 1. Remove synchronization of calls to publish() in Handlers in
>> java.util.logging package.
>> 2. Add explanatory comments to various affe
actually in AbstractStringBuilder, and
> they're inherited by StringBuilder and StringBuffer.
Stuart Marks 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 conta
On Fri, 14 Feb 2025 15:30:16 GMT, Roger Riggs wrote:
>> Stuart Marks has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> A tiny bit of wordsmithing.
>
> It should be pointed out (in the CSR) that this
On Thu, 13 Feb 2025 20:51:26 GMT, Stuart Marks wrote:
>> A couple adjustments to the specs for four methods of StringBuilder and
>> StringBuffer so that they no longer require new Strings to be created, just
>> a String with the right contents. No implementation chan
actually in AbstractStringBuilder, and
> they're inherited by StringBuilder and StringBuffer.
Stuart Marks has updated the pull request incrementally with one additional
commit since the last revision:
A tiny bit of wordsmithing.
-
Changes:
- all: https://git.openjdk.org/jdk/pull
On Wed, 12 Feb 2025 19:55:29 GMT, Stuart Marks wrote:
> A couple adjustments to the specs for four methods of StringBuilder and
> StringBuffer so that they no longer require new Strings to be created, just a
> String with the right contents. No implementation changes. Note that the
On Thu, 6 Feb 2025 12:07:57 GMT, David Beaumont wrote:
> 8349206: j.u.l.Handler classes create deadlock risk via synchronized
> publish() method.
>
> 1. Remove synchronization of calls to publish() in Handlers in
> java.util.logging package.
> 2. Add explanatory comments to various affected me
On Mon, 3 Feb 2025 19:13:10 GMT, Brent Christian wrote:
>> 3 finalizers in RMI code can be removed, as they do not perform meaningful
>> cleanup.
>>
>> **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext`**
>>
>> `RegistryContext.finalize()` just calls `close()`. The `clo
On Mon, 3 Feb 2025 19:13:10 GMT, Brent Christian wrote:
>> 3 finalizers in RMI code can be removed, as they do not perform meaningful
>> cleanup.
>>
>> **`jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext`**
>>
>> `RegistryContext.finalize()` just calls `close()`. The `clo
On Wed, 4 Dec 2024 19:06:20 GMT, Stuart Marks wrote:
> Convert the RMI NewThreadAction class into a couple static methods on
> RuntimeUtil. Also remove a couple unnecessary qualified exports from
> java.base to java.rmi.
This pull request has now been integrated.
Changeset: 8a3c10
On Wed, 4 Dec 2024 19:48:03 GMT, Roger Riggs wrote:
>> Stuart Marks has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Make thread group fields final.
>
> src/java.rmi/share/classes/sun/rmi/runtime/Runt
> Convert the RMI NewThreadAction class into a couple static methods on
> RuntimeUtil. Also remove a couple unnecessary qualified exports from
> java.base to java.rmi.
Stuart Marks has updated the pull request incrementally with one additional
commit since the last revision:
Ma
On Wed, 4 Dec 2024 19:23:47 GMT, Roger Riggs wrote:
>> Convert the RMI NewThreadAction class into a couple static methods on
>> RuntimeUtil. Also remove a couple unnecessary qualified exports from
>> java.base to java.rmi.
>
> Looks good, thanks for the cleanup
@RogerRiggs Thanks, I'll integra
Convert the RMI NewThreadAction class into a couple static methods on
RuntimeUtil. Also remove a couple unnecessary qualified exports from java.base
to java.rmi.
-
Commit messages:
- 8344461: clean up NewThreadAction
Changes: https://git.openjdk.org/jdk/pull/22557/files
Webrev:
On Fri, 22 Nov 2024 04:43:55 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this enhancement which proposes to enhance
>> `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`?
>>
>> The actual work for this was done a few years back when we discussed the
>> prop
On Mon, 25 Nov 2024 10:16:34 GMT, Aleksei Efimov wrote:
>> src/java.rmi/share/classes/sun/rmi/runtime/NewThreadAction.java line 30:
>>
>>> 28: import java.security.AccessController;
>>> 29: import java.security.PrivilegedAction;
>>> 30: import sun.security.util.SecurityConstants;
>>
>> Are ther
On Fri, 15 Nov 2024 12:17:47 GMT, Lance Andersen wrote:
>> Stuart in one of his review comments in this PR had noted that:
>>
>>> I think the class specification needs to be clearer about the positioning
>>> of end() and close(). The end() method has done the real work of "closing"
>>> since t
On Fri, 15 Nov 2024 11:15:28 GMT, Jaikiran Pai wrote:
>> Can I please get a review of this enhancement which proposes to enhance
>> `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`?
>>
>> The actual work for this was done a few years back when we discussed the
>> prop
On Fri, 15 Nov 2024 01:12:34 GMT, Stuart Marks wrote:
> First cut at removal of Security Manager stuff from RMI.
>
> This covers just about every SM-related case in RMI, except for a bit of
> package checking in MarshalInputStream. This will be handled separately. It's
-8344461](https://bugs.openjdk.org/browse/JDK-8344461) to
> cover this additional cleanup work.
Stuart Marks has updated the pull request incrementally with one additional
commit since the last revision:
Update with changes from code review.
-
Changes:
- all: https://git
On Mon, 18 Nov 2024 18:49:57 GMT, Roger Riggs wrote:
>> First cut at removal of Security Manager stuff from RMI.
>>
>> This covers just about every SM-related case in RMI, except for a bit of
>> package checking in MarshalInputStream. This will be handled separately.
>> It's covered by [JDK-83
On Mon, 18 Nov 2024 17:39:44 GMT, Aleksei Efimov wrote:
>> First cut at removal of Security Manager stuff from RMI.
>>
>> This covers just about every SM-related case in RMI, except for a bit of
>> package checking in MarshalInputStream. This will be handled separately.
>> It's covered by [JDK
On Mon, 18 Nov 2024 18:05:12 GMT, Aleksei Efimov wrote:
>> src/java.rmi/share/classes/sun/rmi/server/MarshalInputStream.java line 69:
>>
>>> 67:
>>> 68: /** table to hold sun classes to which access is explicitly
>>> permitted */
>>> 69: protected static Map> permittedSunClasses
>>
>>
First cut at removal of Security Manager stuff from RMI.
This covers just about every SM-related case in RMI, except for a bit of
package checking in MarshalInputStream. This will be handled separately. It's
covered by [JDK-8344329](https://bugs.openjdk.org/browse/JDK-8344329).
Further simplifi
On Thu, 14 Nov 2024 22:09:59 GMT, Roger Riggs wrote:
> Remove use of doPrivileged and SecurityManager in java.util.
Marked as reviewed by smarks (Reviewer).
I mainly wanted to look at Arrays, and I looked briefly at the other stuff too.
All looks good.
-
PR Review: https://git.op
On Thu, 14 Nov 2024 03:23:29 GMT, Naman Nigam wrote:
>> As the documentation of getCeilingEntry currently reads, the inference is
>> misleading as follows:
>>
>> if no such entry exists, returns the entry for the least key greater than
>> the specified key;
>> if no such entry exists (i.e., th
On Thu, 3 Oct 2024 19:31:06 GMT, Attila Szegedi wrote:
>> Fixes a regression with #17818 where `ArrayList.subList(…).sort()` started
>> incrementing `ArrayList.modCount` resulting in some cases throwing a
>> `ConcurrentModificationException` where none was thrown before.
>>
>> This change keep
On Tue, 1 Oct 2024 05:39:09 GMT, Eirik Bjørsnøs wrote:
>> Please review this cleanup PR which updates code and tests in `java.base` to
>> consistently use `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH`
>> when referring to the JVM's maximum array size implementation limit.
>> Currentl
On Tue, 1 Oct 2024 05:52:23 GMT, Eirik Bjørsnøs wrote:
>> As this stands (modulo my other comments) this change is mostly OK. Using
>> the SOFT_MAX value within java.base is fine. Using SOFT_MAX within
>> java.base-related tests is a little suspicious, because it requires the
>> addition of di
On Mon, 30 Sep 2024 15:14:31 GMT, Eirik Bjørsnøs wrote:
> Please review this cleanup PR which updates code and tests in `java.base` to
> consistently use `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when
> referring to the JVM's maximum array size implementation limit. Currently,
>
On Mon, 30 Sep 2024 15:14:31 GMT, Eirik Bjørsnøs wrote:
> Please review this cleanup PR which updates code and tests in `java.base` to
> consistently use `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when
> referring to the JVM's maximum array size implementation limit. Currently,
>
On Mon, 30 Sep 2024 19:44:05 GMT, Attila Szegedi wrote:
>> Just an observation, but sorting is not defined as a "structural
>> modification" but obviously would interfere with an active iterator. So the
>> docs may need updating to include this aspect.
>
> @dholmes-ora and @dfuch both your obse
On Tue, 1 Oct 2024 03:18:57 GMT, David Holmes wrote:
>> Fixes a regression with #17818 where `ArrayList.subList(…).sort()` started
>> incrementing `ArrayList.modCount` resulting in some cases throwing a
>> `ConcurrentModificationException` where none was thrown before.
>>
>> This change keeps
On Fri, 22 Mar 2024 09:25:06 GMT, Viktor Klang wrote:
>> BenchmarkMode CntScore Error Units
>> ImmutableColls.forEachOverList thrpt 15 361.423 ± 8.751 ops/us
>> ImmutableColls.forEachOverSet thrpt 15 79.158 ± 5.064 ops/us
>> ImmutableColls.getOrDefault
On Fri, 26 Apr 2024 22:27:21 GMT, Chen Liang wrote:
>> Please review this patch that:
>> 1. Implemented `forEach` to optimize for 1 or 2 element collections.
>> 2. Implemented `spliterator` to optimize for a single element.
>>
>> The default implementations for multiple-element immutable collect
On Tue, 10 Sep 2024 19:23:16 GMT, Brent Christian wrote:
>> From the bug description:
>> ForceGC would be improved by moving the Reference.reachabilityFence() calls
>> for 'obj' and 'ref'.
>>
>> Reference.reachabilityFence(obj) is currently placed after 'obj' has been
>> set to null, so effect
On Mon, 9 Sep 2024 16:12:02 GMT, Stuart Marks wrote:
>> The reason for the explicit reference and RF, as I recall, is to guard
>> against the allocation of the new object being elided entirely, with the
>> `PhantomReference` constructor being passed null (or itself being
On Mon, 9 Sep 2024 05:01:26 GMT, David Holmes wrote:
>> test/lib/jdk/test/lib/util/ForceGC.java line 82:
>>
>>> 80: PhantomReference ref = new PhantomReference<>(obj,
>>> queue);
>>> 81: Reference.reachabilityFence(obj);
>>> 82: obj = null;
>>
>> You're right to questio
On Fri, 6 Sep 2024 19:57:41 GMT, Brent Christian wrote:
> From the bug description:
> ForceGC would be improved by moving the Reference.reachabilityFence() calls
> for 'obj' and 'ref'.
>
> Reference.reachabilityFence(obj) is currently placed after 'obj' has been set
> to null, so effectively d
On Fri, 6 Sep 2024 19:57:41 GMT, Brent Christian wrote:
> From the bug description:
> ForceGC would be improved by moving the Reference.reachabilityFence() calls
> for 'obj' and 'ref'.
>
> Reference.reachabilityFence(obj) is currently placed after 'obj' has been set
> to null, so effectively d
1 - 100 of 497 matches
Mail list logo
