On Fri, 25 Jun 2021 01:39:21 GMT, Brian Burkhalter wrote:
>> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and
>> `read(byte[],int,int)` to return zero per the `InputStream` specification
>> when the byte array actual or specified length is zero.
>
> Bria
> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and
> `read(byte[],int,int)` to return zero per the `InputStream` specification
> when the byte array actual or specified length is zero.
Brian Burkhalter has updated the pull request incrementally with one additional
com
On Fri, 25 Jun 2021 00:04:48 GMT, Brian Burkhalter wrote:
> Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and
> `read(byte[],int,int)` to return zero per the `InputStream` specification
> when the byte array actual or specified length is zero.
Yeah I overlooked addin
Modify `java.io.ByteArrayInputStream` methods `read(byte[])` and
`read(byte[],int,int)` to return zero per the `InputStream` specification when
the byte array actual or specified length is zero.
-
Commit messages:
- 6766844: ByteArrayInputStream#read with a byte array of length 0
On Thu, 24 Jun 2021 21:20:29 GMT, Naoto Sato wrote:
> Fine by me.
Thanks!
-
PR: https://git.openjdk.java.net/jdk/pull/4589
On Thu, 24 Jun 2021 20:01:27 GMT, Brian Burkhalter wrote:
> Merge identical Unix and Windows versions of FileOutputStream_md.c into
> single, common FileOutputStream.c.
The `fileOpen()`, `writeSingle()`, and `writeBytes()` functions called here all
expect to receive a field ID. This
On Thu, 24 Jun 2021 20:36:29 GMT, Joe Wang wrote:
> Fix a regression caused by the previous BCEL update. The issue was fixed in
> the current BCEL repo with a reversal of the previous code, adding back
> "gos.close();". Note however, doing so will result in a warning: [try]
> explicit call to
Merge identical Unix and Windows versions of FileOutputStream_md.c into single,
common FileOutputStream.c.
-
Commit messages:
- 6633375: FileOutputStream_md.c should be merged into FileOutputStream.c
Changes: https://git.openjdk.java.net/jdk/pull/4589/files
Webrev:
On Thu, 24 Jun 2021 17:40:55 GMT, Naoto Sato wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 4847239: Add test
>
> test/jdk/java/io/File/createTempFile/TargetDi
> Augment the specification of
> `java.io.File.createTempFile(String,String,File)` to clarify its behavior
> with respect to the `File` parameter `directory`.
Brian Burkhalter has refreshed the contents of this pull request, and previous
commits have been removed. The incremen
> Augment the specification of
> `java.io.File.createTempFile(String,String,File)` to clarify its behavior
> with respect to the `File` parameter `directory`.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
484723
On Jun 24, 2021, at 3:29 AM, Lance Andersen
mailto:lan...@openjdk.java.net>> wrote:
src/java.base/share/classes/java/io/File.java line 2116:
2114: * abstract pathname is valid and denotes an existing directory, then
the
2115: * file will be created in that directory; otherwise, the
On Wed, 23 Jun 2021 00:06:25 GMT, Brian Burkhalter wrote:
> Augment the specification of
> `java.io.File.createTempFile(String,String,File)` to clarify its behavior
> with respect to the `File` parameter `directory`.
Test added.
-
PR: https://git.openjdk.java.net/jdk/pull/4561
> Augment the specification of
> `java.io.File.createTempFile(String,String,File)` to clarify its behavior
> with respect to the `File` parameter `directory`.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
4847239:
On Wed, 23 Jun 2021 00:06:25 GMT, Brian Burkhalter wrote:
> Augment the specification of
> `java.io.File.createTempFile(String,String,File)` to clarify its behavior
> with respect to the `File` parameter `directory`.
Surprisingly it does not look like there is a verifying test.
Augment the specification of `java.io.File.createTempFile(String,String,File)`
to clarify its behavior with respect to the `File` parameter `directory`.
-
Commit messages:
- Merge
- 4847239: (spec) File.createTempFile() should make it clear that it doesn't
create the temporary
On Tue, 22 Jun 2021 16:18:11 GMT, Roger Riggs wrote:
>> Add java.util.Objects.newIdentity to supply a unique object with identity.
>> This is a replacement code can be used today for the traditional new
>> Object() idiom, which will be deprecated under Project Valhalla.
>> Refer to [JEP 401:
On Tue, 22 Jun 2021 04:22:34 GMT, Ian Graves wrote:
> 8268664: The documentation of the Scanner.hasNextLine is incorrect
+1
-
Marked as reviewed by bpb (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/4547
On Mon, 21 Jun 2021 18:22:26 GMT, Naoto Sato wrote:
> Please review this doc clarification fix to `toDaysPart()` method. CSR will
> also be filed accordingly.
Looks fine.
-
Marked as reviewed by bpb (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/4542
On Jun 18, 2021, at 6:36 AM, Alan Bateman
mailto:al...@openjdk.java.net>> wrote:
Adding an override of transferTo may require new tests. @bplb Do you if we have
good tests for all the scenarios where input stream returned by
Channels.newInputStream is the source?
There are not a lot of tests
On Tue, 8 Jun 2021 20:20:58 GMT, Markus KARG
wrote:
>> src/java.base/share/classes/sun/nio/ch/ChannelOutputStream.java line 113:
>>
>>> 111: if ((off < 0) || (off > bs.length) || (len < 0) ||
>>> 112: ((off + len) > bs.length) || ((off + len) < 0)) {
>>> 113:
On Sun, 30 May 2021 17:30:56 GMT, Markus KARG
wrote:
> This PR-*draft* is **work in progress** and an invitation to discuss a
> possible solution for issue
> [JDK-8265891](https://bugs.openjdk.java.net/browse/JDK-8265891). It is *not
> yet* intended for a final review.
>
> As proposed in
On Tue, 15 Jun 2021 18:05:18 GMT, Joe Darcy wrote:
> The javadoc of AutoCloseable.close is from JDK 7 and thus predates tags like
> @apiNote. However, some of the discussion contained in AutoCloseable.close is
> more appropriate as an apiNote that normal text.
Marked as reviewed by bpb
On Thu, 27 May 2021 20:33:50 GMT, Brian Burkhalter wrote:
> Modify the specification of `java.io.File.equals` to clarify that equality is
> based only on a comparison of abstract pathnames as opposed to the file
> system objects that the `File`s represent.
This pull request has
> Modify the specification of `java.io.File.equals` to clarify that equality is
> based only on a comparison of abstract pathnames as opposed to the file
> system objects that the `File`s represent.
Brian Burkhalter has updated the pull request incrementally with one additional
com
> Modify the specification of `java.io.File.equals` to clarify that equality is
> based only on a comparison of abstract pathnames as opposed to the file
> system objects that the `File`s represent.
Brian Burkhalter has updated the pull request incrementally with one additional
com
Modify the specification of `java.io.File.equals` to clarify that equality is
based only on a comparison of abstract pathnames as opposed to the file system
objects that the `File`s represent.
-
Commit messages:
- 8267569: java.io.File.equals contains misleading Javadoc
Changes:
On Mon, 3 May 2021 20:33:23 GMT, Brian Burkhalter wrote:
> Please consider this request to override the `java.io.InputStream` methods
> `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more
> performant implementations. The method overrides attempt to read all
&g
045 ops/s
> ReadAllBytes.readHalfBytesFileInputStream1000 thrpt 20561.752
> ± 0.951 ops/s
> ReadAllBytes.readHalfBytesFileInputStream 1 thrpt 20 45.043
> ± 0.102 ops/s
> ReadAllBytes.readHalfBytesFileInputStream 10 thrpt 20 4.6
045 ops/s
> ReadAllBytes.readHalfBytesFileInputStream1000 thrpt 20561.752
> ± 0.951 ops/s
> ReadAllBytes.readHalfBytesFileInputStream 1 thrpt 20 45.043
> ± 0.102 ops/s
> ReadAllBytes.readHalfBytesFileInputStream 10 thrpt 20 4.629
On Mon, 10 May 2021 17:54:52 GMT, Brian Burkhalter wrote:
>> Please consider this request to override the `java.io.InputStream` methods
>> `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more
>> performant implementations. The method overrides attempt to read
On Wed, 12 May 2021 15:48:16 GMT, Daniel Fuchs wrote:
> ParentLoggersTest.java has been (rarely) seen failing with "checkLoggers:
> getLoggerNames() returned unexpected loggers"
> The suspicion is that there might be some possible interaction with other
> tests running in the same VM. This
On Thu, 6 May 2021 11:52:09 GMT, Ignasi Marimon-Clos
wrote:
>> @ignasi35 I have created JDK-8266578. Please change the name of this PR to:
>>
>> `8266578: Disambiguate BigDecimal description of scale`
>>
>> Please resolve any conflicts and commit the updated file. Once the update is
>>
045 ops/s
> ReadAllBytes.readHalfBytesFileInputStream1000 thrpt 20561.752
> ± 0.951 ops/s
> ReadAllBytes.readHalfBytesFileInputStream 1 thrpt 20 45.043
> ± 0.102 ops/s
> ReadAllBytes.readHalfBytesFileInputStream 10 thrpt
On Fri, 7 May 2021 22:46:08 GMT, Naoto Sato wrote:
> Please review this small fix to Windows system property init code. This is
> leftover from the support for `Console.charset()` method, where it lacked to
> initialize `sun.stdout/err.encoding` to `UTF-8` for the code page `cp65001`.
> The
On Thu, 6 May 2021 16:40:31 GMT, Brian Burkhalter wrote:
>> Please consider this request to override the `java.io.InputStream` methods
>> `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more
>> performant implementations. The method overrides attempt to read
On Fri, 7 May 2021 12:17:11 GMT, Vyom Tewari wrote:
>> RandomAccessFile.length() method for block device return always 0
>
> Vyom Tewari has updated the pull request incrementally with one additional
> commit since the last revision:
>
> fixed assigning -1 to uint64_t
Covers updated
On Thu, 6 May 2021 11:52:09 GMT, Ignasi Marimon-Clos
wrote:
>> @ignasi35 I have created JDK-8266578. Please change the name of this PR to:
>>
>> `8266578: Disambiguate BigDecimal description of scale`
>>
>> Please resolve any conflicts and commit the updated file. Once the update is
>>
On Fri, 9 Oct 2020 16:14:59 GMT, Ignasi Marimon-Clos
wrote:
> The API Docs for `BigDecimal` introduce the meaning of `scale`. The current
> writeup can be missleading when presenting the meaning of a `scale` value
> that's negative. Hopefully, with this PR, the sentence is more clear.
>
>
On Thu, 6 May 2021 16:57:12 GMT, Daniel Fuchs wrote:
>> Hi, please find here a trivial test change that adds some diagnostic (time
>> stamps) to the LoggerFinder/modules subprocess test logs.
>
> Daniel Fuchs has updated the pull request incrementally with one additional
> commit since the
045 ops/s
> ReadAllBytes.readHalfBytesFileInputStream1000 thrpt 20561.752
> ± 0.951 ops/s
> ReadAllBytes.readHalfBytesFileInputStream 1 thrpt 20 45.043
> ± 0.102 ops/s
> ReadAllBytes.readHalfBytesFileInputStream 10 thrpt 20 4.629
&g
On Mon, 3 May 2021 16:45:22 GMT, Ignasi Marimon-Clos
wrote:
>> Thanks @bplb. I'm afraid I'm not an
>> [author](http://openjdk.java.net/bylaws#author) or have access to create or
>> read the issues in
>> [JIRA](https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300=1).
>>
>> I am a
On Tue, 12 Jan 2021 14:07:23 GMT, Ignasi Marimon-Clos
wrote:
>> The `jcheck` test fails because "The commit message does not reference any
>> issue. To add an issue reference to this PR, edit the title to be of the
>> format `issue number: message`."
>
> Thanks @bplb. I'm afraid I'm not an
>
On Fri, 9 Oct 2020 16:14:59 GMT, Ignasi Marimon-Clos
wrote:
> The API Docs for `BigDecimal` introduce the meaning of `scale`. The current
> writeup can be missleading when presenting the meaning of a `scale` value
> that's negative. Hopefully, with this PR, the sentence is more clear.
>
>
045 ops/s
> ReadAllBytes.readHalfBytesFileInputStream1000 thrpt 20561.752
> ± 0.951 ops/s
> ReadAllBytes.readHalfBytesFileInputStream 1 thrpt 20 45.043
> ± 0.102 ops/s
> ReadAllBytes.readHalfBytesFileInputStream 10 thrpt 20 4.629
On Wed, 5 May 2021 19:10:21 GMT, Lance Andersen wrote:
> Hi all,
>
> Please review this patch which updates
> test/jdk/java/lang/ProcessHandle/PermissionTest.java &
> test/jdk/java/sql/testng/util/TestPolicy.java to include :
>
> `new PropertyPermission("testng.memory.friendly", "read");
> On May 5, 2021, at 11:09 AM, Robert Marcano wrote:
>
> Greetings. DataInputStream has some fields with the comment "working arrays
> initialized on demand by readUTF" but these fields are being initialized at
> object instantiation.
>
> On the other hand DataOutputStream has one field
On Wed, 5 May 2021 17:53:43 GMT, Joe Darcy wrote:
>> 8244146: javac changes for JEP 306
>
> Joe Darcy has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Respond to review feedback.
Changes to `java.base` look fine. The other changes should
On Wed, 5 May 2021 17:18:08 GMT, Daniel Fuchs wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8264777: Fix typo in error message
>
> src/java.base/share/classes/java/io/FileInputS
045 ops/s
> ReadAllBytes.readHalfBytesFileInputStream1000 thrpt 20561.752
> ± 0.951 ops/s
> ReadAllBytes.readHalfBytesFileInputStream 1 thrpt 20 45.043
> ± 0.102 ops/s
> ReadAllBytes.readHalfBytesFileInputStream 10 thrpt 20 4.629
&g
045 ops/s
> ReadAllBytes.readHalfBytesFileInputStream1000 thrpt 20561.752
> ± 0.951 ops/s
> ReadAllBytes.readHalfBytesFileInputStream 1 thrpt 20 45.043
> ± 0.102 ops/s
> ReadAllBytes.readHalfBytesFileInputStream 10 thrpt 20 4.629
>
On Tue, 4 May 2021 20:45:43 GMT, Lance Andersen wrote:
> Hi all,
>
> This fix addresses a change in TestNG behavior for the Before/AfterGroups
> annotations that was introduced via
> https://github.com/cbeust/testng/pull/2167. The tests have been verified
> against the latest TestNG
On Tue, 4 May 2021 22:49:22 GMT, Lance Andersen wrote:
>> Ah. I was just thinking of consistency with other tests. Up to you.
>
> I think your milage will vary depending on the author and the IDE being used.
> My primary concern was to address the issue for the failing test and
> Intellij
On Tue, 4 May 2021 22:42:57 GMT, Lance Andersen wrote:
>> test/jdk/java/io/InputStream/NullInputStream.java line 33:
>>
>>> 31: import java.io.InputStream;
>>> 32:
>>> 33: import static org.testng.Assert.*;
>>
>> Would it not be more standard to put the new imports just after this import?
>>
On Tue, 4 May 2021 20:45:43 GMT, Lance Andersen wrote:
> Hi all,
>
> This fix addresses a change in TestNG behavior for the Before/AfterGroups
> annotations that was introduced via
> https://github.com/cbeust/testng/pull/2167. The tests have been verified
> against the latest TestNG
On Tue, 4 May 2021 19:01:45 GMT, Brian Burkhalter wrote:
>> Only regular files this far. Are there any particular special files which
>> would be of interest?
>
> On `/proc/cpuinfo` for example, `fstat()` succeeds but `st_size` in `struct
> stat` is zero. The correc
045 ops/s
> ReadAllBytes.readHalfBytesFileInputStream1000 thrpt 20561.752
> ± 0.951 ops/s
> ReadAllBytes.readHalfBytesFileInputStream 1 thrpt 20 45.043
> ± 0.102 ops/s
> ReadAllBytes.readHalfBytesFileInputStream 10 thrpt 20
On Tue, 4 May 2021 17:46:15 GMT, Brian Burkhalter wrote:
>> src/java.base/share/classes/java/io/FileInputStream.java line 342:
>>
>>> 340:
>>> 341: private native long length() throws IOException;
>>> 342: private native long position() thr
On Tue, 4 May 2021 14:07:18 GMT, Alan Bateman wrote:
>> Please consider this request to override the `java.io.InputStream` methods
>> `readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more
>> performant implementations. The method overrides attempt to read all
>> requested
Please consider this request to override the `java.io.InputStream` methods
`readAllBytes()` and `readNBytes(int)` in `FileInputStream` with more
performant implementations. The method overrides attempt to read all requested
bytes into a single array of the required size rather than composing
On Tue, 27 Apr 2021 18:47:41 GMT, Brian Burkhalter wrote:
> Please consider this request to modify `Reader.read(CharBuffer)` to check
> whether the buffer is read-only before reading any characters from the
> character stream. This can happen now if the buffer is read-only.
On Tue, 27 Apr 2021 01:26:53 GMT, Brian Burkhalter wrote:
> Please consider this request to correct a minor problem with the optimization
> added for JDK-4926314. The change is to attempt to read the number of
> elements remaining in the target buffer unless that number is non
e an attempt is made to put
> them in the `CharBuffer` thus incorrectly advancing the stream position.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8266078: Remove confusing comment
-
Changes:
- all: https://git.o
On Tue, 27 Apr 2021 21:34:02 GMT, Ian Graves wrote:
> 8266155: Convert java.base to use Stream.toList()
Looks all right.
-
Marked as reviewed by bpb (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/3734
e an attempt is made to put
> them in the `CharBuffer` thus incorrectly advancing the stream position.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8266078: Make read-only check global; add message in test
-
C
On Tue, 27 Apr 2021 19:31:40 GMT, Roger Riggs wrote:
>> Please consider this request to modify `Reader.read(CharBuffer)` to check
>> whether the buffer is read-only before reading any characters from the
>> character stream. This can happen now if the buffer is read-only. Character
>> are
Please consider this request to modify `Reader.read(CharBuffer)` to check
whether the buffer is read-only before reading any characters from the
character stream. This can happen now if the buffer is read-only. Character are
first read thereby advancing the stream before an attempt is made to
ails without and passes with the
> implementation change.
Brian Burkhalter has updated the pull request incrementally with one additional
commit since the last revision:
8266014: Clean up spurious line break in the test
-
Changes:
- all: https://git.openjdk.java.net/jdk/pull/370
Please consider this request to correct a minor problem with the optimization
added for JDK-4926314. The change is to attempt to read the number of elements
remaining in the target buffer unless that number is non-positive in which case
read zero. The test addition fails without and passes with
On Sun, 25 Apr 2021 10:38:03 GMT, Philippe Marschall
wrote:
>> Implement three optimiztations for Reader.read(CharBuffer)
>>
>> * Add a code path for heap buffers in Reader#read to use the backing array
>> instead of allocating a new one.
>> * Change the code path for direct buffers in
On Sat, 13 Mar 2021 14:28:25 GMT, Philippe Marschall
wrote:
>> Implement three optimiztations for Reader.read(CharBuffer)
>>
>> * Add a code path for heap buffers in Reader#read to use the backing array
>> instead of allocating a new one.
>> * Change the code path for direct buffers in
On Wed, 21 Apr 2021 21:27:40 GMT, Joe Darcy wrote:
>> Some throws clauses in BigDecimal are uninformative and could be eliminated.
>> A few explicit throws clauses for surprising exceptions could be added.
>>
>> These are spec clarifications rather than spec changes.
>>
>> Follow-up work to
On Apr 21, 2021, at 9:23 AM, Brian Burkhalter
mailto:brian.burkhal...@oracle.com>> wrote:
There is in fact some system maintenance which should be completed this
morning, Pacific Time. After that a new issue for this should be filed as we
cannot reuse issue IDs.
Correction: not sure
On Apr 21, 2021, at 9:14 AM, Fabian Meumertzheim
mailto:github.com+4312191+fm...@openjdk.java.net>>
wrote:
On Thu, 25 Mar 2021 08:19:24 GMT, Fabian Meumertzheim
mailto:github.com+4312191+fm...@openjdk.org>>
wrote:
Adds missing @throws declarations for ArithmeticException to the public
I think this post needs to go to 2d-dev (copied).
> On Apr 20, 2021, at 9:58 AM, Lapo Luchini wrote:
>
> In both OpenJDK 8, 11 and 15 I verified that:
>
> sun/awt/image/InputStreamImageSource.java
>
> has "e.printStackTrace()" commands that might better be converted to
> java.util.logging in
On Mon, 19 Apr 2021 20:43:26 GMT, Ian Graves wrote:
> Clarifying note on comments mode to explicitly note that whitespace within
> character classes is ignored.
Looks all right. Probably a CSR is in order.
-
Marked as reviewed by bpb (Reviewer).
PR:
On Fri, 16 Apr 2021 18:07:01 GMT, Daniel D. Daugherty
wrote:
> A set of trivial ProblemListing for macos-aarch64 Tier2 test failures:
>
> - JDK-8265358 ProblemList jdk/jshell/ToolBasicTest.java on macOS-aarch64
> - JDK-8265361 ProblemList a few compiler/whitebox tests on macos-aarch64
> -
On Sat, 13 Mar 2021 14:28:25 GMT, Philippe Marschall
wrote:
>> Implement three optimiztations for Reader.read(CharBuffer)
>>
>> * Add a code path for heap buffers in Reader#read to use the backing array
>> instead of allocating a new one.
>> * Change the code path for direct buffers in
On Fri, 16 Apr 2021 16:08:53 GMT, Ian Graves wrote:
>> This fixes a bug where the formatting code for `%g` flags incorrectly tries
>> to round `BigDecimal` after determining whether it should be a decimal
>> numeric format or a scientific numeric format. The solution rounds before
>>
On Sat, 13 Mar 2021 14:28:25 GMT, Philippe Marschall
wrote:
>> Implement three optimiztations for Reader.read(CharBuffer)
>>
>> * Add a code path for heap buffers in Reader#read to use the backing array
>> instead of allocating a new one.
>> * Change the code path for direct buffers in
Hello Philippe,
> On Apr 16, 2021, at 8:43 AM, Philippe Marschall wrote:
>
> Hello
>
> I am looking for reviewers and a sponsor for JDK-4926314: Optimize
> Reader.read(CharBuffer) [1]. The PR [2] went through quite some changes
> and is now back to few changes to reduce the impact and the
On Sat, 13 Mar 2021 14:28:25 GMT, Philippe Marschall
wrote:
>> Implement three optimiztations for Reader.read(CharBuffer)
>>
>> * Add a code path for heap buffers in Reader#read to use the backing array
>> instead of allocating a new one.
>> * Change the code path for direct buffers in
On Wed, 7 Apr 2021 21:01:48 GMT, Brian Burkhalter wrote:
> The specification of the method `flush()` in the `java.io` classes
> `CharArrayWriter` and `StringWriter` is not explicit about the fact that the
> method has no effect. This request proposes to add to the specification o
On Tue, 13 Apr 2021 18:56:22 GMT, Lance Andersen wrote:
>> Hi all,
>>
>> Please review the following patch which adds additional permissions needed
>> for when JTREG upgrades to a newer version of TestNG.
>>
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with
On Fri, 9 Apr 2021 16:39:45 GMT, Brian Burkhalter wrote:
>> Hello,
>>
>> here's some background information for those that didn't follow the mailing
>> list for the last couple of years.
>>
>> Some enjoyable properties of the novel algorithm:
>>
On Fri, 9 Apr 2021 16:33:43 GMT, Raffaello Giulietti
wrote:
>> Forgot to add that other changes in the code are the use of switch
>> expressions and the use of instanceof patterns.
>
> Hello,
>
> here's some background information for those that didn't follow the mailing
> list for the last
On Thu, 8 Apr 2021 13:46:00 GMT, Roger Riggs wrote:
>> The specification of the method `flush()` in the `java.io` classes
>> `CharArrayWriter` and `StringWriter` is not explicit about the fact that the
>> method has no effect. This request proposes to add to the specification of
>> each
The specification of the method `flush()` in the `java.io` classes
`CharArrayWriter` and `StringWriter` is not explicit about the fact that the
method has no effect. This request proposes to add to the specification of each
flush() method the sentence
The {@code flush} method of {@code } does
On Apr 6, 2021, at 3:40 PM, Raffaello Giulietti
mailto:raffaello.giulie...@gmail.com>> wrote:
if there's revived interest I would be glad to migrate the code to Skara/GitHub
for a PR. The last uploaded version is still on Mercurial, I assume, under
Brian Burkhalter's webrev folder.
Is the
Hello,
This does not sound unreasonable to me, although I do not know the historical
context of the design decisions involved, on which I expect that Alan Bateman
will comment tomorrow.
As to the implementation, it might be just to modify
On Tue, 6 Apr 2021 16:46:06 GMT, Jim Laskey wrote:
>> SecureRandom is stochastic and will become unpredictable over time (hence
>> the intermittent nature).
>
> Jim Laskey has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add bug number
On Mon, 5 Apr 2021 17:06:24 GMT, Jim Laskey wrote:
> open/src/java.base/share/native/random/create_ziggurat_tables.c should not be
> in the sources.
Marked as reviewed by bpb (Reviewer).
-
PR: https://git.openjdk.java.net/jdk/pull/3343
The mailing list mangled formatting. My comments are prefixed below by “->”.
On Apr 5, 2021, at 9:52 AM, Brian Burkhalter
mailto:brian.burkhal...@oracle.com>> wrote:
On Apr 5, 2021, at 4:11 AM, Andrew Haley
mailto:a...@redhat.com><mailto:a...@redhat.com>> wrote:
On
The mailing list mangled formatting. My comments are prefixed below by “->”.
On Apr 5, 2021, at 9:52 AM, Brian Burkhalter
mailto:brian.burkhal...@oracle.com>> wrote:
On Apr 5, 2021, at 4:11 AM, Andrew Haley
mailto:a...@redhat.com><mailto:a...@redhat.com>> wrote:
On
shop just after FOSDEM 2020. Brian Burkhalter and Andrew Dinn had
both put time into looking at the proposal it but the conclusion was
that Raffaello's paper "The Schubfach way to render doubles" needed a
review from from an expert in this area.
I spent some time on it a while back but
On Fri, 2 Apr 2021 21:45:58 GMT, Brian Burkhalter wrote:
> This test emits to a `java.io.ByteArrayOutputStream` the contents of a
> `java.utils.prefs.Preferences` node. The `UTF-8` character encoding is used
> [1]. The `ByteArrayOutputStream` is then converted to a `String` using
&g
This test emits to a `java.io.ByteArrayOutputStream` the contents of a
`java.utils.prefs.Preferences` node. The `UTF-8` character encoding is used
[1]. The `ByteArrayOutputStream` is then converted to a `String` using
`toString()` which uses the platform's default character set [2]. The
On Thu, 1 Apr 2021 22:15:01 GMT, Joe Darcy wrote:
> Simple change to make the exception/error messages more informative for
> various malformed annotation situations.
Looks fine.
-
Marked as reviewed by bpb (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/3317
On Thu, 1 Apr 2021 18:12:43 GMT, Joe Darcy wrote:
> Please review this small code change and its accompanying CSR:
>
> https://bugs.openjdk.java.net/browse/JDK-8264610
CSR also reviewed.
-
Marked as reviewed by bpb (Reviewer).
PR: https://git.openjdk.java.net/jdk/pull/3314
On Wed, 31 Mar 2021 11:15:43 GMT, Stefan Karlsson wrote:
>> Add more logging to the LargeCopyWithMark.java test, to gather more
>> information when this test fails with OOME.
>>
>> The intention is to gather more info for JDK-8239089.
>>
>> I consider this patch trivial, and expect to push
301 - 400 of 1769 matches
Mail list logo
