On Thu, 18 Mar 2021 21:03:20 GMT, Rafael Winterhalter
wrote:
> 8263763: The constructor of an enumeration prefixes with two synthetic
> arguments for constant name and ordinal index. For this reason, the
> constructor annotations need to be shifted two indices to the right, such
> that the
Hi Lance,
Thanks a lot for your comments!
The CSR has been proposed at https://bugs.openjdk.java.net/browse/JDK-8263793,
but it seems I can not add it to the github PR.
I am WIP on the test coverage, will update the PR when it is ready.
BRs,
Lin
From: Lance Andersen
Date: Thursday, March 18,
On Tue, 16 Mar 2021 04:55:23 GMT, Ian Graves wrote:
>> This converts jpackage to use `Stream.toList()` instead of
>> `Stream.collect(Collectors.toList())`. One piece of code was modified to not
>> mutate a list in addition to one test that used a mutating sort on a list.
>> The rest of the
On Thu, 18 Mar 2021 22:56:53 GMT, Claes Redestad wrote:
>> I don't object this dead code elimination. I don't know the design/thought
>> when these unused canonicalization codes were defined.
>
> This code appear to have been initially introduced with the JDK 7
> implementation of JSR 292,
On Thu, 18 Mar 2021 21:37:53 GMT, Mandy Chung wrote:
>> MethodTypeForm.INTS, LONGS and RAW_RETURN are effectively unused. This
>> removes these canonicalization codes and cleans up related code.
>
> I don't object this dead code elimination. I don't know the design/thought
> when these unused
On Wed, 17 Mar 2021 00:57:24 GMT, Henry Jen wrote:
>> This patch ensure launcher won't crash JVM for the new static Methods from
>> local/anonymous class on MacOS.
>>
>> As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug
>> when the launcher trying to grab class name to
On Thu, 18 Mar 2021 11:56:23 GMT, Alan Bateman wrote:
>> Brian Burkhalter has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8251942: Scale back class level spec change
>
> Marked as reviewed by alanb (Reviewer).
CSR filed:
On Thu, 18 Mar 2021 19:51:06 GMT, Ian Graves wrote:
>> @igraves as a "best practice" try to avoid doing a force-push to a branch
>> with an active code review. It makes it hard for reviewers to see what has
>> changed. If you need to merge changes from master, use "git merge master"
>>
On Thu, 18 Mar 2021 15:08:56 GMT, Jim Laskey wrote:
>> This PR is to introduce a new random number API for the JDK. The primary API
>> is found in RandomGenerator and RandomGeneratorFactory. Further description
>> can be found in the JEP https://openjdk.java.net/jeps/356 .
>>
>> javadoc can
On Thu, 18 Mar 2021 15:42:49 GMT, Claes Redestad wrote:
> MethodTypeForm.INTS, LONGS and RAW_RETURN are effectively unused. This
> removes these canonicalization codes and cleans up related code.
I don't object this dead code elimination. I don't know the design/thought
when these unused
On Tue, 9 Mar 2021 21:37:16 GMT, Roger Riggs wrote:
> ObjectStreamPrinter is a Formatter plugin to the test library HexPrinter.
>
> A binary stream of serialized java objects is converted into a textual form
> by parsing the header, typecodes, and interpreting the stream contents. The
>
8263763: The constructor of an enumeration prefixes with two synthetic
arguments for constant name and ordinal index. For this reason, the constructor
annotations need to be shifted two indices to the right, such that the
annotation indices match with the parameter indices.
-
On Thu, 18 Mar 2021 19:43:10 GMT, Kevin Rushforth wrote:
>> This converts jpackage to use `Stream.toList()` instead of
>> `Stream.collect(Collectors.toList())`. One piece of code was modified to not
>> mutate a list in addition to one test that used a mutating sort on a list.
>> The rest of
On Sun, 14 Mar 2021 18:22:50 GMT, Ian Graves wrote:
> This converts jpackage to use `Stream.toList()` instead of
> `Stream.collect(Collectors.toList())`. One piece of code was modified to not
> mutate a list in addition to one test that used a mutating sort on a list.
> The rest of the
On Thu, 18 Mar 2021 17:02:57 GMT, Alex Blewitt
wrote:
>> Sonar displays a warning message that modifiers should be declared in the
>> order listed in the JLS; specifically, that isntead of using `final static`
>> the `static final` should be preferred.
>>
>> This fixes the issues in the
On Thu, 18 Mar 2021 17:06:04 GMT, Alex Blewitt
wrote:
>>> If I have other fixes for different modules, should I file PRs with the
>>> same bug number e.g. "8263658: Use the blessed modifier order in
>>> java.logging/java.desktop" or should we have separate bug numbers for them?
>>
>>
On Thu, 18 Mar 2021 16:51:35 GMT, Alex Blewitt
wrote:
> If I have other fixes for different modules, should I file PRs with the same
> bug number e.g. "8263658: Use the blessed modifier order in
> java.logging/java.desktop" or should we have separate bug numbers for them?
Separate bug
On Thu, 18 Mar 2021 17:03:28 GMT, Claes Redestad wrote:
>> If I have other fixes for different modules, should I file PRs with the same
>> bug number e.g. "8263658: Use the blessed modifier order in
>> java.logging/java.desktop" or should we have separate bug numbers for them?
>
>> If I have
On Thu, 18 Mar 2021 16:50:39 GMT, Claes Redestad wrote:
>> Is that there to indicate a placeholder value that was once used and is kept
>> for documentation purposes? Should the corresponding JavaDoc be removed as
>> well? Should I do this in the same commit/PR as this one, or submit a new
>>
> Sonar displays a warning message that modifiers should be declared in the
> order listed in the JLS; specifically, that isntead of using `final static`
> the `static final` should be preferred.
>
> This fixes the issues in the `java.base` package for ease of reviewing.
>
>
On 3/18/2021 9:53 AM, Alex Blewitt wrote:
On Thu, 18 Mar 2021 14:50:43 GMT, Claes Redestad wrote:
Sonar displays a warning message that modifiers should be declared in the order
listed in the JLS; specifically, that isntead of using `final static` the
`static final` should be preferred.
On Thu, 18 Mar 2021 16:42:39 GMT, Alex Blewitt
wrote:
>> Yeah, I agree.
>
> Is that there to indicate a placeholder value that was once used and is kept
> for documentation purposes? Should the corresponding JavaDoc be removed as
> well? Should I do this in the same commit/PR as this one, or
On Thu, 18 Mar 2021 14:50:43 GMT, Claes Redestad wrote:
>> Sonar displays a warning message that modifiers should be declared in the
>> order listed in the JLS; specifically, that isntead of using `final static`
>> the `static final` should be preferred.
>>
>> This fixes the issues in the
On Thu, 18 Mar 2021 15:08:09 GMT, Aleksey Shipilev wrote:
>> src/java.base/share/classes/com/sun/security/ntlm/NTLMException.java line 52:
>>
>>> 50: * from server.
>>> 51: */
>>> 52: //public static final int DOMAIN_UNMATCH = 3;
>>
>> Maybe this one ought to be removed instead?
On Tue, 9 Mar 2021 21:37:16 GMT, Roger Riggs wrote:
> ObjectStreamPrinter is a Formatter plugin to the test library HexPrinter.
>
> A binary stream of serialized java objects is converted into a textual form
> by parsing the header, typecodes, and interpreting the stream contents. The
>
MethodTypeForm.INTS, LONGS and RAW_RETURN are effectively unused. This removes
these canonicalization codes and cleans up related code.
-
Commit messages:
- Minor simplifications
- Remove unused MethodTypeForm canonicalization codes
Changes:
On Thu, 18 Mar 2021 15:19:20 GMT, Peter Levart wrote:
>>> The test expects there to be zero output from the child (and it doesn't
>>> matter what state the child is in).
>>> Can the logging from the VM be disabled or re-directed?
>>
>> Not to the extend that it would be guaranteed never to
On Thu, 18 Mar 2021 15:19:20 GMT, Peter Levart wrote:
>>> The test expects there to be zero output from the child (and it doesn't
>>> matter what state the child is in).
>>> Can the logging from the VM be disabled or re-directed?
>>
>> Not to the extend that it would be guaranteed never to
Hi Lin,
Thank you for your contribution.
I have no looked at this in any detail. A few general comments:
* This will require a CSR
* Please update your PR to include test coverage demonstrating that the
data can be written and then read back
Best,
Lance
On Mar 18, 2021, at 6:57
On Thu, 18 Mar 2021 14:30:21 GMT, Thomas Stuefe wrote:
>> The test expects there to be zero output from the child (and it doesn't
>> matter what state the child is in).
>> Can the logging from the VM be disabled or re-directed?
>
>> The test expects there to be zero output from the child (and
On Wed, 17 Mar 2021 12:31:22 GMT, Claes Redestad wrote:
>> Sonar displays a warning message that modifiers should be declared in the
>> order listed in the JLS; specifically, that isntead of using `final static`
>> the `static final` should be preferred.
>>
>> This fixes the issues in the
> This PR is to introduce a new random number API for the JDK. The primary API
> is found in RandomGenerator and RandomGeneratorFactory. Further description
> can be found in the JEP https://openjdk.java.net/jeps/356 .
>
> javadoc can be found at
>
On Sat, 13 Mar 2021 22:45:30 GMT, Alex Blewitt
wrote:
> Sonar displays a warning message that modifiers should be declared in the
> order listed in the JLS; specifically, that isntead of using `final static`
> the `static final` should be preferred.
>
> This fixes the issues in the
On Thu, 18 Mar 2021 13:41:01 GMT, Roger Riggs wrote:
> The test expects there to be zero output from the child (and it doesn't
> matter what state the child is in).
> Can the logging from the VM be disabled or re-directed?
Not to the extend that it would be guaranteed never to happen. Even if
On Wed, 17 Mar 2021 20:03:16 GMT, Thomas Stuefe wrote:
>> Its a Java Child for consistency across tests and across OS's.
>> The JavaChild executes a number of specialized commands to consume or
>> provide data to the parent.
>> Piecing that together on different OS's would add more variables
On Tue, 16 Mar 2021 20:37:57 GMT, Tommy Ettinger
wrote:
>> This is now looking very nicely structured.
>>
>> The only thing i am unsure are the details around `RandomGenerator` being a
>> service provider interface. The documentation mentions this at various
>> points (mostly as
On Mon, 15 Mar 2021 23:02:33 GMT, Joe Darcy wrote:
>> Jim Laskey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Missing @since
>
> src/java.base/share/classes/java/util/Random.java line 135:
>
>> 133: * number generator which is
On Mon, 15 Mar 2021 23:07:53 GMT, Joe Darcy wrote:
>> Jim Laskey has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Missing @since
>
> src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line
> 62:
>
>> 60:
On Thu, 28 Jan 2021 19:21:28 GMT, Claes Redestad wrote:
> - Remove unused code
> - Inline and simplify the bootstrap method invocation code (remove pointless
> reboxing checks etc)
> - Apply pattern matching to make some code more readable
This pull request has now been integrated.
Changeset:
On Thu, 11 Mar 2021 20:57:24 GMT, Brian Burkhalter wrote:
>> Please review this minor change to the specification of
>> `java.io.PrintStream`. The longstanding behavior for flushing is to invoke
>> the `flush()` method of the underlying `OutputStream` rather than its
>> override but this was
On Thu, 11 Mar 2021 20:57:24 GMT, Brian Burkhalter wrote:
>> Please review this minor change to the specification of
>> `java.io.PrintStream`. The longstanding behavior for flushing is to invoke
>> the `flush()` method of the underlying `OutputStream` rather than its
>> override but this was
On Thu, 18 Mar 2021 10:46:04 GMT, Lin Zang wrote:
> 4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional
> GZIP fields
Dear All,
This PR introduce new constructor of GZIPOutputStream to support adding extra
field info in gzip file header, as decribed in RFC 1952 gzip
4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional
GZIP fields
-
Commit messages:
- remove trailing spaces
- 4890732: support optional GZIP fields in GZIPOutputStream
Changes: https://git.openjdk.java.net/jdk/pull/3072/files
Webrev:
43 matches
Mail list logo
