On Wed, 16 Jul 2025 13:30:08 GMT, Alan Bateman wrote:
> Hello Brian, I'm late to this discussion. I think there are a couple of more
> places in this code which need attention.
Thanks for catching this, @jaikiran. As you no doubt already observed, this has
been fixed by #26353 in the mainline
On Thu, 17 Jul 2025 06:33:43 GMT, Brian Burkhalter wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [be0161a8](https://github.com/openjdk/jdk/commit/be0161a8e63096f3a21ce6ea1e055ee1c4ed63ad)
> from the [openjdk/jdk](https://git.openjdk.org/
Hi all,
This pull request contains a backport of commit
[be0161a8](https://github.com/openjdk/jdk/commit/be0161a8e63096f3a21ce6ea1e055ee1c4ed63ad)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Brian Burkhalter on 17 Jul 2025
On Wed, 16 Jul 2025 16:54:55 GMT, Brian Burkhalter wrote:
> Address the same problem as in #26224 but for the `listFiles` variants with a
> filter parameter.
This pull request has now been integrated.
Changeset: be0161a8
Author: Brian Burkhalter
URL:
https://git.openjdk.o
> Address the same problem as in #26224 but for the `listFiles` variants with a
> filter parameter.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8362429: Simplify listFile loops; add non-null filter
On Wed, 16 Jul 2025 19:05:30 GMT, Brian Burkhalter wrote:
>> src/java.base/share/classes/java/io/File.java line 1227:
>>
>>> 1225: File f = new File(s, this);
>>> 1226: if ((filter == null) || filter.accept(f))
>>>
On Wed, 16 Jul 2025 18:26:51 GMT, Alan Bateman wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8362429: Add list(FilenameFilter) and toURL()
>
> src/java.base/share/class
> Address the same problem as in #26224 but for the `listFiles` variants with a
> filter parameter.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8362429: Add list(FilenameFilter) and toURL()
-
Changes:
Address the same problem as in #26224 but for the `listFiles` variants with a
filter parameter.
-
Commit messages:
- 8362429: AssertionError in File.listFiles(FileFilter | FilenameFilter)
Changes: https://git.openjdk.org/jdk/pull/26353/files
Webrev: https://webrevs.openjdk.org/?r
On Wed, 16 Jul 2025 13:30:08 GMT, Alan Bateman wrote:
> @bplb Can you check the test coverage again? Its important that EmptyTest
> exercises every method.
Yes.
-
PR Comment: https://git.openjdk.org/jdk/pull/26224#issuecomment-3079290576
On Tue, 15 Jul 2025 18:21:22 GMT, Brian Burkhalter wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [eefbfdce](https://github.com/openjdk/jdk/commit/eefbfdce315237eeec4aceceb476d86314304e81)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repos
Hi all,
This pull request contains a backport of commit
[eefbfdce](https://github.com/openjdk/jdk/commit/eefbfdce315237eeec4aceceb476d86314304e81)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Brian Burkhalter on 15 Jul 2025 and
On Wed, 9 Jul 2025 18:04:08 GMT, Brian Burkhalter wrote:
> Changes to address `File.listFiles` invoked on an empty path. This fixes an
> oversight in #22821.
This pull request has now been integrated.
Changeset: eefbfdce
Author: Brian Burkhalter
URL:
https://git.openjdk.o
> Changes to address `File.listFiles` invoked on an empty path. This fixes an
> oversight in #22821.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8361587: Fix mkdirs sub-test
-
Changes:
- all:
On Tue, 15 Jul 2025 17:03:18 GMT, Brian Burkhalter wrote:
>> Okay, but if I read this correctly then these methods will test mkdirs with
>> a non-empty path as child will be "/child" or "\child". In order to test
>> mkdirs with an empty path then
On Fri, 11 Jul 2025 15:34:26 GMT, Brian Burkhalter wrote:
>> src/java.base/unix/classes/java/io/UnixFileSystem.java line 120:
>>
>>> 118: public String resolve(String parent, String child) {
>>> 119: if (child.isEmpty()) return parent;
>>> 12
On Tue, 15 Jul 2025 16:43:49 GMT, Alan Bateman wrote:
>> Yes. The OS-dependent `mkdirs` sub-tests reflect the actual behavior.
>
> Okay, but if I read this correctly then these methods will test mkdirs with a
> non-empty path as child will be "/child" or "\child". In order to test
> mkdirs wit
On Tue, 15 Jul 2025 06:36:46 GMT, Alan Bateman wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8361587: Improve previous commit
>
> test/jdk/java/io/File/Empt
> Changes to address `File.listFiles` invoked on an empty path. This fixes an
> oversight in #22821.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8361587: Improve previous commit
-
Changes:
- all:
> Changes to address `File.listFiles` invoked on an empty path. This fixes an
> oversight in #22821.
Brian Burkhalter has updated the pull request incrementally with two additional
commits since the last revision:
- 8361587: Address the error directly in listFiles
- 8361587: Revert c
On Fri, 11 Jul 2025 07:24:24 GMT, Alan Bateman wrote:
> [...] look to special casing the empty parent in the listFiles methods [...].
Will investigate.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/26224#discussion_r2201046992
> Changes to address `File.listFiles` invoked on an empty path. This fixes an
> oversight in #22821.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8361587: Modify mkdirs() testing
-
Changes:
- all:
On Thu, 10 Jul 2025 14:18:31 GMT, Alan Bateman wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8361587: Expand test coverage of File methods
>
> test/jdk/java/io/File/Empt
> Changes to address `File.listFiles` invoked on an empty path. This fixes an
> oversight in #22821.
Brian Burkhalter has updated the pull request incrementally with two additional
commits since the last revision:
- 8361587: Fix omission in previous commit
- 8361587: Address re
> Changes to address `File.listFiles` invoked on an empty path. This fixes an
> oversight in #22821.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8361587: Expand test coverage of File methods
-
Changes:
On Wed, 9 Jul 2025 18:39:40 GMT, Naoto Sato wrote:
> Replaced Collections.emptyList() with List.of() as part of refactoring. This
> was discussed in the context of investigating a CDS-related issue
> (https://bugs.openjdk.org/browse/JDK-8357281?focusedId=14796714&page=com.atlassian.jira.plugin.
On Wed, 9 Jul 2025 18:16:44 GMT, Alan Bateman wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8361587: Clean up listFiles sub-test per suggestions
>
> test/jdk/java/io/File/Empt
On Wed, 9 Jul 2025 18:22:51 GMT, Johannes Döbler wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8361587: Clean up listFiles sub-test per suggestions
>
> test/jdk/java/i
> Changes to address `File.listFiles` invoked on an empty path. This fixes an
> oversight in #22821.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8361587: Clean up listFiles sub-test per suggestions
-
C
Changes to address `File.listFiles` invoked on an empty path. This fixes an
oversight in #22821.
-
Commit messages:
- 8361587: AssertionError in File.listFiles() when path is empty and -esa is
enabled
Changes: https://git.openjdk.org/jdk/pull/26224/files
Webrev: https://webrevs.
On Wed, 18 Jun 2025 00:04:37 GMT, Brian Burkhalter wrote:
> Replaces the implementation `readAllCharsAsString().lines().toList()` with
> reading into a temporary `char` array which is then processed to detect line
> terminators and copy non-terminating characters into strings which
On Thu, 3 Jul 2025 13:41:02 GMT, Roger Riggs wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8358533: Decrease value of minGrowth parameter
>
> Another review would be
> Replaces the implementation `readAllCharsAsString().lines().toList()` with
> reading into a temporary `char` array which is then processed to detect line
> terminators and copy non-terminating characters into strings which are added
> to the list.
Brian Burkhalter has upda
> On Jul 2, 2025, at 1:05 PM, Brett Okken wrote:
>
>> It looks like only CharBuffer.getChars is broken so the rest of the change
>> can stay. I filed this issue to track it:
>>
>> https://bugs.openjdk.org/browse/JDK-8361299
>>
>> The fix is straightforward but will break a test and require
break.
Thanks for bringing this up. It does need attention. I just chatted with Brian
Burkhalter so he's going to look through the spec + implementation changes to
address this. If there is any risk or uncertainty then it mean pulling this out.
It looks like only CharBuffer.getChars is b
Sorry, I intended nio-...@openjdk.org<mailto:nio-...@openjdk.org>.
On Jul 2, 2025, at 9:03 AM, Brian Burkhalter
wrote:
I think that this discussion should be redirected to nio-dev:
https://mail.openjdk.org/pipermail/nio-dev/
On Jul 2, 2025, at 9:00 AM, Brett Okken wrote:
Actually it
I think that this discussion should be redirected to nio-dev:
https://mail.openjdk.org/pipermail/nio-dev/
On Jul 2, 2025, at 9:00 AM, Brett Okken wrote:
Actually it looks like the CharBuffer java doc explicitly states that
all CharSequence should be relative:
This class implements the CharSequ
Some methods are absolute and some relative:
https://docs.oracle.com/en/java/javase/24/docs/api/java.base/java/nio/Buffer.html#transferring-data-heading
On Jul 2, 2025, at 8:35 AM, Brett Okken wrote:
CharBuffer implementation of public default void getChars(int
srcBegin, int srcEnd, char[] dst,
> This proposed change would move the native objects required for NIO file
> interaction from the libnio native library to the libjava native library on
> Linux, macOS, and Windows.
Brian Burkhalter has updated the pull request with a new target base due to a
merge or a rebase.
On Tue, 1 Jul 2025 15:10:10 GMT, Brian Burkhalter wrote:
>> src/java.base/share/classes/java/io/Reader.java line 482:
>>
>>> 480: if (pos == limit) {
>>> 481: int len = limit - start;
>>> 482: if
> Replaces the implementation `readAllCharsAsString().lines().toList()` with
> reading into a temporary `char` array which is then processed to detect line
> terminators and copy non-terminating characters into strings which are added
> to the list.
Brian Burkhalter has upda
On Tue, 1 Jul 2025 19:17:17 GMT, Roger Riggs wrote:
>> With this change
>>
>> --- a/test/jdk/java/io/Reader/ReadAll.java
>> +++ b/test/jdk/java/io/Reader/ReadAll.java
>> @@ -115,6 +115,8 @@ public static void setup() throws IOException {
>> sb.setLength(0);
>> }
>>
>> +
On Tue, 1 Jul 2025 15:10:33 GMT, Brian Burkhalter wrote:
>> test/jdk/java/io/Reader/ReadAll.java line 117:
>>
>>> 115: sb.setLength(0);
>>> 116: }
>>> 117:
>>
>> Does one of these cases result in a *very very long l
On Tue, 1 Jul 2025 01:37:27 GMT, Roger Riggs wrote:
> I think resizing the buffer when the line length exceeds cb.length/2 will be
> more efficient (cpu wise).
I concur. I missed that this had been changed in the most recent commit.
> test/jdk/java/io/Reader/ReadAll.java line 117:
>
>> 115:
> Replaces the implementation `readAllCharsAsString().lines().toList()` with
> reading into a temporary `char` array which is then processed to detect line
> terminators and copy non-terminating characters into strings which are added
> to the list.
Brian Burkhalter has upda
On Mon, 30 Jun 2025 18:28:26 GMT, Xueming Shen wrote:
> the throughput appears to back to normal with 'find term while loop' fast path
This version passes the regression test and is a little faster than the latest
PR version. I'll run it through the CI and probably use it in the next commit.
T
On Sat, 28 Jun 2025 08:41:27 GMT, Xueming Shen wrote:
> The modified code below is a PoC for reference. It seems to work as expected,
> though not fully tested.
This looks like a nice reworking, and appears to pass the regression test, but
its throughput is less than half that of the current v
On Fri, 27 Jun 2025 22:46:40 GMT, Xueming Shen wrote:
> [...] more in line with how resizing is handled in string builder
Looks like `StringBuilder` eventually calls
`ArraysSupport.newLength(int,int.int)`. This is probably worth checking out.
-
PR Review Comment: https://git.openj
On Fri, 27 Jun 2025 19:21:19 GMT, Roger Riggs wrote:
> More directly, use limit instead of term in the computation of length.
Good point. So changed in 3e5e498.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2172749427
> Replaces the implementation `readAllCharsAsString().lines().toList()` with
> reading into a temporary `char` array which is then processed to detect line
> terminators and copy non-terminating characters into strings which are added
> to the list.
Brian Burkhalter has upda
On Fri, 27 Jun 2025 18:52:14 GMT, Brian Burkhalter wrote:
>> src/java.base/share/classes/java/io/Reader.java line 494:
>>
>>> 492: skipLF = isCR;
>>> 493: } else { // no line terminator
>>> 494: in
On Fri, 27 Jun 2025 18:44:55 GMT, Roger Riggs wrote:
>> Brian Burkhalter has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - 8358533: Use a boolean instead of fragPos != -1
>> - 8358533: Immediately
On Fri, 27 Jun 2025 15:36:29 GMT, Roger Riggs wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8358533: Test change accidentally omitted from previous commit
>
> src/java.base/sha
> Replaces the implementation `readAllCharsAsString().lines().toList()` with
> reading into a temporary `char` array which is then processed to detect line
> terminators and copy non-terminating characters into strings which are added
> to the list.
Brian Burkhalter has upda
> Replaces the implementation `readAllCharsAsString().lines().toList()` with
> reading into a temporary `char` array which is then processed to detect line
> terminators and copy non-terminating characters into strings which are added
> to the list.
Brian Burkhalter has upda
> Replaces the implementation `readAllCharsAsString().lines().toList()` with
> reading into a temporary `char` array which is then processed to detect line
> terminators and copy non-terminating characters into strings which are added
> to the list.
Brian Burkhalter has upda
On Tue, 24 Jun 2025 19:15:38 GMT, Brian Burkhalter wrote:
> > One possibility is to copy the remaining fragment of a line to a new
> > transfer buffer (maybe twice the size).
>
> It's probably worth testing this.
In 0ee3f59 I implemented something like this. It i
On Thu, 26 Jun 2025 06:51:14 GMT, Alan Bateman wrote:
> Exactly, so I think the first step here has to validate that where we ended
> up in WindowsPath.compareTo is correct.
`WindowsPath.compareTo` returns zero (equal) if and only if the path strings
are the same length, and the two characters
> Replaces the implementation `readAllCharsAsString().lines().toList()` with
> reading into a temporary `char` array which is then processed to detect line
> terminators and copy non-terminating characters into strings which are added
> to the list.
Brian Burkhalter has upda
On Mon, 23 Jun 2025 11:09:30 GMT, Alan Bateman wrote:
> > Just wondering how Windows implementation really behaves for its
> > 'case-insensitive-comparing" for "\u0131 vs "I". I would assume they
> > actually are 2 'distinguished" files?
>
> I think it depends on the locale. Also it is possibl
On Fri, 20 Jun 2025 17:16:58 GMT, Xueming Shen wrote:
>> The change is motivated by performance, but there will be many inputs that
>> are less than the transfer buffer size and those will not use the
>> StringBuilder, so creating it before it is needed could be avoided.
>> When a partial line
On Tue, 24 Jun 2025 18:49:08 GMT, Brian Burkhalter wrote:
>> resizing/newCapacity is always expensive and tricky, string builder
>> included. so maybe we should decide if 'long lines' (> transfer buffer size)
>> is the goal of this pr. if not, it might be
On Tue, 24 Jun 2025 08:08:58 GMT, Andrey Turbanov wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8358533: Init StringBuilder to size zero; use StringBuilder.isEmpty()
>
> test/m
On Mon, 23 Jun 2025 21:23:05 GMT, Stuart Marks wrote:
>> src/java.base/share/classes/java/io/Reader.java line 508:
>>
>>> 506: }
>>> 507:
>>> 508: return lines;
>>
>> Do we really want to return a mutable `ArrayList` here? In earlier
>> discussions about this very API I was to
On Mon, 9 Jun 2025 21:03:27 GMT, Brian Burkhalter wrote:
> Relax testing the inequality `usable_space <= free_space` to testing the
> inequality `usable_space <= total_space`.
This pull request has now been integrated.
Changeset: 50910576
Author:Brian Burkhalter
URL:
On Tue, 24 Jun 2025 19:12:25 GMT, Roger Riggs wrote:
> One possibility is to copy the remaining fragment of a line to a new transfer
> buffer (maybe twice the size).
It's probably worth testing this.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r216472586
On Tue, 24 Jun 2025 18:46:49 GMT, Brian Burkhalter wrote:
>> The `readAllLines` method has a specification of line terminators that
>> agrees with that of `BufferedReader::readLine` and `String::lines` and so we
>> don't want to change it to be different.
>>
>&
On Wed, 18 Jun 2025 00:05:17 GMT, Brian Burkhalter wrote:
> The throughput of the implementation [...].
The performance comments made
[here](https://github.com/openjdk/jdk/pull/25863#issuecomment-2982169343) still
apply to the most recent commit.
-
PR Comment: ht
On Thu, 19 Jun 2025 10:59:14 GMT, Markus KARG wrote:
> Is there a reason for `sb.length() == 0` instead of `sb.isEmpty()`?
The former is identical. Modified to use `isEmpty` in 8ccfd54.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2164686620
On Wed, 18 Jun 2025 02:12:50 GMT, Shaojin Wen wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8358533: Init StringBuilder to size zero; use StringBuilder.isEmpty()
>
> src/j
On Wed, 18 Jun 2025 02:25:03 GMT, Chen Liang wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8358533: Init StringBuilder to size zero; use StringBuilder.isEmpty()
>
> src/j
On Mon, 23 Jun 2025 21:16:30 GMT, Stuart Marks wrote:
>> `Scanner` seems to scan for even more characters:
>> https://github.com/openjdk/jdk/blob/c4fb00a7be51c7a05a29d3d57d787feb5c698ddf/src/java.base/share/classes/java/util/Scanner.java#L490
>>
>> Would it make sense to resemble this? Would it
> Replaces the implementation `readAllCharsAsString().lines().toList()` with
> reading into a temporary `char` array which is then processed to detect line
> terminators and copy non-terminating characters into strings which are added
> to the list.
Brian Burkhalter has upda
On Wed, 18 Jun 2025 00:04:37 GMT, Brian Burkhalter wrote:
> Replaces the implementation `readAllCharsAsString().lines().toList()` with
> reading into a temporary `char` array which is then processed to detect line
> terminators and copy non-terminating characters into strings which
> Replaces the implementation `readAllCharsAsString().lines().toList()` with
> reading into a temporary `char` array which is then processed to detect line
> terminators and copy non-terminating characters into strings which are added
> to the list.
Brian Burkhalter has upda
On Mon, 23 Jun 2025 11:09:30 GMT, Alan Bateman wrote:
> WindowsPath.compareTo is where we ended up for JDK 7, it would be good to
> validate this.
I assume that you intend here validating correctness with respect to the NTFS
case sensitivity settings
-
PR Comment: https://git.ope
On Wed, 18 Jun 2025 02:26:48 GMT, Chen Liang wrote:
> Is there a reason for this pre-allocation?
What would you suggest? Start with a smaller allocation and increase it if
needed? There is no possibility of knowing the length of the stream.
-
PR Review Comment: https://git.openjdk
On Wed, 18 Jun 2025 02:38:04 GMT, Chen Liang wrote:
> Edit: No, we need to check empty lines.
Right. I caught this during testing.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/25863#discussion_r2155088265
On Wed, 18 Jun 2025 02:33:40 GMT, Xueming Shen wrote:
> I think we should treat "\r\n" as a single line terminator?
You are correct: that needs to be fixed:
jshell> Reader r = new StringReader("hello\r\nworld")
r ==> java.io.StringReader@480bdb19
jshell> r.readAllLines()
$3 ==> [hello, , world
On Wed, 18 Jun 2025 09:20:12 GMT, Shaojin Wen wrote:
> If we want better performance, we should go a step further and overload the
> readAllLines method in the Reader implementation class.
Perhaps, but not in this request. A separate issue should be filed and
addressed subsequently.
-
On Wed, 18 Jun 2025 00:53:51 GMT, Roger Riggs wrote:
>> Replaces the implementation `readAllCharsAsString().lines().toList()` with
>> reading into a temporary `char` array which is then processed to detect line
>> terminators and copy non-terminating characters into strings which are added
>>
Replaces the implementation `readAllCharsAsString().lines().toList()` with
reading into a temporary `char` array which is then processed to detect line
terminators and copy non-terminating characters into strings which are added to
the list.
-
Commit messages:
- 8358533: Improve p
On Wed, 18 Jun 2025 00:04:37 GMT, Brian Burkhalter wrote:
> Replaces the implementation `readAllCharsAsString().lines().toList()` with
> reading into a temporary `char` array which is then processed to detect line
> terminators and copy non-terminating characters into strings which
On Tue, 17 Jun 2025 14:56:59 GMT, Dermot Boyle wrote:
> … extract method for Windows specific test
Looks fine.
-
Marked as reviewed by bpb (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/25853#pullrequestreview-2936585934
>
> The commit being backported was authored by Stuart Marks on 16 Jun 2025 and
> was reviewed by Naoto Sato @naotoj and Brian Burkhalter @bplb.
>
> Thanks!
Marked as reviewed by bpb (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/25858#pullrequestreview-2936534326
On Fri, 13 Jun 2025 21:46:42 GMT, Raffaello Giulietti
wrote:
>> Documenting a suggestion for `float` arguments.
>
> Raffaello Giulietti has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Suggestion by reviewer.
Marked as reviewed by bpb (Rev
On Fri, 13 Jun 2025 18:10:03 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/math/BigDecimal.java line 1383:
>>
>>> 1381: * the result usually contains too many trailing digits compared
>>> 1382: * to the precision of a {@code float}.
>>> 1383: * Consider usin
On Fri, 13 Jun 2025 15:21:38 GMT, Raffaello Giulietti
wrote:
> Documenting a suggestion for `float` arguments.
Marked as reviewed by bpb (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/25805#pullrequestreview-2925970196
On Fri, 13 Jun 2025 15:21:38 GMT, Raffaello Giulietti
wrote:
> Documenting a suggestion for `float` arguments.
src/java.base/share/classes/java/math/BigDecimal.java line 1383:
> 1381: * the result usually contains too many trailing digits compared
> 1382: * to the precision of a {@co
On Thu, 12 Jun 2025 23:39:44 GMT, Stuart Marks wrote:
>> Add a note to String.trim pointing to the String.strip family of methods.
>>
>> Add notes cross-linking String.isBlank and String.isEmpty.
>
> Stuart Marks has updated the pull request incrementally with one additional
> commit since the
Replace logic in `java.io.WinNTFileSystems.compare(File,File)` with that from
`sun.nio.fs.WindowsPath.compareTo(Path)`.
-
Commit messages:
- 8191963: Path.equals() and File.equals() return true for two different files
on Windows
Changes: https://git.openjdk.org/jdk/pull/25788/file
On Wed, 11 Jun 2025 22:39:48 GMT, Stuart Marks wrote:
> Add a note to String.trim pointing to the String.strip family of methods.
>
> Add notes cross-linking String.isBlank and String.isEmpty.
src/java.base/share/classes/java/lang/String.java line 3837:
> 3835: *
> 3836: * @apiNote
>
On Wed, 11 Jun 2025 07:15:43 GMT, SendaoYan wrote:
> Hi all,
>
> I think use `@requires (os.family == "windows")` is more elegant than thow
> jtreg.SkippedException in test java/io/File/MaxPath.java.
>
> On linux before this PR, run this test jtreg report:
>
>
> TEST: java/io/File/MaxPath.ja
On Mon, 9 Jun 2025 21:03:27 GMT, Brian Burkhalter wrote:
> Relax testing the inequality `usable_space <= free_space` to testing the
> inequality `usable_space <= total_space`.
Although the native system call `statfs` (Unix) and native function
`GetDiskFreeSpaceExW` (Windows) might
Relax testing the inequality `usable_space <= free_space` to testing the
inequality `usable_space <= total_space`.
-
Commit messages:
- 8351010: Test java/io/File/GetXSpace.java failed: / usable space 56380809216
> free space 14912244940
Changes: https://git.openjdk.org/jdk/pull/2
On Mon, 14 Apr 2025 20:57:17 GMT, Brian Burkhalter wrote:
> In `java.io.WinNTFileSystem::isInvalid`, replace an insufficient test for
> file path validity with a sufficient test for file path invalidity. Also, add
> a new test.
This pull request has now been integrated.
Changeset:
On Fri, 30 May 2025 17:02:12 GMT, Justin Lu wrote:
>> Please review this PR which cleans up some i18n tests.
>>
>> There are some i18n related tests that set the locale provider to CLDR (and
>> only CLDR). Since JDK9, this is redundant and equivalent to the default.
>> Thus, occurrences of "-D
On Fri, 30 May 2025 13:28:34 GMT, Alan Bateman wrote:
> We will need a release note to document the behavior change.
Will do.
-
PR Comment: https://git.openjdk.org/jdk/pull/24635#issuecomment-2922804844
On Fri, 30 May 2025 00:17:37 GMT, Justin Lu wrote:
>> Please review this PR which cleans up some i18n tests.
>>
>> There are some i18n related tests that set the locale provider to CLDR (and
>> only CLDR). Since JDK9, this is redundant and equivalent to the default.
>> Thus, occurrences of "-D
On Thu, 29 May 2025 21:59:30 GMT, Justin Lu wrote:
> Please review this PR which cleans up some i18n tests.
>
> There are some i18n related tests that set the locale provider to CLDR (and
> only CLDR). Since JDK9, this is redundant and equivalent to the default.
> Thus, occurrences of "-Djava.
1 - 100 of 1203 matches
Mail list logo
