Re: RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields

[Lin Zang]

On Thu, 18 Mar 2021 10:50:05 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 spec 
> (https://tools.ietf.org/html/rfc1952).
> BTW, does a CSR required for this PR?  
> 
> Thanks!
> Lin

The CSR has been submitted at https://bugs.openjdk.java.net/browse/JDK-8263793

-

PR: https://git.openjdk.java.net/jdk/pull/3072

Re: RFR: 8263763: Synthetic constructor parameters of enum are not considered for annotation indices

[Joe Darcy]

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 annotation indices match with the parameter indices.

A general comment, the enum constructor situation is a bit tricky as

1) There is no 100% reliable way to determine which of a enum constructor's 
args are synthetic.

2) How a Java compiler generates enum constructors is a compiler-internal 
contract since all the enum constructors must be private.

It is true that javac has consistently added two extra parameters as an 
implementation detail. Offhand, I don't know if ecj in particular has made the 
same choice. javac is not obliged to continue implementing enum constructors in 
this manner, so for better robustness, I think a fix in this space needs to be 
able to accommodate situations other than exactly N+2 parameters.

-

PR: https://git.openjdk.java.net/jdk/pull/3082

Re: 4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields(Internet mail)

[臧琳]

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, 2021 at 11:25 PM
To: Lin Zang 
Cc: "core-libs-dev@openjdk.java.net" 
Subject: Re: RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts, 
use of optional GZIP fields(Internet mail)

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 AM, Lin Zang 
mailto:lz...@openjdk.java.net>> wrote:

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: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=00
 Issue: https://bugs.openjdk.java.net/browse/JDK-4890732
 Stats: 184 lines in 1 file changed: 184 ins; 0 del; 0 mod
 Patch: https://git.openjdk.java.net/jdk/pull/3072.diff
 Fetch: git fetch https://git.openjdk.java.net/jdk pull/3072/head:pull/3072

PR: https://git.openjdk.java.net/jdk/pull/3072

[cid:image001.gif@01D71CAA.9557DB60]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: JDK-8263545: Convert jpackage to use Stream.toList() [v3]

[Alexey Semenyuk]

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 changes are simple substitutions.
>
> Ian Graves has updated the pull request with a new target base due to a merge 
> or a rebase. The pull request now contains two commits:
> 
>  - Clarifying type argument and shorting a toArray invocation
>  - Converting jpackage to use Stream.toList()

Marked as reviewed by asemenyuk (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/2997

Re: RFR: 8263821: Remove unused MethodTypeForm canonicalization codes

[Mandy Chung]

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, which implemented different ways of adapting to 
> and from generic types than the current code: 
> https://bugs.openjdk.java.net/browse/JDK-6839872
> 
> Many uses (possibly all) were removed in 
> https://bugs.openjdk.java.net/browse/JDK-6983728 (8-b01) where adapters were 
> reworked. This was backported to 7, so the code I'm removing here is probably 
> dead in all active releases.

Thanks for the history.

-

PR: https://git.openjdk.java.net/jdk/pull/3075

Re: RFR: 8263821: Remove unused MethodTypeForm canonicalization codes

[Claes Redestad]

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 canonicalization codes were defined.

This code appear to have been initially introduced with the JDK 7 
implementation of JSR 292, which implemented different ways of adapting to and 
from generic types than the current code: 
https://bugs.openjdk.java.net/browse/JDK-6839872

Many uses (possibly all) were removed in 
https://bugs.openjdk.java.net/browse/JDK-6983728 (8-b01) where adapters were 
reworked. This was backported to 7, so the code I'm removing here is probably 
dead in all active releases.

-

PR: https://git.openjdk.java.net/jdk/pull/3075

Re: RFR: 8261785: Calling "main" method in anonymous nested class crashes the JVM [v3]

[Sergey Bylokhov]

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 be displayed as the 
>> Application name on the menu.
>> 
>> The fix is to not setting name, test shows that GUI java application shows 
>> 'bin' as the application name. It's possible for us to set the name to 
>> something more friendly, for example, "Java", but I am not sure that should 
>> be launcher's responsibility to choose such a default name. It seems to me 
>> the consumer of the JAVA_MAIN_CLASS_%d environment variable should be 
>> responsible to pick such name in case the environment variable is not set.
>
> Henry Jen has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Add copyright and another test case

Looks fine from the client point of view.

-

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2999

Re: RFR: 8251942: PrintStream specification is not clear which flush method is automatically invoked [v2]

[Brian Burkhalter]

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: https://bugs.openjdk.java.net/browse/JDK-8263835.

-

PR: https://git.openjdk.java.net/jdk/pull/2926

Re: RFR: JDK-8263545: Convert jpackage to use Stream.toList()

[Alexander Matveev]

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" 
>> instead.
>> 
>> @alexeysemenyukoracle @sashamatveev Can you re-review this so Ian can 
>> integrate it?
>
> @kevinrushforth Understood, thanks!

Looks fine.

-

PR: https://git.openjdk.java.net/jdk/pull/2997

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v32]

[Joe Darcy]

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 be found at 
>> http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
>> 
>> old PR:  https://github.com/openjdk/jdk/pull/1273
>
> Jim Laskey has updated the pull request with a new target base due to a merge 
> or a rebase. The pull request now contains 67 commits:
> 
>  - Merge branch 'master' into 8248862
>  - Review revisions
>  - Missing @since
>  - Review revisions
>  - Review requested changes
>  - Merge branch 'master' into 8248862
>  - Remove conflicts
>  - Use isAnnotationPresent
>  - Introduce isDeprecated
>  - Update javadoc
>  - ... and 57 more: 
> https://git.openjdk.java.net/jdk/compare/8c8d1b31...63094f9d

Changes requested by darcy (Reviewer).

src/java.base/share/classes/java/util/random/RandomGenerator.java line 1290:

> 1288:  * @return a new object that is a copy of this generator
> 1289:  */
> 1290: LeapableGenerator copy();

Suggest adding an Override annotation here and possibly to inheritDoc the text 
from Jumpable.copy.

src/java.base/share/classes/java/util/random/RandomGenerator.java line 1455:

> 1453:  *  period of this generator
> 1454:  */
> 1455: void jump(double distance);

Suggest Override and inheritDoc combo.

src/java.base/share/classes/java/util/random/RandomGenerator.java line 1465:

> 1463:  * @implSpec The default implementation invokes 
> jump(jumpDistance()).
> 1464:  */
> 1465: default void jump() { jump(jumpDistance()); }

Should be able to avoid defining the jump method in this subinterface.

src/java.base/share/classes/java/util/random/RandomGenerator.java line 1486:

> 1484:  * ({@link Long#MAX_VALUE Long.MAX_VALUE}).
> 1485:  */
> 1486: default Stream jumps(double 
> distance) {

Suggest adding an Override annotation.

src/java.base/share/classes/java/util/random/RandomGenerator.java line 1521:

> 1519:  * {@link ArbitrarilyJumpableGenerator#leapDistance() 
> leapDistance}().
> 1520:  */
> 1521: default void leap() { jump(leapDistance()); }

Should need to define this method in the subinterface of Leapable.

src/java.base/share/classes/java/util/random/RandomGenerator.java line 1538:

> 1536:  * returns the copy.
> 1537:  */
> 1538: default ArbitrarilyJumpableGenerator copyAndJump(double 
> distance) {

Suggest Override and inheritDoc.

-

PR: https://git.openjdk.java.net/jdk/pull/1292

Re: RFR: 8263821: Remove unused MethodTypeForm canonicalization codes

[Mandy Chung]

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 canonicalization codes were defined.

-

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3075

Integrated: 8263320: [test] Add Object Stream Formatter to work with test utility HexPrinter

[Roger Riggs]

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 
> formatter can be used standalone or with the HexPrinter to align the 
> formatted stream with the corresponding hexadecimal bytes.
> 
> StreamDump is a test utility to pass the contents of a file to the HexPrinter 
> utility. The format of the file is guessed from the encoding and initial 
> bytes. ASN.1 and serialized object streams are supported.

This pull request has now been integrated.

Changeset: 788e30c1
Author:Roger Riggs 
URL:   https://git.openjdk.java.net/jdk/commit/788e30c1
Stats: 1684 lines in 4 files changed: 1684 ins; 0 del; 0 mod

8263320: [test] Add Object Stream Formatter to work with test utility HexPrinter

Reviewed-by: chegar

-

PR: https://git.openjdk.java.net/jdk/pull/2900

RFR: 8263763: Synthetic constructor parameters of enum are not considered for annotation indices

[Rafael Winterhalter]

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.

-

Commit messages:
 - 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.

Changes: https://git.openjdk.java.net/jdk/pull/3082/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3082&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263763
  Stats: 65 lines in 3 files changed: 60 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3082.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3082/head:pull/3082

PR: https://git.openjdk.java.net/jdk/pull/3082

Re: RFR: JDK-8263545: Convert jpackage to use Stream.toList()

[Ian Graves]

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 the changes are simple substitutions.
>
> @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" 
> instead.
> 
> @alexeysemenyukoracle @sashamatveev Can you re-review this so Ian can 
> integrate it?

@kevinrushforth Understood, thanks!

-

PR: https://git.openjdk.java.net/jdk/pull/2997

Re: RFR: JDK-8263545: Convert jpackage to use Stream.toList()

[Kevin Rushforth]

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 changes are simple substitutions.

@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" instead.

@alexeysemenyukoracle @sashamatveev Can you re-review this so Ian can integrate 
it?

-

PR: https://git.openjdk.java.net/jdk/pull/2997

Re: RFR: 8263658: Use the blessed modifier order in java.base [v2]

[Claes Redestad]

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 `java.base` package for ease of reviewing.
>> 
>> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124
>
> Alex Blewitt has refreshed the contents of this pull request, and previous 
> commits have been removed. The incremental views will show differences 
> compared to the previous content of the PR.

Marked as reviewed by redestad (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/2993

Re: RFR: 8263658: Use the blessed modifier order in java.base [v2]

[Claes Redestad]

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?
>> 
>> Separate bug numbers is necessary. Unless you repurpose / widen this PR to 
>> include more modules.
>> 
>> A word of advice: Avoid git rebase + force push after opening a PR for 
>> review, since it might mess up the review context. Preferably either merge 
>> in changes from main, or just keep adding commits without syncing up - the 
>> system will ensure your patch can be merged in without conflicts.
>
> I'm happy to either widen the scope of this PR or to submit multiple but I 
> have to rely on the kindness of strangers to create appropriate bugs in the 
> system. On the one hand I don't want to cause a lot of noise but  on the 
> other having smaller independent commits (particularly if they hit a lot of 
> files/modules) seems like a more sensible plan to me.

There's some extra churn in splitting it up, sure, but different modules are 
often maintained by different people so getting changes that span the entire 
JDK reviewed might actually take you longer.  YMMV. I can assist creating RFEs.

-

PR: https://git.openjdk.java.net/jdk/pull/2993

Re: RFR: 8263658: Use the blessed modifier order in java.base [v2]

[Claes Redestad]

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 numbers is necessary. Unless you repurpose / widen this PR to 
include more modules.

A word of advice: Avoid git rebase + force push after opening a PR for review, 
since it might mess up the review context. Preferably either merge in changes 
from main, or just keep adding commits without syncing up - the system will 
ensure your patch can be merged in without conflicts.

-

PR: https://git.openjdk.java.net/jdk/pull/2993

Re: RFR: 8263658: Use the blessed modifier order in java.base [v2]

[Alex Blewitt]

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 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 numbers is necessary. Unless you repurpose / widen this PR to 
> include more modules.
> 
> A word of advice: Avoid git rebase + force push after opening a PR for 
> review, since it might mess up the review context. Preferably either merge in 
> changes from main, or just keep adding commits without syncing up - the 
> system will ensure your patch can be merged in without conflicts.

I'm happy to either widen the scope of this PR or to submit multiple but I have 
to rely on the kindness of strangers to create appropriate bugs in the system. 
On the one hand I don't want to cause a lot of noise but  on the other having 
smaller independent commits (particularly if they hit a lot of files/modules) 
seems like a more sensible plan to me.

-

PR: https://git.openjdk.java.net/jdk/pull/2993

Re: RFR: 8263658: Use the blessed modifier order in java.base [v2]

[Alex Blewitt]

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 
>> PR? Would prefer to avoid conflating fixes if possible so that if one needs 
>> to be reverted we don't revert the related changes.
>
> There's another constant with value 3 defined, so I think this is just some 
> left-over. 
> 
> If you prefer separating out the removal to another RFE I'd remove this 
> particular change from this PR.

Filed #3076 for the removal and updated this PR without it

-

PR: https://git.openjdk.java.net/jdk/pull/2993

Re: RFR: 8263658: Use the blessed modifier order in java.base [v2]

[Alex Blewitt]

> 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.
> 
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124

Alex Blewitt has refreshed the contents of this pull request, and previous 
commits have been removed. The incremental views will show differences compared 
to the previous content of the PR. The pull request contains one new commit 
since the last revision:

  8263658: Use the blessed modifier order in java.base

-

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2993/files
  - new: https://git.openjdk.java.net/jdk/pull/2993/files/470f7066..86aa9a34

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2993&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2993&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2993.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2993/head:pull/2993

PR: https://git.openjdk.java.net/jdk/pull/2993

Re: RFR: 8263658: Use the blessed modifier order in java.base

[Joe Darcy]

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.

This fixes the issues in the `java.base` package for ease of reviewing.

https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124

Marked as reviewed by redestad (Reviewer).

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 numbers please. It is also possible to use an umbrella 
issue and have issues for, say each module, be subtasks.


-Joe

Re: RFR: 8263658: Use the blessed modifier order in java.base

[Claes Redestad]

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 submit a new PR? 
> Would prefer to avoid conflating fixes if possible so that if one needs to be 
> reverted we don't revert the related changes.

There's another constant with value 3 defined, so I think this is just some 
left-over. 

If you prefer separating out the removal to another RFE I'd remove this 
particular change from this PR.

-

PR: https://git.openjdk.java.net/jdk/pull/2993

Re: RFR: 8263658: Use the blessed modifier order in java.base

[Alex Blewitt]

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 `java.base` package for ease of reviewing.
>> 
>> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124
>
> Marked as reviewed by redestad (Reviewer).

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?

-

PR: https://git.openjdk.java.net/jdk/pull/2993

Re: RFR: 8263658: Use the blessed modifier order in java.base

[Alex Blewitt]

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?
>
> 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 submit a new PR? 
Would prefer to avoid conflating fixes if possible so that if one needs to be 
reverted we don't revert the related changes.

-

PR: https://git.openjdk.java.net/jdk/pull/2993

Re: RFR: 8263320: [test] Add Object Stream Formatter to work with test utility HexPrinter

[Chris Hegarty]

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 
> formatter can be used standalone or with the HexPrinter to align the 
> formatted stream with the corresponding hexadecimal bytes.
> 
> StreamDump is a test utility to pass the contents of a file to the HexPrinter 
> utility. The format of the file is guessed from the encoding and initial 
> bytes. ASN.1 and serialized object streams are supported.

Marked as reviewed by chegar (Reviewer).

-

PR: https://git.openjdk.java.net/jdk/pull/2900

RFR: 8263821: Remove unused MethodTypeForm canonicalization codes

[Claes Redestad]

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: https://git.openjdk.java.net/jdk/pull/3075/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3075&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263821
  Stats: 45 lines in 2 files changed: 0 ins; 35 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3075.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3075/head:pull/3075

PR: https://git.openjdk.java.net/jdk/pull/3075

Re: RFR: 8263729: [test] Extend time to wait before destroying child in ProcssBuilder Basic test

[Roger Riggs]

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 happen. Even if we 
>> control all output in the hotspot, there are other libraries. E.g. glibc 
>> writes a lengthy report to stderr in case of a heap corruption, which I 
>> believe does not result in a hs-err file.
>> 
>> One simple solution, simpler than using two threads, could be to use 
>> ProcessBuilder::redirectError(Redirect.INHERIT) if reading stdout resp. 
>> ProcessBuilder::redirectOutput(Redirect.INHERIT) if reading stderr. One 
>> line, takes care of the stream you don't read does not block, and, we can 
>> see the child output in the parent stdout/err.
>
>> That complicates the test and the child quite a bit for minimal gain.
> 
> Suppose that the child process writes 1 byte to STDOUT and 1 byte to STDERR. 
> In the monitoring thread in the parent process, you could read 1 byte from 
> either STDOUT or STDERR, then count-down the latch and then block in next 
> read. The main thread could then just wait for the latch, wait for the 
> monitoring thread to re-enter the synchronized read method and then destroy 
> the process... It doesn't sound too complicated. WDYT?

@plevart, I prototyped using that technique but was concerned that it might 
change the test case to be different in some subtle way from the original. It 
adds a new subcommand to the JavaChild to add the specific behavior.
Not particularly complex but more code and dependencies to explain.

-

PR: https://git.openjdk.java.net/jdk/pull/3049

Re: RFR: 8263729: [test] Extend time to wait before destroying child in ProcssBuilder Basic test

[Roger Riggs]

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 happen. Even if we 
>> control all output in the hotspot, there are other libraries. E.g. glibc 
>> writes a lengthy report to stderr in case of a heap corruption, which I 
>> believe does not result in a hs-err file.
>> 
>> One simple solution, simpler than using two threads, could be to use 
>> ProcessBuilder::redirectError(Redirect.INHERIT) if reading stdout resp. 
>> ProcessBuilder::redirectOutput(Redirect.INHERIT) if reading stderr. One 
>> line, takes care of the stream you don't read does not block, and, we can 
>> see the child output in the parent stdout/err.
>
>> That complicates the test and the child quite a bit for minimal gain.
> 
> Suppose that the child process writes 1 byte to STDOUT and 1 byte to STDERR. 
> In the monitoring thread in the parent process, you could read 1 byte from 
> either STDOUT or STDERR, then count-down the latch and then block in next 
> read. The main thread could then just wait for the latch, wait for the 
> monitoring thread to re-enter the synchronized read method and then destroy 
> the process... It doesn't sound too complicated. WDYT?

Redirecting the stream not being tested to INHERIT may be useful.
But the failing case is when the vm output is being directed to the stream 
being tested.
The command line arguments are:
Arrays.asList(javaExe,
"-XX:+DisplayVMOutputToStderr",
"-classpath", absolutifyPath(classpath),
"Basic$JavaChild");```
A combination of redirecting to inherited and sending the VM output to the same 
(untested) stream seems like a good option.

-

PR: https://git.openjdk.java.net/jdk/pull/3049

Re: RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields

[Lance Andersen]

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 AM, Lin Zang 
mailto:lz...@openjdk.java.net>> wrote:

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: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=00
 Issue: https://bugs.openjdk.java.net/browse/JDK-4890732
 Stats: 184 lines in 1 file changed: 184 ins; 0 del; 0 mod
 Patch: https://git.openjdk.java.net/jdk/pull/3072.diff
 Fetch: git fetch https://git.openjdk.java.net/jdk pull/3072/head:pull/3072

PR: https://git.openjdk.java.net/jdk/pull/3072

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC@home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
lance.ander...@oracle.com

Re: RFR: 8263729: [test] Extend time to wait before destroying child in ProcssBuilder Basic test

[Peter Levart]

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 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 we 
> control all output in the hotspot, there are other libraries. E.g. glibc 
> writes a lengthy report to stderr in case of a heap corruption, which I 
> believe does not result in a hs-err file.
> 
> One simple solution, simpler than using two threads, could be to use 
> ProcessBuilder::redirectError(Redirect.INHERIT) if reading stdout resp. 
> ProcessBuilder::redirectOutput(Redirect.INHERIT) if reading stderr. One line, 
> takes care of the stream you don't read does not block, and, we can see the 
> child output in the parent stdout/err.

> That complicates the test and the child quite a bit for minimal gain.

Suppose that the child process writes 1 byte to STDOUT and 1 byte to STDERR. In 
the monitoring thread in the parent process, you could read 1 byte from either 
STDOUT or STDERR, then count-down the latch and then block in next read. The 
main thread could then just wait for the latch, wait for the monitoring thread 
to re-enter the synchronized read method and then destroy the process... It 
doesn't sound too complicated. WDYT?

-

PR: https://git.openjdk.java.net/jdk/pull/3049

Re: RFR: 8263658: Use the blessed modifier order in java.base

[Aleksey Shipilev]

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 `java.base` package for ease of reviewing.
>> 
>> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124
>
> 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?

Yeah, I agree.

-

PR: https://git.openjdk.java.net/jdk/pull/2993

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v32]

[Jim Laskey]

> 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 
> http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request with a new target base due to a merge 
or a rebase. The pull request now contains 67 commits:

 - Merge branch 'master' into 8248862
 - Review revisions
 - Missing @since
 - Review revisions
 - Review requested changes
 - Merge branch 'master' into 8248862
 - Remove conflicts
 - Use isAnnotationPresent
 - Introduce isDeprecated
 - Update javadoc
 - ... and 57 more: https://git.openjdk.java.net/jdk/compare/8c8d1b31...63094f9d

-

Changes: https://git.openjdk.java.net/jdk/pull/1292/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=31
  Stats: 13653 lines in 26 files changed: 11537 ins; 1821 del; 295 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

PR: https://git.openjdk.java.net/jdk/pull/1292

Re: RFR: 8263658: Use the blessed modifier order in java.base

[Claes Redestad]

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 `java.base` package for ease of reviewing.
> 
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124

Marked as reviewed by redestad (Reviewer).

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?

-

PR: https://git.openjdk.java.net/jdk/pull/2993

Re: RFR: 8263729: [test] Extend time to wait before destroying child in ProcssBuilder Basic test

[Thomas Stuefe]

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 we 
control all output in the hotspot, there are other libraries. E.g. glibc writes 
a lengthy report to stderr in case of a heap corruption, which I believe does 
not result in a hs-err file.

One simple solution, simpler than using two threads, could be to use 
ProcessBuilder::redirectError(Redirect.INHERIT) if reading stdout resp. 
ProcessBuilder::redirectOutput(Redirect.INHERIT) if reading stderr. One line, 
takes care of the stream you don't read does not block, and, we can see the 
child output in the parent stdout/err.

-

PR: https://git.openjdk.java.net/jdk/pull/3049

Re: RFR: 8263729: [test] Extend time to wait before destroying child in ProcssBuilder Basic test

[Roger Riggs]

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 to the 
>> tests.
>> In this particular case, assuming it's well understood could probably be 
>> handled by some native program
>> as long its available on all platforms consistently.
>
>> 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 to the 
>> tests.
>> In this particular case, assuming it's well understood could probably be 
>> handled by some native program
>> as long its available on all platforms consistently.
> 
> Thanks Roger for explaining. Sorry for the questions. We are bugged regularly 
> by similar intermittent errors and I am curious and interested in getting 
> tests stable.
> 
> I'm still thinking reading both stdout and stderr simultaneously would be 
> more defensive in case the child dies of unnatural circumstances, or prints 
> out unexpected output. The VM does this sometimes (eg unconditonal logging, 
> or crashing), and we have seen blockages like these when childs waited on 
> unflushed write buffers. Since you have all parts already there - a thread to 
> drain the childs output - why not just spawn two of those instead of one and 
> make sure both are closed as expected when the child is gone. That way you 
> also cut down on execution time.

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?

-

PR: https://git.openjdk.java.net/jdk/pull/3049

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

[Jim Laskey]

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 implementation notes), but it's not really called out on 
>> `RandomGenerator`. 
>> 
>> Trying out the patch, I can implement `RandomGenerator` and register it as a 
>> service:
>> 
>> public class AlwaysZero implements RandomGenerator {
>> @Override
>> public long nextLong() {
>> return 0;
>> }
>> }
>> ...
>> RandomGenerator alwaysZero = RandomGenerator.of("AlwaysZero");
>>  
>> 
>> Is that intended? (esp. since the annotation `RandomGeneratorProperties` is 
>> not public). If i rename the above to `L32X64MixRandom` an 
>> `ExceptionInInitializerError` is produced due to duplicate keys.
>> 
>> I suspect you want to filter out the service providers to those that only 
>> declare `RandomGeneratorProperties`, thereby restricting to providers only 
>> supplied by the platform.
>
> Has anyone here benchmarked this? I've run BumbleBench benchmarks (one of the 
> AdoptOpenJDK team's tools, [available 
> here](https://github.com/adoptium/bumblebench)) and I'm skeptical of the 
> original claims in [JEP 356](https://openjdk.java.net/jeps/356), namely:
> 
>> ...a new class of splittable PRNG algorithms (LXM) has also been discovered 
>> that are almost as fast [as SplittableRandom]...
> 
> On my machine, L64X128MixRandom's algorithm is 53% slower than 
> SplittableRandom, a halving in performance that I think would be inaccurate 
> to describe as "almost as fast." I've benchmarked on Java 8 HotSpot (Windows 
> 10, x64) and Java 15 OpenJ9 (same machine). On HotSpot, which I think is the 
> main concern, I go from 1021770880 (over 1 billion) random longs per second 
> with SplittableRandom to 479769280 (over 479 million) with my (I believe 
> faithful) implementation of L64X128MixRandom. That is where I observed the 
> 53% reduction. While SplittableRandom specifically seems to perform 
> relatively badly on OpenJ9, with 893283072 longs per second (893 million), 
> other similar random number generators do extremely well on OpenJ9; 
> [LaserRandom](https://github.com/tommyettinger/jdkgdxds/blob/master/src/main/java/com/github/tommyettinger/ds/support/LaserRandom.java)
>  generates 4232752128 random longs per second (4.2 billion) where 
> L64X128MixRandom gets 840015872 (840 million). My benchmark repo is
  a mess, but if anyone wants to see and verify, [here it 
is](https://github.com/tommyettinger/assorted-benchmarks/tree/master/src/main/java/net/adoptopenjdk/bumblebench/examples).
 JMH benchmarks might provide different or just additional useful information; 
I've only run BumbleBench.
> 
> One could make the argument that getting a random long from a PRNG takes so 
> little time in the first place that it is unlikely to be a bottleneck, and by 
> that logic, LXM is "almost as fast." However, if random generation is not 
> being called often enough for its speed to matter, you are exceedingly 
> unlikely to need so many (over 9 quintillion) parallel streams or such a long 
> period per stream ((2 to the 192) minus (2 to the 64)). LXM is also 
> 1-dimensionally equidistributed, while the foundation it is built on should 
> allow 4-dimensional equidistribution (with the caveat of any LFSR that an 
> all-zero state is impossible), with the same memory use per generator (4 
> longs), a longer period, and comparable quality using `xoshiro256**`, or 
> possibly `xoshiro256++`, giving up streams but permitting twice as many leaps 
> as LXM has streams if you maintain the same period as L64X128MixRandom.
> 
> If I were implementing a PRNG to operate in a future official version of the 
> JVM, I would definitely look into ways to use AES-NI, and I think the 
> interfaces provided here should be valuable for any similar addition, even if 
> I disagree with the provided implementations of those interfaces. Thank you 
> for your time.

> 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 implementation notes), but it's not really called out on 
> `RandomGenerator`.
> 
> Trying out the patch, I can implement `RandomGenerator` and register it as a 
> service:
> 
> ```java
> public class AlwaysZero implements RandomGenerator {
> @Override
> public long nextLong() {
> return 0;
> }
> }
> ...
> RandomGenerator alwaysZero = RandomGenerator.of("AlwaysZero");
> ```
> 
> Is that intended? (esp. since the annotation `RandomGeneratorProperties` is 
> not public). If i rename the above to `L32X64MixRandom` an 
> `ExceptionInInitializerError` is produced due to duplicate keys.
> 
> I suspect you want to filter out the service providers to

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v31]

[Jim Laskey]

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 maintained by method {@link #next}.
>> 134:  *
>> 135:  * @implSpec The invocation {@code new Random(seed)} is 
>> equivalent to:
> 
> This is not conventional formatting for an implSpec section. I suggest 
> putting implSpec on its own line and then left-justifying the text as normal. 
> A new paragraph tag is no needed at the beginning of implSpec.

Adjusted

-

PR: https://git.openjdk.java.net/jdk/pull/1292

Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v31]

[Jim Laskey]

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: @Retention(RetentionPolicy.RUNTIME)
>> 61: @Target(ElementType.TYPE)
>> 62: public @interface RandomGeneratorProperties {
> 
> Should the is-deprecated information be stored here?

I don't think so. That would require the deprecation state be stored in two 
places. I think it's sufficient to rely on the presence of @Deprecated.

-

PR: https://git.openjdk.java.net/jdk/pull/1292

Integrated: 8260605: Various java.lang.invoke cleanups

[Claes Redestad]

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: 63eae8fa
Author:Claes Redestad 
URL:   https://git.openjdk.java.net/jdk/commit/63eae8fa
Stats: 286 lines in 4 files changed: 40 ins; 168 del; 78 mod

8260605: Various java.lang.invoke cleanups

Reviewed-by: mchung

-

PR: https://git.openjdk.java.net/jdk/pull/2300

Re: RFR: 8251942: PrintStream specification is not clear which flush method is automatically invoked [v2]

[Alan Bateman]

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 not made explicit in the specification.
>
> 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).

-

PR: https://git.openjdk.java.net/jdk/pull/2926

Re: RFR: 8251942: PrintStream specification is not clear which flush method is automatically invoked [v2]

[Daniel Fuchs]

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 not made explicit in the specification.
>
> Brian Burkhalter has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   8251942: Scale back class level spec change

Looks good to me Brian!

-

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2926

Re: RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields

[Lin Zang]

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 spec 
(https://tools.ietf.org/html/rfc1952).
BTW, does a CSR required for this PR?  

Thanks!
Lin

-

PR: https://git.openjdk.java.net/jdk/pull/3072

RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields

[Lin Zang]

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: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-4890732
  Stats: 184 lines in 1 file changed: 184 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3072.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3072/head:pull/3072

PR: https://git.openjdk.java.net/jdk/pull/3072