From ihse at openjdk.java.net  Mon Feb  1 11:14:59 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 1 Feb 2021 11:14:59 GMT
Subject: [jdk16] RFR: 8258378: Final nroff manpage update for JDK 16
Message-ID: <2nAapGYDGTih_WWtZngNa0s8ZBc3ZKOSgz1MEZMHGYg=.a80e96ee-dd5a-42bd-80d7-1f83e72b9686@github.com>

Before RC phase we need to ensure we have the final set of manpage updates published in OpenJDK.

-------------

Commit messages:
 - 8258378: Final nroff manpage update for JDK 16

Changes: https://git.openjdk.java.net/jdk16/pull/142/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=142&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258378
  Stats: 238 lines in 27 files changed: 98 ins; 111 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/142.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/142/head:pull/142

PR: https://git.openjdk.java.net/jdk16/pull/142

From jlahoda at openjdk.java.net  Mon Feb  1 13:43:04 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 1 Feb 2021 13:43:04 GMT
Subject: RFR: JDK-8260593: javac can skip a temporary local variable when
 pattern matching over a local variable [v2]
In-Reply-To: <K3mcIdlZxb_NWWtbtka1dWx0GouNlv4rnFhxHZPveY4=.dbf12096-6ed5-401c-a893-7d4b37c0f179@github.com>
References: <K3mcIdlZxb_NWWtbtka1dWx0GouNlv4rnFhxHZPveY4=.dbf12096-6ed5-401c-a893-7d4b37c0f179@github.com>
Message-ID: <8e9Wcf8Xv6dRzA2qcXBHm_XtfXV5j8y5JZF0U9nnAAw=.d3fa9eef-4a6a-40ba-b802-581b21e38a18@github.com>

> When translating type test like `<expr> instanceof String s`, javac needs to a) check if the value of `<expr>` is a String, and if yes, b) create a new variable `s`, and assign the value of `<expr>` into it. But, `<expr>` needs to be evaluated only once. So, javac will create a temporary local variable to hold the value of `<expr>`. But, if `<expr>` itself is a local variable, there is no need to create another temporary local variable, javac can read the original local variable twice, leading to a shorter bytecode.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Fixing tests.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2313/files
  - new: https://git.openjdk.java.net/jdk/pull/2313/files/ebf3c79b..24e898c7

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

  Stats: 5 lines in 2 files changed: 0 ins; 2 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2313.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2313/head:pull/2313

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

From jlahoda at openjdk.java.net  Mon Feb  1 15:15:05 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 1 Feb 2021 15:15:05 GMT
Subject: RFR: JDK-8222850: jshell tool: Misleading cascade compiler error in
 switch expression with undefined vars
Message-ID: <8ipwF_RplZANcUQB_Poj62xam4Pz6IiKXzx8I8ovT54=.802cc822-633e-44cf-bf5a-8322d870832b@github.com>

Consider code like:
        switch (undefined) {
            case A -> {}
            case B, C -> {}
            case D -> {}
        }

javac will produce these errors for it:
$ javac Switch.java 
Switch.java:3: error: cannot find symbol
        switch (undefined) {
                ^
  symbol:   variable undefined
  location: class Switch
Switch.java:3: error: illegal parenthesized expression
        switch (undefined) {
               ^
Switch.java:4: error: cannot find symbol
            case A -> {}
                 ^
  symbol:   variable A
  location: class Switch
Switch.java:5: error: cannot find symbol
            case B, C -> {}
                 ^
  symbol:   variable B
  location: class Switch
Switch.java:5: error: cannot find symbol
            case B, C -> {}
                    ^
  symbol:   variable C
  location: class Switch
Switch.java:6: error: cannot find symbol
            case D -> {}
                 ^
  symbol:   variable D
  location: class Switch
6 errors

For jshell and switch expressions, there may be one more error reported at the end:
jshell> var v = switch (undefined) {case A -> 0;};
|  Error:
|  cannot find symbol
|    symbol:   variable undefined
|  var v = switch (undefined) {case A -> 0;};
|                  ^-------^
|  Error:
|  illegal parenthesized expression
|  var v = switch (undefined) {case A -> 0;};
|                 ^---------^
|  Error:
|  cannot find symbol
|    symbol:   variable A
|  var v = switch (undefined) {case A -> 0;};
|                                   ^
|  Error:
|  the switch expression does not cover all possible input values
|  var v = switch (undefined) {case A -> 0;};
|          ^-------------------------------^

We could prevent all the follow-up error reports, and keep only the first one, which is the real error in the code.

-------------

Commit messages:
 - JDK-8222850: jshell tool: Misleading cascade compiler error in switch expression with undefined vars

Changes: https://git.openjdk.java.net/jdk/pull/2336/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2336&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8222850
  Stats: 63 lines in 6 files changed: 59 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2336.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2336/head:pull/2336

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

From vromero at openjdk.java.net  Mon Feb  1 17:13:48 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 1 Feb 2021 17:13:48 GMT
Subject: RFR: JDK-8222850: jshell tool: Misleading cascade compiler error
 in switch expression with undefined vars
In-Reply-To: <8ipwF_RplZANcUQB_Poj62xam4Pz6IiKXzx8I8ovT54=.802cc822-633e-44cf-bf5a-8322d870832b@github.com>
References: <8ipwF_RplZANcUQB_Poj62xam4Pz6IiKXzx8I8ovT54=.802cc822-633e-44cf-bf5a-8322d870832b@github.com>
Message-ID: <SuEKspOkG5K2KLenYEly-41P6MtCNPHVrnXW9me822Q=.7177e8c8-8e9c-4726-8432-506ce488bc94@github.com>

On Mon, 1 Feb 2021 15:09:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
>         switch (undefined) {
>             case A -> {}
>             case B, C -> {}
>             case D -> {}
>         }
> 
> javac will produce these errors for it:
> $ javac Switch.java 
> Switch.java:3: error: cannot find symbol
>         switch (undefined) {
>                 ^
>   symbol:   variable undefined
>   location: class Switch
> Switch.java:3: error: illegal parenthesized expression
>         switch (undefined) {
>                ^
> Switch.java:4: error: cannot find symbol
>             case A -> {}
>                  ^
>   symbol:   variable A
>   location: class Switch
> Switch.java:5: error: cannot find symbol
>             case B, C -> {}
>                  ^
>   symbol:   variable B
>   location: class Switch
> Switch.java:5: error: cannot find symbol
>             case B, C -> {}
>                     ^
>   symbol:   variable C
>   location: class Switch
> Switch.java:6: error: cannot find symbol
>             case D -> {}
>                  ^
>   symbol:   variable D
>   location: class Switch
> 6 errors
> 
> For jshell and switch expressions, there may be one more error reported at the end:
> jshell> var v = switch (undefined) {case A -> 0;};
> |  Error:
> |  cannot find symbol
> |    symbol:   variable undefined
> |  var v = switch (undefined) {case A -> 0;};
> |                  ^-------^
> |  Error:
> |  illegal parenthesized expression
> |  var v = switch (undefined) {case A -> 0;};
> |                 ^---------^
> |  Error:
> |  cannot find symbol
> |    symbol:   variable A
> |  var v = switch (undefined) {case A -> 0;};
> |                                   ^
> |  Error:
> |  the switch expression does not cover all possible input values
> |  var v = switch (undefined) {case A -> 0;};
> |          ^-------------------------------^
> 
> We could prevent all the follow-up error reports, and keep only the first one, which is the real error in the code.

looks good

-------------

Marked as reviewed by vromero (Reviewer).

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

From github.com+7806504+liach at openjdk.java.net  Mon Feb  1 19:18:44 2021
From: github.com+7806504+liach at openjdk.java.net (liach)
Date: Mon, 1 Feb 2021 19:18:44 GMT
Subject: RFR: 8241356: Use a more reliable way to encode Symbol flags
In-Reply-To: <aYRbIKEZmDlWfryC0sW1BSVtzJyIR7BRZS2Vs0XfGaY=.de31b4a7-d2df-489a-9816-08deab0cddef@github.com>
References: <aYRbIKEZmDlWfryC0sW1BSVtzJyIR7BRZS2Vs0XfGaY=.de31b4a7-d2df-489a-9816-08deab0cddef@github.com>
Message-ID: <FSyY4LXJeGt-T6BQ2nSjnpJt5PUP-QS55TrbO8FGdAw=.46ed160b-cd1f-4e6b-a982-06c46bbd8ecc@github.com>

On Fri, 29 Jan 2021 17:31:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> [This is a GitHub copy of: https://mail.openjdk.java.net/pipermail/compiler-dev/2020-March/014389.html ]
> 
> Currently, (com.sun.tools.javac.code.)Symbol/s have a long field "flags_field", which holds various one-bit information ("Flags") about the given Symbol.
> 
> We currently have around 64 such Flags, which means we are out of bits in the long field, and adding new flags is not easy.
> 
> We could change the "flags_field" to be a Set over enums, but this would increase the memory footprint notably, and would also slow-down access to flags. Currently, flags operations in javac are very fast and very common, so this is probably too much burden. There are also flags to which we need to access as bit masks, e.g. due to writing to classfile.
> 
> My proposal here is to use an intermediate solution, until we find a better solution, or until a better solution is possible (like due to Valhalla). The idea is as follows:
> -the current long-based Flags are split into 4 groups:
> --"flat" Flags, long based, work exactly as before.
> --enum-based TypeSymbolFlags, MethodSymbolFlags and VarSymbolFlags, which are only applicable to TypeSymbols, MethodSymbols and VarSymbols, respectively, and are checked using methods like Symbol.isFlagSet and set/clear using methods Symbol.setFlag and Symbol.clearFlag. So these flags are mostly encapsulated, even though physically they are currently stored in the flags_field as well.
> 
> There are ~~37~~ 40 "flat" flags and ~~16~~ 17 TypeSymbolFlags (methods and vars have less flags), 57 in total. This gives us at least 7 new flags before we run out of long bits in flags_field again - but even if we do, there are several easy mitigation strategies we could use, like:
> -create a new int/long field on TypeSymbols for the TypeSymbolFlags (probably preferable)
> -split TypeSymbolFlags into Class/Package/MethodSymbolFlags
> 
> The positives of this solution include:
> -safe(r) access to the flags - the access to the extra/symbol-kind-specific flags is mostly encapsulated, and hence mostly safe
> -improves the abstractions at least for some flags
> -reasonably complex patch (attempts to encapsulate all the flags were troublesome in previous experiments)
> -the performances appears to be acceptable.
> 
> The negative that I see is that the code includes several incompatible types of flags now. These cannot be easily confused by accident (as the type system will complain), but still we need to be aware of them when writing code.
> 
> Some more alternatives:
> -add a new field to Symbol, like long extraFlags, and continue with bit masks as we did so far using this new field. The drawback is that it is more error prone (it would be difficult to ensure only the new/extra flags would be stored and read from extraFlags).
> -have a new field, and "flat" and non-"flat" enum-based encapsulated Flags, but don't separate Type/Method/Var flags. Probably something to consider, even though I am a bit reluctant to add new fields without trying to avoid it .
> 
> Any feedback is welcome!

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 544:

> 542: //        RECORD(Flags.RECORD),
> 543: //        RECOVERABLE(Flags.RECOVERABLE),
> 544: //>>>>>>> master

This commented out merge conflict stub should be removed.

-------------

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

From jfranck at openjdk.java.net  Mon Feb  1 20:20:41 2021
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Mon, 1 Feb 2021 20:20:41 GMT
Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation
 type
In-Reply-To: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
Message-ID: <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>

On Thu, 28 Jan 2021 22:33:53 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Please review this fix to add `ElementType.MODULE` to the default list of annotation targets, to allow annotations without an explicit `@Target` to be used on module declarations.

Hi Liam,

Code looks good, but I'd prefer if you file a more specific bug. Maybe also add a small test that doesn't compile before the fix?

-------------

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

From darcy at openjdk.java.net  Mon Feb  1 20:43:44 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 1 Feb 2021 20:43:44 GMT
Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation
 type
In-Reply-To: <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
Message-ID: <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>

On Mon, 1 Feb 2021 20:18:09 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:

>> Please review this fix to add `ElementType.MODULE` to the default list of annotation targets, to allow annotations without an explicit `@Target` to be used on module declarations.
>
> Hi Liam,
> 
> Code looks good, but I'd prefer if you file a more specific bug. Maybe also add a small test that doesn't compile before the fix?

Please file a CSR so that the behavioral compatibly change can be assessed.

-------------

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

From cushon at openjdk.java.net  Mon Feb  1 20:53:43 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Mon, 1 Feb 2021 20:53:43 GMT
Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation
 type
In-Reply-To: <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
 <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
Message-ID: <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>

On Mon, 1 Feb 2021 20:40:54 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Hi Liam,
>> 
>> Code looks good, but I'd prefer if you file a more specific bug. Maybe also add a small test that doesn't compile before the fix?
>
> Please file a CSR so that the behavioral compatibly change can be assessed.

Thanks for the comments,

@jbf I'll add a more focused test. For the bug, the original discussion in https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013705.html is specifically about annotations without an explicit `@Target` applying to `MODULE`, I don't think there's anything that needs to be done for [JDK-8231436](https://bugs.openjdk.java.net/browse/JDK-8231436) besides supporting `MODULE`, would you still prefer a separate bug?

@jddarcy note that there was already a spec change related to this in [JDK-8231435](https://bugs.openjdk.java.net/browse/JDK-8231435) and the spec bug mentions "this expansion is source, binary, and behaviorally compatible", should I still file a CSR?

-------------

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

From Divino.Cesar at microsoft.com  Tue Feb  2 01:31:16 2021
From: Divino.Cesar at microsoft.com (Cesar Soares Lucas)
Date: Tue, 2 Feb 2021 01:31:16 +0000
Subject: Way to print type inference engine progress?
Message-ID: <BY5PR21MB147321B1D7BB6DF45CA320899AB59@BY5PR21MB1473.namprd21.prod.outlook.com>

Hey there,

I'm debugging a portion of Java 11 code that seems to be hitting a problem like the bugs reported here [1][2]. I'm not very familiar with javac internals so I'm wondering if there is a way to make the type inference engine operate in verbose mode so I can get a list of type/constraints that it resolved during the evaluation of a Java statement.

I have a piece of code similar to the one below and I wanted to see all types the engine considered for each method:

Workflow<Map<FeatureSourceKey, Document<?>>> result = Workflow
? ? .value(strs)
? ? .flatMap(operator)
? ? .map(
? ? ? ? batchResult -> batchResult
? ? ? ? .values()
? ? ? ? .stream()
? ? ? ? .map(item -> getReMixBulkResponseItemValue(item))
? ? ? ? .collect(Collectors.toMap(d -> null, Function.identity())));

Is this possible?
 

Thanks,
Cesar

[1] https://bugs.openjdk.java.net/browse/JDK-8222171
[2] https://bugs.openjdk.java.net/browse/JDK-8222035

From duke at openjdk.java.net  Tue Feb  2 01:32:41 2021
From: duke at openjdk.java.net (duke)
Date: Tue, 2 Feb 2021 01:32:41 GMT
Subject: Withdrawn: 7194212: NPE in Flow.visitIdent
In-Reply-To: <ata8yNXB-KSWpLrfUUS2_W4__kQCxkBYK-j8itCCR0s=.0fd12b0b-f2c6-49a7-a107-da29779a097c@github.com>
References: <ata8yNXB-KSWpLrfUUS2_W4__kQCxkBYK-j8itCCR0s=.0fd12b0b-f2c6-49a7-a107-da29779a097c@github.com>
Message-ID: <3KBKdmSnsNCFWIe3eD1YTGl7miv09Pzx3D5bzv8ngNc=.cef5b129-5f25-4b2e-852f-080bd1eea61a@github.com>

On Thu, 19 Nov 2020 18:24:00 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> A somewhat corner-case issue, but consider a case where classfiles for:
> 
> public class Outer {
>     public class Inner { }
> }
> 
> Are on a classpath while compiling:
> 
> public class Outer$Inner extends Outer { }
> 
> This leads to a crash in javac (in Flow), because when Outer is completed, its InnerClasses attribute is read, and, based on it, the flags_field of Outer$Inner is (re)set (and it is put as an nested class to Outer, although that is not correct). But the flags_field used to contain UNATTRIBUTED flag. As this flag is cleared, the method bodies for Outer$Inner are never attributed (its default constructor in this case), which ultimately leads to the crash in Flow.
> 
> The proposed patch is to ensure the InnerClasses entry is ignored if we are compiling a same-named class from source. The cost is yet another Flag bit.

This pull request has been closed without being integrated.

-------------

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

From jfranck at openjdk.java.net  Tue Feb  2 09:31:43 2021
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Tue, 2 Feb 2021 09:31:43 GMT
Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation
 type
In-Reply-To: <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
 <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
 <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>
Message-ID: <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com>

On Mon, 1 Feb 2021 20:50:41 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Please file a CSR so that the behavioral compatibly change can be assessed.
>
> Thanks for the comments,
> 
> @jbf I'll add a more focused test. For the bug, the original discussion in https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013705.html is specifically about annotations without an explicit `@Target` applying to `MODULE`, I don't think there's anything that needs to be done for [JDK-8231436](https://bugs.openjdk.java.net/browse/JDK-8231436) besides supporting `MODULE`, would you still prefer a separate bug?
> 
> @jddarcy note that there was already a spec change related to this in [JDK-8231435](https://bugs.openjdk.java.net/browse/JDK-8231435) and the spec bug mentions "this expansion is source, binary, and behaviorally compatible", should I still file a CSR?

>From this follow up here: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013715.html my interpretation is that this bug was intended to widen it to all contexts, including type use. This has been changed in JLS but not in the normative javadoc and also not in the compiler. I believe we should keep declarations only, and back out the change to JLS.

-------------

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

From maurizio.cimadamore at oracle.com  Tue Feb  2 11:10:14 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 2 Feb 2021 11:10:14 +0000
Subject: Way to print type inference engine progress?
In-Reply-To: <BY5PR21MB147321B1D7BB6DF45CA320899AB59@BY5PR21MB1473.namprd21.prod.outlook.com>
References: <BY5PR21MB147321B1D7BB6DF45CA320899AB59@BY5PR21MB1473.namprd21.prod.outlook.com>
Message-ID: <6bb458e6-4e97-f1a7-3f42-97eb9caf52df@oracle.com>

Hi Cesar,
There should be an option:

"-Ddebug.dumpInferenceGraphsTo=<folder-name>"

which should generate a lot of .dot files showing constraints and 
dependencies between inference variables. The option generates a ton of 
output though, so it might take a while to figure out what graph you are 
staring at.

Cheers
Maurizio

On 02/02/2021 01:31, Cesar Soares Lucas wrote:
> Hey there,
>
> I'm debugging a portion of Java 11 code that seems to be hitting a problem like the bugs reported here [1][2]. I'm not very familiar with javac internals so I'm wondering if there is a way to make the type inference engine operate in verbose mode so I can get a list of type/constraints that it resolved during the evaluation of a Java statement.
>
> I have a piece of code similar to the one below and I wanted to see all types the engine considered for each method:
>
> Workflow<Map<FeatureSourceKey, Document<?>>> result = Workflow
>  ? ? .value(strs)
>  ? ? .flatMap(operator)
>  ? ? .map(
>  ? ? ? ? batchResult -> batchResult
>  ? ? ? ? .values()
>  ? ? ? ? .stream()
>  ? ? ? ? .map(item -> getReMixBulkResponseItemValue(item))
>  ? ? ? ? .collect(Collectors.toMap(d -> null, Function.identity())));
>
> Is this possible?
>   
>
> Thanks,
> Cesar
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8222171
> [2] https://bugs.openjdk.java.net/browse/JDK-8222035



From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Feb  2 11:44:53 2021
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 2 Feb 2021 11:44:53 GMT
Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation
 type
In-Reply-To: <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
 <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
 <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>
 <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com>
Message-ID: <PEhAZNV434d5RP5m0cH5X5MvUv8tmg-TuPfM1eFqtOQ=.e1483dc5-9c8d-4282-82dc-0d264c7c646d@github.com>

On Tue, 2 Feb 2021 09:28:59 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:

>> Thanks for the comments,
>> 
>> @jbf I'll add a more focused test. For the bug, the original discussion in https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013705.html is specifically about annotations without an explicit `@Target` applying to `MODULE`, I don't think there's anything that needs to be done for [JDK-8231436](https://bugs.openjdk.java.net/browse/JDK-8231436) besides supporting `MODULE`, would you still prefer a separate bug?
>> 
>> @jddarcy note that there was already a spec change related to this in [JDK-8231435](https://bugs.openjdk.java.net/browse/JDK-8231435) and the spec bug mentions "this expansion is source, binary, and behaviorally compatible", should I still file a CSR?
>
> From this follow up here: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013715.html my interpretation is that this bug was intended to widen it to all contexts, including type use. This has been changed in JLS but not in the normative javadoc and also not in the compiler. I believe we should keep declarations only, and back out the change to JLS.

Maybe we should collect the concrete information about this problem. Here are some materials that I know.

Order by time:
- 2019.08 **Werner Dietl** launched the discussion. [1]
- 2019.09 After the discussion between **Alex Buckley** and **Michael Ernst**, an initiative result came out.[2]
- 2019.09 Two JBS issues were filed. [3][4]
- 2019.12 **Alex Buckley** fixed the JLS(fix version: 14). But the compiler code and javadoc were not fixed. [5][6]
- 2020.10 **Christian Stein** created another issue about it. [7]
- 2020.10 **Guoxiong Li**(me) submitted a PR about it in Github. [8]
- 2020.10 **Joel Borggr?n-Franck** restarted the discussion about the specification. [9]
- 2020.12 Because the JDK16 was nearly at RDP1, we decided to only fix JDK-8254023. And other work left to JDk17.  [7][10][11]
- 2020.12 The issue JDK-8254023 was fixed at JDK16. [7][8][12]
- **Now, we need to discuss the problem(unify the specification, implement and javadoc) that JDK16 has left.**[11]

[1] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-August/013666.html
[2] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013705.html
[3] https://bugs.openjdk.java.net/browse/JDK-8231435
[4] https://bugs.openjdk.java.net/browse/JDK-8231436
[5] https://docs.oracle.com/javase/specs/jls/se14/html/jls-9.html#jls-9.6.4.1
[6] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/annotation/Target.html
[7] https://bugs.openjdk.java.net/browse/JDK-8254023
[8] https://github.com/openjdk/jdk/pull/622
[9] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015197.html
[10] http://openjdk.java.net/projects/jdk/16/
[11] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015503.html
[12] https://github.com/openjdk/jdk16/pull/34

-------------

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

From jlahoda at openjdk.java.net  Tue Feb  2 16:28:01 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 2 Feb 2021 16:28:01 GMT
Subject: RFR: 8241356: Use a more reliable way to encode Symbol flags [v2]
In-Reply-To: <aYRbIKEZmDlWfryC0sW1BSVtzJyIR7BRZS2Vs0XfGaY=.de31b4a7-d2df-489a-9816-08deab0cddef@github.com>
References: <aYRbIKEZmDlWfryC0sW1BSVtzJyIR7BRZS2Vs0XfGaY=.de31b4a7-d2df-489a-9816-08deab0cddef@github.com>
Message-ID: <BeN0ieY-9mauOUxv6aUlC3VU7lvOy7TA4_n4soZwZ9Y=.806f69e0-635c-4f72-8f75-89c73668572d@github.com>

> [This is a GitHub copy of: https://mail.openjdk.java.net/pipermail/compiler-dev/2020-March/014389.html ]
> 
> Currently, (com.sun.tools.javac.code.)Symbol/s have a long field "flags_field", which holds various one-bit information ("Flags") about the given Symbol.
> 
> We currently have around 64 such Flags, which means we are out of bits in the long field, and adding new flags is not easy.
> 
> We could change the "flags_field" to be a Set over enums, but this would increase the memory footprint notably, and would also slow-down access to flags. Currently, flags operations in javac are very fast and very common, so this is probably too much burden. There are also flags to which we need to access as bit masks, e.g. due to writing to classfile.
> 
> My proposal here is to use an intermediate solution, until we find a better solution, or until a better solution is possible (like due to Valhalla). The idea is as follows:
> -the current long-based Flags are split into 4 groups:
> --"flat" Flags, long based, work exactly as before.
> --enum-based TypeSymbolFlags, MethodSymbolFlags and VarSymbolFlags, which are only applicable to TypeSymbols, MethodSymbols and VarSymbols, respectively, and are checked using methods like Symbol.isFlagSet and set/clear using methods Symbol.setFlag and Symbol.clearFlag. So these flags are mostly encapsulated, even though physically they are currently stored in the flags_field as well.
> 
> There are ~~37~~ 40 "flat" flags and ~~16~~ 17 TypeSymbolFlags (methods and vars have less flags), 57 in total. This gives us at least 7 new flags before we run out of long bits in flags_field again - but even if we do, there are several easy mitigation strategies we could use, like:
> -create a new int/long field on TypeSymbols for the TypeSymbolFlags (probably preferable)
> -split TypeSymbolFlags into Class/Package/MethodSymbolFlags
> 
> The positives of this solution include:
> -safe(r) access to the flags - the access to the extra/symbol-kind-specific flags is mostly encapsulated, and hence mostly safe
> -improves the abstractions at least for some flags
> -reasonably complex patch (attempts to encapsulate all the flags were troublesome in previous experiments)
> -the performances appears to be acceptable.
> 
> The negative that I see is that the code includes several incompatible types of flags now. These cannot be easily confused by accident (as the type system will complain), but still we need to be aware of them when writing code.
> 
> Some more alternatives:
> -add a new field to Symbol, like long extraFlags, and continue with bit masks as we did so far using this new field. The drawback is that it is more error prone (it would be difficult to ensure only the new/extra flags would be stored and read from extraFlags).
> -have a new field, and "flat" and non-"flat" enum-based encapsulated Flags, but don't separate Type/Method/Var flags. Probably something to consider, even though I am a bit reluctant to add new fields without trying to avoid it .
> 
> Any feedback is welcome!

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Removing merge tags are noted on the review - thanks!

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2316/files
  - new: https://git.openjdk.java.net/jdk/pull/2316/files/a9c3ff6e..27e37860

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

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

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

From alex.buckley at oracle.com  Tue Feb  2 18:50:48 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Tue, 2 Feb 2021 10:50:48 -0800
Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation
 type
In-Reply-To: <PEhAZNV434d5RP5m0cH5X5MvUv8tmg-TuPfM1eFqtOQ=.e1483dc5-9c8d-4282-82dc-0d264c7c646d@github.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
 <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
 <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>
 <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com>
 <PEhAZNV434d5RP5m0cH5X5MvUv8tmg-TuPfM1eFqtOQ=.e1483dc5-9c8d-4282-82dc-0d264c7c646d@github.com>
Message-ID: <54e81069-d66b-d466-77eb-a425ff4ee336@oracle.com>

I initially proposed "all declaration contexts" as the smallest possible 
streamlining of the SE 7-oriented rule defined in SE 8. It would have 
ensured that legacy annotation types without @Target were locked out of 
the new world of type uses enabled in SE 8 by JSR 308. As it turned out, 
my conservative approach was unnecessary because Mike was fine with 
admitting those legacy annotation types for type uses via the "all 
contexts" rule. In the real world, "all declaration contexts" versus 
"all declaration contexts + all type contexts" is a distinction without 
a difference (that is, an insignificant distinction) -- we're best off 
adopting the latter rule, phrased simply as "all contexts".

Alex

On 2/2/2021 3:44 AM, Guoxiong Li wrote:
> On Tue, 2 Feb 2021 09:28:59 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:
> 
>>> Thanks for the comments,
>>>
>>> @jbf I'll add a more focused test. For the bug, the original discussion in https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013705.html is specifically about annotations without an explicit `@Target` applying to `MODULE`, I don't think there's anything that needs to be done for [JDK-8231436](https://bugs.openjdk.java.net/browse/JDK-8231436) besides supporting `MODULE`, would you still prefer a separate bug?
>>>
>>> @jddarcy note that there was already a spec change related to this in [JDK-8231435](https://bugs.openjdk.java.net/browse/JDK-8231435) and the spec bug mentions "this expansion is source, binary, and behaviorally compatible", should I still file a CSR?
>>
>>  From this follow up here: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013715.html my interpretation is that this bug was intended to widen it to all contexts, including type use. This has been changed in JLS but not in the normative javadoc and also not in the compiler. I believe we should keep declarations only, and back out the change to JLS.
> 
> Maybe we should collect the concrete information about this problem. Here are some materials that I know.
> 
> Order by time:
> - 2019.08 **Werner Dietl** launched the discussion. [1]
> - 2019.09 After the discussion between **Alex Buckley** and **Michael Ernst**, an initiative result came out.[2]
> - 2019.09 Two JBS issues were filed. [3][4]
> - 2019.12 **Alex Buckley** fixed the JLS(fix version: 14). But the compiler code and javadoc were not fixed. [5][6]
> - 2020.10 **Christian Stein** created another issue about it. [7]
> - 2020.10 **Guoxiong Li**(me) submitted a PR about it in Github. [8]
> - 2020.10 **Joel Borggr?n-Franck** restarted the discussion about the specification. [9]
> - 2020.12 Because the JDK16 was nearly at RDP1, we decided to only fix JDK-8254023. And other work left to JDk17.  [7][10][11]
> - 2020.12 The issue JDK-8254023 was fixed at JDK16. [7][8][12]
> - **Now, we need to discuss the problem(unify the specification, implement and javadoc) that JDK16 has left.**[11]
> 
> [1] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-August/013666.html
> [2] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013705.html
> [3] https://bugs.openjdk.java.net/browse/JDK-8231435
> [4] https://bugs.openjdk.java.net/browse/JDK-8231436
> [5] https://docs.oracle.com/javase/specs/jls/se14/html/jls-9.html#jls-9.6.4.1
> [6] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/annotation/Target.html
> [7] https://bugs.openjdk.java.net/browse/JDK-8254023
> [8] https://github.com/openjdk/jdk/pull/622
> [9] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015197.html
> [10] http://openjdk.java.net/projects/jdk/16/
> [11] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015503.html
> [12] https://github.com/openjdk/jdk16/pull/34
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2303
> 

From Divino.Cesar at microsoft.com  Tue Feb  2 23:22:42 2021
From: Divino.Cesar at microsoft.com (Cesar Soares Lucas)
Date: Tue, 2 Feb 2021 23:22:42 +0000
Subject: Way to print type inference engine progress?
In-Reply-To: <6bb458e6-4e97-f1a7-3f42-97eb9caf52df@oracle.com>
References: <BY5PR21MB147321B1D7BB6DF45CA320899AB59@BY5PR21MB1473.namprd21.prod.outlook.com>,
 <6bb458e6-4e97-f1a7-3f42-97eb9caf52df@oracle.com>
Message-ID: <BY5PR21MB14737BBFD75B902148F15E3F9AB59@BY5PR21MB1473.namprd21.prod.outlook.com>

Thank you, Maurizio. That was helpful!
________________________________
From: Maurizio Cimadamore <maurizio.cimadamore at oracle.com>
Sent: February 2, 2021 3:10 AM
To: Cesar Soares Lucas <Divino.Cesar at microsoft.com>; compiler-dev at openjdk.java.net <compiler-dev at openjdk.java.net>
Subject: Re: Way to print type inference engine progress?

Hi Cesar,
There should be an option:

"-Ddebug.dumpInferenceGraphsTo=<folder-name>"

which should generate a lot of .dot files showing constraints and
dependencies between inference variables. The option generates a ton of
output though, so it might take a while to figure out what graph you are
staring at.

Cheers
Maurizio

On 02/02/2021 01:31, Cesar Soares Lucas wrote:
> Hey there,
>
> I'm debugging a portion of Java 11 code that seems to be hitting a problem like the bugs reported here [1][2]. I'm not very familiar with javac internals so I'm wondering if there is a way to make the type inference engine operate in verbose mode so I can get a list of type/constraints that it resolved during the evaluation of a Java statement.
>
> I have a piece of code similar to the one below and I wanted to see all types the engine considered for each method:
>
> Workflow<Map<FeatureSourceKey, Document<?>>> result = Workflow
>      .value(strs)
>      .flatMap(operator)
>      .map(
>          batchResult -> batchResult
>          .values()
>          .stream()
>          .map(item -> getReMixBulkResponseItemValue(item))
>          .collect(Collectors.toMap(d -> null, Function.identity())));
>
> Is this possible?
>
>
> Thanks,
> Cesar
>
> [1] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8222171&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7C08cccf30a24348ec144508d8c76b69a3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637478611436273106%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Vetuhk1Rhps%2BPll6xN9BcqRcdm35BRQVHfcuEk5l0t8%3D&amp;reserved=0
> [2] https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8222035&amp;data=04%7C01%7CDivino.Cesar%40microsoft.com%7C08cccf30a24348ec144508d8c76b69a3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637478611436273106%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=oEGyG%2FY2fn2oFtn3cAnh%2FWPdpsHd47Zme1TGCGOGC9E%3D&amp;reserved=0


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210202/3dc0039a/attachment-0001.htm>

From vromero at openjdk.java.net  Wed Feb  3 00:57:44 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 3 Feb 2021 00:57:44 GMT
Subject: RFR: 8259235: javac crashes while attributing super method
 invocation
In-Reply-To: <GVxbhQG4b59QeL6dAqnFOu2xTiIYJ1ZTwuK9nKF7-mw=.3c6072eb-6d05-4332-b29b-b669fbc84286@github.com>
References: <GVxbhQG4b59QeL6dAqnFOu2xTiIYJ1ZTwuK9nKF7-mw=.3c6072eb-6d05-4332-b29b-b669fbc84286@github.com>
Message-ID: <4NYj2_5IDHRbTzwcVwg4P-m1LgJH8n1M7dhH057hUzY=.5d735391-5d3e-4f0e-9212-28b5fec43344@github.com>

On Tue, 5 Jan 2021 16:47:26 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Code like:
> public class SuperMethodCallBroken extends Undef implements I {
>     public void test() {
>         I.super.test();
>     }
> }
> interface I {
>     public default void test() {}
> }
> 
> crashes javac. The reason is that when `I.super` is being attributed, the interfaces of the enclosing class are pruned to remove subtypes - but `Undef` is erroneous and is a subtype of every type. So `I` is removed from the list of interfaces to check, and javac crashes then.
> 
> The proposed fix is to ignore erroneous supertypes when looking for subtypes.

looks good

-------------

Marked as reviewed by vromero (Reviewer).

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

From jjg at openjdk.java.net  Wed Feb  3 01:14:42 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 3 Feb 2021 01:14:42 GMT
Subject: RFR: 8260959: remove RECORDS from PreviewFeature.Feature enum
In-Reply-To: <AwCW8S7x-ls9hLA6AmLnkYLL6hcpSsGT_hEd5swj6n8=.4e4413d6-781a-4169-bf6b-bf592b76708b@github.com>
References: <AwCW8S7x-ls9hLA6AmLnkYLL6hcpSsGT_hEd5swj6n8=.4e4413d6-781a-4169-bf6b-bf592b76708b@github.com>
Message-ID: <dhjquVIiIWSroAnH-fe1G4P3Jo_xbc-q-aAjk6K5B3E=.6004c3f4-477d-430a-ab9e-d31b445af2dd@github.com>

On Tue, 2 Feb 2021 18:33:18 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this simple fix that is removing the RECORDS enum constant from the PreviewFeature.Feature enum, now that RECORDS are final in 16 this constant can be safely removed.
> 
> Thanks,
> Vicente

Given the scary comment and reference to JDK 15 and boot cycle builds, is it really safe to remove the constant?

-------------

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

From darcy at openjdk.java.net  Wed Feb  3 01:40:39 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 3 Feb 2021 01:40:39 GMT
Subject: RFR: 8260959: remove RECORDS from PreviewFeature.Feature enum
In-Reply-To: <dhjquVIiIWSroAnH-fe1G4P3Jo_xbc-q-aAjk6K5B3E=.6004c3f4-477d-430a-ab9e-d31b445af2dd@github.com>
References: <AwCW8S7x-ls9hLA6AmLnkYLL6hcpSsGT_hEd5swj6n8=.4e4413d6-781a-4169-bf6b-bf592b76708b@github.com>
 <dhjquVIiIWSroAnH-fe1G4P3Jo_xbc-q-aAjk6K5B3E=.6004c3f4-477d-430a-ab9e-d31b445af2dd@github.com>
Message-ID: <sSZBW2qvql4zH4rQRECkRPHc_G9Fj2y737qf5x9IMns=.272968f6-b601-4226-ad4b-e955cd1e9fdd@github.com>

On Wed, 3 Feb 2021 01:12:19 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review this simple fix that is removing the RECORDS enum constant from the PreviewFeature.Feature enum, now that RECORDS are final in 16 this constant can be safely removed.
>> 
>> Thanks,
>> Vicente
>
> Given the scary comment and reference to JDK 15 and boot cycle builds, is it really safe to remove the constant?

So currently, JDK 17 can be built with a boot JDK of 15, 16, or 17 (since JDK-8257459: "Bump minimum boot jdk to JDK 16") hasn't been fixed yet.

JDK 17 can currently be used as boot JDK only for itself, right? And in the future be used for JDK 18, and 19.

-------------

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

From jjg at openjdk.java.net  Wed Feb  3 04:41:04 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 3 Feb 2021 04:41:04 GMT
Subject: RFR: JDK-8257925 enable more support for nested inline tags
Message-ID: <8ywNfJMqNdrdBT2BZb52mnwOVO1sHm2gbpYPGVCH6Ss=.a21bd47b-c78f-466e-b936-2518c3d0a54c@github.com>

Please review an update to improve the support, where appropriate, for nested inline tags. 

It has always been the case that certain inline tags allow text and HTML to appear within them. With tags like `{@return}` and `{@summary}` it becomes desirable to also generally allow nested inline tags to appear in those places as well. The work for this was started with the support for `{@return}` [JDK-8075778](https://bugs.openjdk.java.net/browse/JDK-8075778), but applying the work more generally was out of scope at the time. This change completes the work that was started then.

The work can be grouped into 4 parts, in 3 commits.

## Commit 1

* Update `DocCommentParser` to syntactically allow nested inline tags in situations that permit text and HTML
* Update the downstream code to semantically limit nestg where it does not make sense, and provide new tests to verify the behavior.

A family of new tests are added, each testing the ability to put an inline tag within another of the same kind, with and without doclint being enabled. In addition, test cases are added placing a simple instance `{@value}` in an enclosing tag: this is a useful case just because the expansion is plain text and therefore valid in all situations.  Additional tests and test cases can be added as needed.

This commit left the `{@index}` tag generating "bad" code when it was nested. The error was "reference to an undeclared ID". The (temporary) solution was to disable the automatic link checking for this specific subtest.

## Commit 2

* `HtmlDocletWriter` and `TagletWriterImpl ` pass around a pair of booleans `isFirstSentence` and `inSummary` to help determine the output to be generated. Conceptually, a third value is added to that group: a set containing the set of nested tag kinds, so that it is possible to determine the enclosing tags for a tag.  But, rather than add a third parameter to be passed around, the 3 are grouped into a new class `TagletWriterImpl.Context` which encapsulates the two booleans and the new set.  The new class is added in a way to minimize code churn.  No tests are affected by this change: all continue to pass.

## Commit 3

* The new `Context#inTags` field is used to help improve the behavior of nested `{@index}` tags even when used incorrectly, with warnings disabled.  As a result, the temporary change in the first commit to disable automatic link checking in one of the test cases is reverted.

<hr>

The introduction of the new Context class is arguably more general than we need at this time, but it clears up some erratic and inconsistent use of the `isFirstSentence` and `inSummary` booleans. The new class also provides a better framework for any complex new inline tags we may add in future. We might want to change the `Set<DocTree.Kind>` to some other collection at some point, if needs be (a stack, for example.) We might also want to move more information into the `Context`, such as the related `Element` that is otherwise ubiquitously passed around.

The overall cleanup also revealed some latent bugs in the code, that were hidden in some of the tests. Most notable was that there were still some cases were `<` and `>` were not being correctly escaped as `&lt;` and `&gt;` leading to output in some tests of the form `List<String>` !  This triggered a minor cleanup/rewrite of the beginning of `HtmlDocletWriter.seeTagsToContent` which was previously a bit too liberal with the use of `new RawHtml`!  The other minor cleanup was more consistent handling of whitespace at the end of the first sentence, as will be seen in a couple of places in one of the tests that was updated.

-------------

Commit messages:
 - fix trailing whitespace
 - neaten alignment in test description
 - use TagletWriterImpl.Context#inTags to modify behavior on a nested {@index} tag
 - initial introduction of TagletWriterImpl.Context
 - JDK-8257925: enable more support for nested inline tags

Changes: https://git.openjdk.java.net/jdk/pull/2369/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2369&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257925
  Stats: 708 lines in 14 files changed: 624 ins; 21 del; 63 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2369.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2369/head:pull/2369

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

From jlahoda at openjdk.java.net  Wed Feb  3 09:25:43 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 3 Feb 2021 09:25:43 GMT
Subject: Integrated: JDK-8222850: jshell tool: Misleading cascade compiler
 error in switch expression with undefined vars
In-Reply-To: <8ipwF_RplZANcUQB_Poj62xam4Pz6IiKXzx8I8ovT54=.802cc822-633e-44cf-bf5a-8322d870832b@github.com>
References: <8ipwF_RplZANcUQB_Poj62xam4Pz6IiKXzx8I8ovT54=.802cc822-633e-44cf-bf5a-8322d870832b@github.com>
Message-ID: <40k8H8mMkUiTutm3mjct2ukxqw9MaXsl0SCuq7T3IVY=.6d44a145-d284-4a9d-a74d-ba6c8258615b@github.com>

On Mon, 1 Feb 2021 15:09:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
>         switch (undefined) {
>             case A -> {}
>             case B, C -> {}
>             case D -> {}
>         }
> 
> javac will produce these errors for it:
> $ javac Switch.java 
> Switch.java:3: error: cannot find symbol
>         switch (undefined) {
>                 ^
>   symbol:   variable undefined
>   location: class Switch
> Switch.java:3: error: illegal parenthesized expression
>         switch (undefined) {
>                ^
> Switch.java:4: error: cannot find symbol
>             case A -> {}
>                  ^
>   symbol:   variable A
>   location: class Switch
> Switch.java:5: error: cannot find symbol
>             case B, C -> {}
>                  ^
>   symbol:   variable B
>   location: class Switch
> Switch.java:5: error: cannot find symbol
>             case B, C -> {}
>                     ^
>   symbol:   variable C
>   location: class Switch
> Switch.java:6: error: cannot find symbol
>             case D -> {}
>                  ^
>   symbol:   variable D
>   location: class Switch
> 6 errors
> 
> For jshell and switch expressions, there may be one more error reported at the end:
> jshell> var v = switch (undefined) {case A -> 0;};
> |  Error:
> |  cannot find symbol
> |    symbol:   variable undefined
> |  var v = switch (undefined) {case A -> 0;};
> |                  ^-------^
> |  Error:
> |  illegal parenthesized expression
> |  var v = switch (undefined) {case A -> 0;};
> |                 ^---------^
> |  Error:
> |  cannot find symbol
> |    symbol:   variable A
> |  var v = switch (undefined) {case A -> 0;};
> |                                   ^
> |  Error:
> |  the switch expression does not cover all possible input values
> |  var v = switch (undefined) {case A -> 0;};
> |          ^-------------------------------^
> 
> We could prevent all the follow-up error reports, and keep only the first one, which is the real error in the code.

This pull request has now been integrated.

Changeset: 90376156
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/90376156
Stats:     63 lines in 6 files changed: 59 ins; 0 del; 4 mod

8222850: jshell tool: Misleading cascade compiler error in switch expression with undefined vars

Reviewed-by: vromero

-------------

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

From mcimadamore at openjdk.java.net  Wed Feb  3 10:54:42 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 3 Feb 2021 10:54:42 GMT
Subject: RFR: 8241356: Use a more reliable way to encode Symbol flags [v2]
In-Reply-To: <BeN0ieY-9mauOUxv6aUlC3VU7lvOy7TA4_n4soZwZ9Y=.806f69e0-635c-4f72-8f75-89c73668572d@github.com>
References: <aYRbIKEZmDlWfryC0sW1BSVtzJyIR7BRZS2Vs0XfGaY=.de31b4a7-d2df-489a-9816-08deab0cddef@github.com>
 <BeN0ieY-9mauOUxv6aUlC3VU7lvOy7TA4_n4soZwZ9Y=.806f69e0-635c-4f72-8f75-89c73668572d@github.com>
Message-ID: <UrON-JG2MMegyFMEN0RnsQXQiBqeWn_xmyioBQCMOaQ=.11c34cc3-e675-437c-b7bc-757fd58563ca@github.com>

On Tue, 2 Feb 2021 16:28:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> [This is a GitHub copy of: https://mail.openjdk.java.net/pipermail/compiler-dev/2020-March/014389.html ]
>> 
>> Currently, (com.sun.tools.javac.code.)Symbol/s have a long field "flags_field", which holds various one-bit information ("Flags") about the given Symbol.
>> 
>> We currently have around 64 such Flags, which means we are out of bits in the long field, and adding new flags is not easy.
>> 
>> We could change the "flags_field" to be a Set over enums, but this would increase the memory footprint notably, and would also slow-down access to flags. Currently, flags operations in javac are very fast and very common, so this is probably too much burden. There are also flags to which we need to access as bit masks, e.g. due to writing to classfile.
>> 
>> My proposal here is to use an intermediate solution, until we find a better solution, or until a better solution is possible (like due to Valhalla). The idea is as follows:
>> -the current long-based Flags are split into 4 groups:
>> --"flat" Flags, long based, work exactly as before.
>> --enum-based TypeSymbolFlags, MethodSymbolFlags and VarSymbolFlags, which are only applicable to TypeSymbols, MethodSymbols and VarSymbols, respectively, and are checked using methods like Symbol.isFlagSet and set/clear using methods Symbol.setFlag and Symbol.clearFlag. So these flags are mostly encapsulated, even though physically they are currently stored in the flags_field as well.
>> 
>> There are ~~37~~ 40 "flat" flags and ~~16~~ 17 TypeSymbolFlags (methods and vars have less flags), 57 in total. This gives us at least 7 new flags before we run out of long bits in flags_field again - but even if we do, there are several easy mitigation strategies we could use, like:
>> -create a new int/long field on TypeSymbols for the TypeSymbolFlags (probably preferable)
>> -split TypeSymbolFlags into Class/Package/MethodSymbolFlags
>> 
>> The positives of this solution include:
>> -safe(r) access to the flags - the access to the extra/symbol-kind-specific flags is mostly encapsulated, and hence mostly safe
>> -improves the abstractions at least for some flags
>> -reasonably complex patch (attempts to encapsulate all the flags were troublesome in previous experiments)
>> -the performances appears to be acceptable.
>> 
>> The negative that I see is that the code includes several incompatible types of flags now. These cannot be easily confused by accident (as the type system will complain), but still we need to be aware of them when writing code.
>> 
>> Some more alternatives:
>> -add a new field to Symbol, like long extraFlags, and continue with bit masks as we did so far using this new field. The drawback is that it is more error prone (it would be difficult to ensure only the new/extra flags would be stored and read from extraFlags).
>> -have a new field, and "flat" and non-"flat" enum-based encapsulated Flags, but don't separate Type/Method/Var flags. Probably something to consider, even though I am a bit reluctant to add new fields without trying to avoid it .
>> 
>> Any feedback is welcome!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing merge tags are noted on the review - thanks!

Good experiment! I don't mind too much the fact that we have sets of incompatible flags - but while looking at the new Flags.java I noted several flags that looked *kind-specific* which seem to be defined in the *global* bucket. If (as I suspect) this is no accident, then I guess I'm a bit worried that the proposed patch would land us in a state where _some_ var flags are in the VarSymbolFlags enum, but not _all_ of them.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 167:

> 165:     /** Flag for synthesized default constructors of anonymous classes.
> 166:      */
> 167:     public static final int ANONCONSTR   = 1<<27;

Question: why this, and other flags that are specific to only one symbol kind have not been translated into the enum? Other examples are `ANONCONSTR_BASED`, `GENERATEDCONSTR`, `COMPACT_RECORD_CONSTRUCTOR`, `THROWS` and probably more.

-------------

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

From mcimadamore at openjdk.java.net  Wed Feb  3 11:02:43 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 3 Feb 2021 11:02:43 GMT
Subject: RFR: 8241356: Use a more reliable way to encode Symbol flags [v2]
In-Reply-To: <UrON-JG2MMegyFMEN0RnsQXQiBqeWn_xmyioBQCMOaQ=.11c34cc3-e675-437c-b7bc-757fd58563ca@github.com>
References: <aYRbIKEZmDlWfryC0sW1BSVtzJyIR7BRZS2Vs0XfGaY=.de31b4a7-d2df-489a-9816-08deab0cddef@github.com>
 <BeN0ieY-9mauOUxv6aUlC3VU7lvOy7TA4_n4soZwZ9Y=.806f69e0-635c-4f72-8f75-89c73668572d@github.com>
 <UrON-JG2MMegyFMEN0RnsQXQiBqeWn_xmyioBQCMOaQ=.11c34cc3-e675-437c-b7bc-757fd58563ca@github.com>
Message-ID: <2hjUP_18of5ES1130eAY94Chyy0fMqsQQwgXCpPWQuQ=.a0952a36-c55d-486c-b1dd-01dd657b9ef0@github.com>

On Wed, 3 Feb 2021 10:51:28 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing merge tags are noted on the review - thanks!
>
> Good experiment! I don't mind too much the fact that we have sets of incompatible flags - but while looking at the new Flags.java I noted several flags that looked *kind-specific* which seem to be defined in the *global* bucket. If (as I suspect) this is no accident, then I guess I'm a bit worried that the proposed patch would land us in a state where _some_ var flags are in the VarSymbolFlags enum, but not _all_ of them.

I'm also worried about where does this leave symbol construction - for instance, in TypeEnter I now see these lines (unchanged in this patch):

params.add(new VarSymbol(
                        GENERATED_MEMBER | PARAMETER | RECORD | (field == lastField && lastIsVarargs ? Flags.VARARGS : 0),
                        field.name, field.sym.type, csym));
 ```

Here, it seems, we are forced to just use a flat flags mask in the constructor - in other words, the new API is only for testing, and there is an asymmetry between construction and testing.

-------------

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

From prappo at openjdk.java.net  Wed Feb  3 12:30:40 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 3 Feb 2021 12:30:40 GMT
Subject: RFR: JDK-8257925 enable more support for nested inline tags
In-Reply-To: <8ywNfJMqNdrdBT2BZb52mnwOVO1sHm2gbpYPGVCH6Ss=.a21bd47b-c78f-466e-b936-2518c3d0a54c@github.com>
References: <8ywNfJMqNdrdBT2BZb52mnwOVO1sHm2gbpYPGVCH6Ss=.a21bd47b-c78f-466e-b936-2518c3d0a54c@github.com>
Message-ID: <5_La30de_lNBPbWoO87kN2bBkdbeUnHJPrf83dXsZvg=.5e41c94a-05a7-4e18-9488-bfbf982ba87f@github.com>

On Wed, 3 Feb 2021 04:28:21 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review an update to improve the support, where appropriate, for nested inline tags. 
> 
> It has always been the case that certain inline tags allow text and HTML to appear within them. With tags like `{@return}` and `{@summary}` it becomes desirable to also generally allow nested inline tags to appear in those places as well. The work for this was started with the support for `{@return}` [JDK-8075778](https://bugs.openjdk.java.net/browse/JDK-8075778), but applying the work more generally was out of scope at the time. This change completes the work that was started then.
> 
> The work can be grouped into 4 parts, in 3 commits.
> 
> ## Commit 1
> 
> * Update `DocCommentParser` to syntactically allow nested inline tags in situations that permit text and HTML
> * Update the downstream code to semantically limit nestg where it does not make sense, and provide new tests to verify the behavior.
> 
> A family of new tests are added, each testing the ability to put an inline tag within another of the same kind, with and without doclint being enabled. In addition, test cases are added placing a simple instance `{@value}` in an enclosing tag: this is a useful case just because the expansion is plain text and therefore valid in all situations.  Additional tests and test cases can be added as needed.
> 
> This commit left the `{@index}` tag generating "bad" code when it was nested. The error was "reference to an undeclared ID". The (temporary) solution was to disable the automatic link checking for this specific subtest.
> 
> ## Commit 2
> 
> * `HtmlDocletWriter` and `TagletWriterImpl ` pass around a pair of booleans `isFirstSentence` and `inSummary` to help determine the output to be generated. Conceptually, a third value is added to that group: a set containing the set of nested tag kinds, so that it is possible to determine the enclosing tags for a tag.  But, rather than add a third parameter to be passed around, the 3 are grouped into a new class `TagletWriterImpl.Context` which encapsulates the two booleans and the new set.  The new class is added in a way to minimize code churn.  No tests are affected by this change: all continue to pass.
> 
> ## Commit 3
> 
> * The new `Context#inTags` field is used to help improve the behavior of nested `{@index}` tags even when used incorrectly, with warnings disabled.  As a result, the temporary change in the first commit to disable automatic link checking in one of the test cases is reverted.
> 
> <hr>
> 
> The introduction of the new Context class is arguably more general than we need at this time, but it clears up some erratic and inconsistent use of the `isFirstSentence` and `inSummary` booleans. The new class also provides a better framework for any complex new inline tags we may add in future. We might want to change the `Set<DocTree.Kind>` to some other collection at some point, if needs be (a stack, for example.) We might also want to move more information into the `Context`, such as the related `Element` that is otherwise ubiquitously passed around.
> 
> The overall cleanup also revealed some latent bugs in the code, that were hidden in some of the tests. Most notable was that there were still some cases were `<` and `>` were not being correctly escaped as `&lt;` and `&gt;` leading to output in some tests of the form `List<String>` !  This triggered a minor cleanup/rewrite of the beginning of `HtmlDocletWriter.seeTagsToContent` which was previously a bit too liberal with the use of `new RawHtml`!  The other minor cleanup was more consistent handling of whitespace at the end of the first sentence, as will be seen in a couple of places in one of the tests that was updated.

Although this patch generally looks reasonable, I'm surprised to see some of the behavior it introduces. For example, consider composition of `@link` tags from the included tests:

    /** First sentence. {@link #m1() ABC {@link #m2() DEF} GHI} */

Before the patch that doc comment resulted in the following HTML:

    First sentence. <a href="#m1()"><code>ABC {@link #m2() DEF} GHI</code></a>

After the patch that same doc comment results in HTML that looks like this:

    First sentence. <a href="#m1()"><code>ABC <a href="#m2()"><code>DEF</code></a> GHI</code></a>

I wouldn't expect that latter behavior. Not only nested `<a>` are invalid HTML, but they are also rendered strangely in browsers. In this particular case the trailing `GHI` appears as normal text, not as a hyperlink.

-------------

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

From joel.p.borggren-franck at oracle.com  Wed Feb  3 13:29:38 2021
From: joel.p.borggren-franck at oracle.com (Joel Borggren-Franck)
Date: Wed, 3 Feb 2021 13:29:38 +0000
Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation
 type
In-Reply-To: <54e81069-d66b-d466-77eb-a425ff4ee336@oracle.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
 <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
 <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>
 <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com>
 <PEhAZNV434d5RP5m0cH5X5MvUv8tmg-TuPfM1eFqtOQ=.e1483dc5-9c8d-4282-82dc-0d264c7c646d@github.com>
 <54e81069-d66b-d466-77eb-a425ff4ee336@oracle.com>
Message-ID: <C0E0B8F2-0E5D-4DED-87AE-8D15B39CA372@oracle.com>

Hi Alex,

Looking at  the class file, and therefore reflection, there is a difference between ?all declaration contexts? and ?all contexts, declaration + type?. For the 5 ambiguous locations we would have to produce type annotation attributes if there is an annotation present whose declaration lack @Target. While this may or may not be desirable, and I?m leaning towards not, it is surely significant as it would change the semantics of reflective annotation processors in use.

cheers
/Joel

> On 2 Feb 2021, at 19:50, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> I initially proposed "all declaration contexts" as the smallest possible streamlining of the SE 7-oriented rule defined in SE 8. It would have ensured that legacy annotation types without @Target were locked out of the new world of type uses enabled in SE 8 by JSR 308. As it turned out, my conservative approach was unnecessary because Mike was fine with admitting those legacy annotation types for type uses via the "all contexts" rule. In the real world, "all declaration contexts" versus "all declaration contexts + all type contexts" is a distinction without a difference (that is, an insignificant distinction) -- we're best off adopting the latter rule, phrased simply as "all contexts".
> 
> Alex
> 
> On 2/2/2021 3:44 AM, Guoxiong Li wrote:
>> On Tue, 2 Feb 2021 09:28:59 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:
>>>> Thanks for the comments,
>>>> 
>>>> @jbf I'll add a more focused test. For the bug, the original discussion in https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013705.html is specifically about annotations without an explicit `@Target` applying to `MODULE`, I don't think there's anything that needs to be done for [JDK-8231436](https://bugs.openjdk.java.net/browse/JDK-8231436) besides supporting `MODULE`, would you still prefer a separate bug?
>>>> 
>>>> @jddarcy note that there was already a spec change related to this in [JDK-8231435](https://bugs.openjdk.java.net/browse/JDK-8231435) and the spec bug mentions "this expansion is source, binary, and behaviorally compatible", should I still file a CSR?
>>> 
>>> From this follow up here: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013715.html my interpretation is that this bug was intended to widen it to all contexts, including type use. This has been changed in JLS but not in the normative javadoc and also not in the compiler. I believe we should keep declarations only, and back out the change to JLS.
>> Maybe we should collect the concrete information about this problem. Here are some materials that I know.
>> Order by time:
>> - 2019.08 **Werner Dietl** launched the discussion. [1]
>> - 2019.09 After the discussion between **Alex Buckley** and **Michael Ernst**, an initiative result came out.[2]
>> - 2019.09 Two JBS issues were filed. [3][4]
>> - 2019.12 **Alex Buckley** fixed the JLS(fix version: 14). But the compiler code and javadoc were not fixed. [5][6]
>> - 2020.10 **Christian Stein** created another issue about it. [7]
>> - 2020.10 **Guoxiong Li**(me) submitted a PR about it in Github. [8]
>> - 2020.10 **Joel Borggr?n-Franck** restarted the discussion about the specification. [9]
>> - 2020.12 Because the JDK16 was nearly at RDP1, we decided to only fix JDK-8254023. And other work left to JDk17.  [7][10][11]
>> - 2020.12 The issue JDK-8254023 was fixed at JDK16. [7][8][12]
>> - **Now, we need to discuss the problem(unify the specification, implement and javadoc) that JDK16 has left.**[11]
>> [1] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-August/013666.html
>> [2] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013705.html
>> [3] https://bugs.openjdk.java.net/browse/JDK-8231435
>> [4] https://bugs.openjdk.java.net/browse/JDK-8231436
>> [5] https://docs.oracle.com/javase/specs/jls/se14/html/jls-9.html#jls-9.6.4.1
>> [6] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/annotation/Target.html
>> [7] https://bugs.openjdk.java.net/browse/JDK-8254023
>> [8] https://github.com/openjdk/jdk/pull/622
>> [9] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015197.html
>> [10] http://openjdk.java.net/projects/jdk/16/
>> [11] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015503.html
>> [12] https://github.com/openjdk/jdk16/pull/34
>> -------------
>> PR: https://git.openjdk.java.net/jdk/pull/2303


From jlahoda at openjdk.java.net  Wed Feb  3 13:31:44 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 3 Feb 2021 13:31:44 GMT
Subject: RFR: 8241356: Use a more reliable way to encode Symbol flags [v2]
In-Reply-To: <UrON-JG2MMegyFMEN0RnsQXQiBqeWn_xmyioBQCMOaQ=.11c34cc3-e675-437c-b7bc-757fd58563ca@github.com>
References: <aYRbIKEZmDlWfryC0sW1BSVtzJyIR7BRZS2Vs0XfGaY=.de31b4a7-d2df-489a-9816-08deab0cddef@github.com>
 <BeN0ieY-9mauOUxv6aUlC3VU7lvOy7TA4_n4soZwZ9Y=.806f69e0-635c-4f72-8f75-89c73668572d@github.com>
 <UrON-JG2MMegyFMEN0RnsQXQiBqeWn_xmyioBQCMOaQ=.11c34cc3-e675-437c-b7bc-757fd58563ca@github.com>
Message-ID: <GPiDNAwNKvMY00tj5H7cN_7Qfx2h5m_JWVn3D7JmroM=.ea9f3d64-7a6b-423d-b47a-a141b390758d@github.com>

On Wed, 3 Feb 2021 10:43:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing merge tags are noted on the review - thanks!
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 167:
> 
>> 165:     /** Flag for synthesized default constructors of anonymous classes.
>> 166:      */
>> 167:     public static final int ANONCONSTR   = 1<<27;
> 
> Question: why this, and other flags that are specific to only one symbol kind have not been translated into the enum? Other examples are `ANONCONSTR_BASED`, `GENERATEDCONSTR`, `COMPACT_RECORD_CONSTRUCTOR`, `THROWS` and probably more.

Some of these (IIRC e.g. GENERATEDCONSTR, ANNONCONSTR) are also set on trees, and read and written as bitmasks, so it is more difficult to separate them to e.g. methods only. A few others could possibly be move with a little more code shuffling.

-------------

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

From jlahoda at openjdk.java.net  Wed Feb  3 13:31:41 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 3 Feb 2021 13:31:41 GMT
Subject: RFR: 8241356: Use a more reliable way to encode Symbol flags [v2]
In-Reply-To: <2hjUP_18of5ES1130eAY94Chyy0fMqsQQwgXCpPWQuQ=.a0952a36-c55d-486c-b1dd-01dd657b9ef0@github.com>
References: <aYRbIKEZmDlWfryC0sW1BSVtzJyIR7BRZS2Vs0XfGaY=.de31b4a7-d2df-489a-9816-08deab0cddef@github.com>
 <BeN0ieY-9mauOUxv6aUlC3VU7lvOy7TA4_n4soZwZ9Y=.806f69e0-635c-4f72-8f75-89c73668572d@github.com>
 <UrON-JG2MMegyFMEN0RnsQXQiBqeWn_xmyioBQCMOaQ=.11c34cc3-e675-437c-b7bc-757fd58563ca@github.com>
 <2hjUP_18of5ES1130eAY94Chyy0fMqsQQwgXCpPWQuQ=.a0952a36-c55d-486c-b1dd-01dd657b9ef0@github.com>
Message-ID: <8FjBush8jmHv6T-EkbJbVt4yX8m0c4pUhUOBRJbtfAs=.4ddd72c5-4248-4119-b273-87ee31a1ca32@github.com>

On Wed, 3 Feb 2021 10:59:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I'm also worried about where does this leave symbol construction - for instance, in TypeEnter I now see these lines (unchanged in this patch):
> 
> ```
> params.add(new VarSymbol(
>                         GENERATED_MEMBER | PARAMETER | RECORD | (field == lastField && lastIsVarargs ? Flags.VARARGS : 0),
>                         field.name, field.sym.type, csym));
> ```
> 
> Here, it seems, we are forced to just use a flat flags mask in the constructor - in other words, the new API is only for testing, and there is an asymmetry between construction and testing.

The flat flags work exactly as before (i.e. set as bits and checked as bit masks), and that are these bits set here. Only the symbol-kind specific flags are set and checked using methods, see e.g. the constructor for BindingSymbol.

-------------

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

From redestad at openjdk.java.net  Wed Feb  3 14:07:42 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 3 Feb 2021 14:07:42 GMT
Subject: RFR: JDK-8260593: javac can skip a temporary local variable when
 pattern matching over a local variable [v2]
In-Reply-To: <1Rx9HLwSpUz6TVydNUoM9Ax8MxpEA5OVz931C-KurLY=.92ab4213-3d09-4d7f-bf18-7ea3ac6c8c6d@github.com>
References: <K3mcIdlZxb_NWWtbtka1dWx0GouNlv4rnFhxHZPveY4=.dbf12096-6ed5-401c-a893-7d4b37c0f179@github.com>
 <1Rx9HLwSpUz6TVydNUoM9Ax8MxpEA5OVz931C-KurLY=.92ab4213-3d09-4d7f-bf18-7ea3ac6c8c6d@github.com>
Message-ID: <hNO7tjelN0YG2hXnJyGxu1h1hZ6cnU9wC_4VHd_T57A=.aa009496-2ec2-4b39-b34f-3911b9fc73f5@github.com>

On Fri, 29 Jan 2021 19:46:36 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing tests.
>
> looks sensible

Thanks for picking up and fixing this, Jan!

-------------

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

From neshkeev at yandex.ru  Wed Feb  3 16:00:09 2021
From: neshkeev at yandex.ru (Nikita Eshkeev)
Date: Wed, 03 Feb 2021 19:00:09 +0300
Subject: PreviewFeature on packages and modules
Message-ID: <222161612366851@mail.yandex.ru>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210203/25a15bd3/attachment.htm>

From alex.buckley at oracle.com  Wed Feb  3 17:54:40 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 3 Feb 2021 09:54:40 -0800
Subject: PreviewFeature on packages and modules
In-Reply-To: <222161612366851@mail.yandex.ru>
References: <222161612366851@mail.yandex.ru>
Message-ID: <1e843faa-5884-ec9f-d01b-e34f71741551@oracle.com>

It looks like your neshkeev/jdk repo was forked from openjdk/jdk very 
recently, so your compiler should have the latest support for preview 
APIs. That support is specified at 
https://bugs.openjdk.java.net/browse/JDK-8249554 -- when preview 
features are enabled/disabled, no warning/error is due if "The 
declaration where the use of a preview API element appears is within the 
same module as the declaration of the preview API element."  This rule 
reflects the JEP 12 policy you refer to, where source code in the same 
module as a preview API is deemed as "participating" and causes no 
warnings/errors.

I can't tell where your Main.java file lives at compile time, but 
presumably you are not accidentally placing it in the jdk.neshkeev 
module. Like you, I expect a warning/error for Main's reference to 
MyPreviewClass, since Main is not participating in your preview API.

Alex

On 2/3/2021 8:00 AM, Nikita Eshkeev wrote:
> The PreviewFeature 
> (https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java 
> <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java>) 
> annotation can be applied to modules and packages. But I don't get any 
> compile-time errors/warnings when I try to use code that is inside of 
> either a package or a module that is annotated with PreviewFeature.
> What I did
> 1. I added a new module to openjdk with the "jdk.neshkeev" name
> 2. I added module-info.java, package-info.java and MyPreviewClass.java 
> (which is just an empty class)
> 3. I annotated both module-info.java and package-info.java with 
> PreviewFeature
> 4. I exported jdk.internal.javac package to jdk.neshkeev in 
> module-info.java of java.base
> 5. `make images` the jdk's source code
> 6. I created Main.java with the following content
> class Main {
>  ?{
>  ? ?new jdk.neshkeev.MyPreviewClass();
>  ?}
> }
> 7. I compiled Main.java with my openjdk that was built in the step 5.
> Here is the link to my openjdk fork with the jdk.neshkeev module: 
> https://github.com/neshkeev/jdk <https://github.com/neshkeev/jdk>
> What is expected
> Since MyPreviewClass is inside of the package that is annotated with 
> PreviewFeature and it is also inside of the module that is also 
> annotated with PreviewFeature I expect to get compile time 
> errors/warnings. I believe that compile-time errors/warnings should 
> arise since Main.java can't be considered as participating source code
> What happened
> No compile-time errors/warnings occurred
> Is this a bug?

From joe.darcy at oracle.com  Wed Feb  3 18:01:31 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 3 Feb 2021 10:01:31 -0800
Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation
 type
In-Reply-To: <C0E0B8F2-0E5D-4DED-87AE-8D15B39CA372@oracle.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
 <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
 <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>
 <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com>
 <PEhAZNV434d5RP5m0cH5X5MvUv8tmg-TuPfM1eFqtOQ=.e1483dc5-9c8d-4282-82dc-0d264c7c646d@github.com>
 <54e81069-d66b-d466-77eb-a425ff4ee336@oracle.com>
 <C0E0B8F2-0E5D-4DED-87AE-8D15B39CA372@oracle.com>
Message-ID: <2aaa7cac-a84c-7610-51dd-17769688a48d@oracle.com>

Hello,

To me, it seems that intending an annotation to be used on declarations 
or on types is a basic design decision of the annotation type. I think 
it can be reasonable to interpret lack of @Target to mean "usable in any 
declaration context," but ill-advised to silently reinterpret absence of 
a @Target to indicate types and declarations.

Cheers,

-Joe

On 2/3/2021 5:29 AM, Joel Borggren-Franck wrote:
> Hi Alex,
>
> Looking at  the class file, and therefore reflection, there is a difference between ?all declaration contexts? and ?all contexts, declaration + type?. For the 5 ambiguous locations we would have to produce type annotation attributes if there is an annotation present whose declaration lack @Target. While this may or may not be desirable, and I?m leaning towards not, it is surely significant as it would change the semantics of reflective annotation processors in use.
>
> cheers
> /Joel
>
>> On 2 Feb 2021, at 19:50, Alex Buckley <alex.buckley at oracle.com> wrote:
>>
>> I initially proposed "all declaration contexts" as the smallest possible streamlining of the SE 7-oriented rule defined in SE 8. It would have ensured that legacy annotation types without @Target were locked out of the new world of type uses enabled in SE 8 by JSR 308. As it turned out, my conservative approach was unnecessary because Mike was fine with admitting those legacy annotation types for type uses via the "all contexts" rule. In the real world, "all declaration contexts" versus "all declaration contexts + all type contexts" is a distinction without a difference (that is, an insignificant distinction) -- we're best off adopting the latter rule, phrased simply as "all contexts".
>>
>> Alex
>>
>> On 2/2/2021 3:44 AM, Guoxiong Li wrote:
>>> On Tue, 2 Feb 2021 09:28:59 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:
>>>>> Thanks for the comments,
>>>>>
>>>>> @jbf I'll add a more focused test. For the bug, the original discussion in https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013705.html is specifically about annotations without an explicit `@Target` applying to `MODULE`, I don't think there's anything that needs to be done for [JDK-8231436](https://bugs.openjdk.java.net/browse/JDK-8231436) besides supporting `MODULE`, would you still prefer a separate bug?
>>>>>
>>>>> @jddarcy note that there was already a spec change related to this in [JDK-8231435](https://bugs.openjdk.java.net/browse/JDK-8231435) and the spec bug mentions "this expansion is source, binary, and behaviorally compatible", should I still file a CSR?
>>>>  From this follow up here: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013715.html my interpretation is that this bug was intended to widen it to all contexts, including type use. This has been changed in JLS but not in the normative javadoc and also not in the compiler. I believe we should keep declarations only, and back out the change to JLS.
>>> Maybe we should collect the concrete information about this problem. Here are some materials that I know.
>>> Order by time:
>>> - 2019.08 **Werner Dietl** launched the discussion. [1]
>>> - 2019.09 After the discussion between **Alex Buckley** and **Michael Ernst**, an initiative result came out.[2]
>>> - 2019.09 Two JBS issues were filed. [3][4]
>>> - 2019.12 **Alex Buckley** fixed the JLS(fix version: 14). But the compiler code and javadoc were not fixed. [5][6]
>>> - 2020.10 **Christian Stein** created another issue about it. [7]
>>> - 2020.10 **Guoxiong Li**(me) submitted a PR about it in Github. [8]
>>> - 2020.10 **Joel Borggr?n-Franck** restarted the discussion about the specification. [9]
>>> - 2020.12 Because the JDK16 was nearly at RDP1, we decided to only fix JDK-8254023. And other work left to JDk17.  [7][10][11]
>>> - 2020.12 The issue JDK-8254023 was fixed at JDK16. [7][8][12]
>>> - **Now, we need to discuss the problem(unify the specification, implement and javadoc) that JDK16 has left.**[11]
>>> [1] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-August/013666.html
>>> [2] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013705.html
>>> [3] https://bugs.openjdk.java.net/browse/JDK-8231435
>>> [4] https://bugs.openjdk.java.net/browse/JDK-8231436
>>> [5] https://docs.oracle.com/javase/specs/jls/se14/html/jls-9.html#jls-9.6.4.1
>>> [6] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/annotation/Target.html
>>> [7] https://bugs.openjdk.java.net/browse/JDK-8254023
>>> [8] https://github.com/openjdk/jdk/pull/622
>>> [9] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015197.html
>>> [10] http://openjdk.java.net/projects/jdk/16/
>>> [11] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015503.html
>>> [12] https://github.com/openjdk/jdk16/pull/34
>>> -------------
>>> PR: https://git.openjdk.java.net/jdk/pull/2303

From mcimadamore at openjdk.java.net  Wed Feb  3 18:07:45 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 3 Feb 2021 18:07:45 GMT
Subject: RFR: 8241356: Use a more reliable way to encode Symbol flags [v2]
In-Reply-To: <GPiDNAwNKvMY00tj5H7cN_7Qfx2h5m_JWVn3D7JmroM=.ea9f3d64-7a6b-423d-b47a-a141b390758d@github.com>
References: <aYRbIKEZmDlWfryC0sW1BSVtzJyIR7BRZS2Vs0XfGaY=.de31b4a7-d2df-489a-9816-08deab0cddef@github.com>
 <BeN0ieY-9mauOUxv6aUlC3VU7lvOy7TA4_n4soZwZ9Y=.806f69e0-635c-4f72-8f75-89c73668572d@github.com>
 <UrON-JG2MMegyFMEN0RnsQXQiBqeWn_xmyioBQCMOaQ=.11c34cc3-e675-437c-b7bc-757fd58563ca@github.com>
 <GPiDNAwNKvMY00tj5H7cN_7Qfx2h5m_JWVn3D7JmroM=.ea9f3d64-7a6b-423d-b47a-a141b390758d@github.com>
Message-ID: <neVWMpNL-T8_rEA4gyN2U9dJdUYMz9L_20T-icWNvMY=.3e743231-3e7e-4f08-8aab-9d863f8dfb66@github.com>

On Wed, 3 Feb 2021 13:26:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 167:
>> 
>>> 165:     /** Flag for synthesized default constructors of anonymous classes.
>>> 166:      */
>>> 167:     public static final int ANONCONSTR   = 1<<27;
>> 
>> Question: why this, and other flags that are specific to only one symbol kind have not been translated into the enum? Other examples are `ANONCONSTR_BASED`, `GENERATEDCONSTR`, `COMPACT_RECORD_CONSTRUCTOR`, `THROWS` and probably more.
>
> Some of these (IIRC e.g. GENERATEDCONSTR, ANNONCONSTR) are also set on trees, and read and written as bitmasks, so it is more difficult to separate them to e.g. methods only. A few others could possibly be move with a little more code shuffling.

I see what you mean - as I said, my worry is that, while this patch addresses the paucity of flags in an effective fashion, the resulting code base end up being worse than it was to begin with, as now a client will have to hunt flags in different enums. If the organization was consistent, I'd have no problem with giving each kind of flag its own enum - but given that the organization is more ad-hoc (e.g. driven by which use cases could be morphed into using enums), I'm unsure.

I mean, what's the advantage of the proposed solution vs. organizing the set of long flags in Flags by categories - so that there's no enum, but so that e.g. a variable symbol flag can reuse the same value as some other method symbol flag?

I think it would deliver same saving, w/o the need to change the flag API. Granted, we also not get any protection for when somebody tries to "merge" flags that are not mergeable - but I'm equally not sure as to whether the proposed solution offers a much more principled alternative?

-------------

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

From cushon at openjdk.java.net  Wed Feb  3 18:22:41 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Wed, 3 Feb 2021 18:22:41 GMT
Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation
 type
In-Reply-To: <PEhAZNV434d5RP5m0cH5X5MvUv8tmg-TuPfM1eFqtOQ=.e1483dc5-9c8d-4282-82dc-0d264c7c646d@github.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
 <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
 <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>
 <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com>
 <PEhAZNV434d5RP5m0cH5X5MvUv8tmg-TuPfM1eFqtOQ=.e1483dc5-9c8d-4282-82dc-0d264c7c646d@github.com>
Message-ID: <AMFQBSUNCfPhqXJV_sFSoZKdkrdTHEl_kG5aSFP1Jbc=.aa266fbf-3662-497b-9dc0-6e093d25fc85@github.com>

On Tue, 2 Feb 2021 11:03:17 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> From this follow up here: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013715.html my interpretation is that this bug was intended to widen it to all contexts, including type use. This has been changed in JLS but not in the normative javadoc and also not in the compiler. I believe we should keep declarations only, and back out the change to JLS.
>
> Maybe we should collect the concrete information about this problem. Here are some materials that I know.
> 
> Order by time:
> - 2019.08 **Werner Dietl** launched the discussion. [1]
> - 2019.09 After the discussion between **Alex Buckley** and **Michael Ernst**, an initiative result came out.[2]
> - 2019.09 Two JBS issues were filed. [3][4]
> - 2019.12 **Alex Buckley** fixed the JLS(fix version: 14). But the compiler code and javadoc were not fixed. [5][6]
> - 2020.10 **Christian Stein** created another issue about it. [7]
> - 2020.10 **Guoxiong Li**(me) submitted a PR about it in Github. [8]
> - 2020.10 **Joel Borggr?n-Franck** restarted the discussion about the specification. [9]
> - 2020.12 Because the JDK16 was nearly at RDP1, we decided to only fix JDK-8254023. And other work left to JDk17.  [7][10][11]
> - 2020.12 The issue JDK-8254023 was fixed at JDK16. [7][8][12]
> - **Now, we need to discuss the problem(unify the specification, implement and javadoc) that JDK16 has left.**[11]
> 
> [1] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-August/013666.html
> [2] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013705.html
> [3] https://bugs.openjdk.java.net/browse/JDK-8231435
> [4] https://bugs.openjdk.java.net/browse/JDK-8231436
> [5] https://docs.oracle.com/javase/specs/jls/se14/html/jls-9.html#jls-9.6.4.1
> [6] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/annotation/Target.html
> [7] https://bugs.openjdk.java.net/browse/JDK-8254023
> [8] https://github.com/openjdk/jdk/pull/622
> [9] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015197.html
> [10] http://openjdk.java.net/projects/jdk/16/
> [11] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015503.html
> [12] https://github.com/openjdk/jdk16/pull/34

Thanks, I was missing context here. I now realize this patch is fixing a bug related to [JDK-8254023](https://bugs.openjdk.java.net/browse/JDK-8254023)--when the handling of annotations without `@Target` was updated to allow them to be applied to module declarations, the handling of repeatable annotations without `@Target` should also have been updated. I filed a new bug for the sub-issue that this patch is fixing, and will update it accordingly in a minute: https://bugs.openjdk.java.net/browse/JDK-8261088

I'm also happy to help with any work to be done on the larger question of interpreting `@Target`-less annotations as applicable to type contexts, if there's agreement about what to do there.

-------------

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

From alex.buckley at oracle.com  Wed Feb  3 18:39:35 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 3 Feb 2021 10:39:35 -0800
Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation
 type
In-Reply-To: <C0E0B8F2-0E5D-4DED-87AE-8D15B39CA372@oracle.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
 <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
 <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>
 <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com>
 <PEhAZNV434d5RP5m0cH5X5MvUv8tmg-TuPfM1eFqtOQ=.e1483dc5-9c8d-4282-82dc-0d264c7c646d@github.com>
 <54e81069-d66b-d466-77eb-a425ff4ee336@oracle.com>
 <C0E0B8F2-0E5D-4DED-87AE-8D15B39CA372@oracle.com>
Message-ID: <3d96a404-9bca-97d7-47fc-2de3c6af8726@oracle.com>

Let me focus first on the design question of what a no- at Target 
annotation type "means". There's no particular reason why it _shouldn't_ 
mean "all contexts". Mike gave good reasons why it should mean that. For 
the corner case of an annotation appearing in one of the ambiguous 
locations in source code, the annotation will appear in the class 
file/via reflection exactly as if someone had taken the perfectly 
legitimate course of spelling out @Target({METHOD, TYPE_USE}) -- the 
no- at Target case is not a secret door to behavior that's otherwise 
impossible or undesirable.

(We could have said "all contexts" for a no- at Target annotation type but 
then added a rule in 9.7.4 to special-case a no- at Target annotation that 
appears in an ambiguous location, e.g., to compile the annotation as if 
it was applicable only in declaration contexts. More compatibility with 
SE 8, but more complexity, and I don't think anyone really wants that.)

Turning to the compatibility concern: yes, JDK-8231435 shouldn't have 
claimed behavioral compatibility. It was my error to not recognize what 
Mike was saying in "It is a behavior change from the current 
specification, but a small one that affects poorly-written programs that 
have no @Target meta-annotation." Still, at the end of the day, it's no 
more than a small behavioral incompatibility for annotation processors 
(they may see more type annotations than they did before), and one which 
was within the power of the annotation type's owner to induce anyway 
(annotation processors that look for type annotations can reasonably be 
expected to ignore type annotations in places they don't care about).

I have cc'd Mike in case he wants to add anything further, but the 
design intent of "all contexts" still looks reasonable to me.

Alex

On 2/3/2021 5:29 AM, Joel Borggren-Franck wrote:
> Hi Alex,
> 
> Looking at  the class file, and therefore reflection, there is a difference between ?all declaration contexts? and ?all contexts, declaration + type?. For the 5 ambiguous locations we would have to produce type annotation attributes if there is an annotation present whose declaration lack @Target. While this may or may not be desirable, and I?m leaning towards not, it is surely significant as it would change the semantics of reflective annotation processors in use.
> 
> cheers
> /Joel
> 
>> On 2 Feb 2021, at 19:50, Alex Buckley <alex.buckley at oracle.com> wrote:
>>
>> I initially proposed "all declaration contexts" as the smallest possible streamlining of the SE 7-oriented rule defined in SE 8. It would have ensured that legacy annotation types without @Target were locked out of the new world of type uses enabled in SE 8 by JSR 308. As it turned out, my conservative approach was unnecessary because Mike was fine with admitting those legacy annotation types for type uses via the "all contexts" rule. In the real world, "all declaration contexts" versus "all declaration contexts + all type contexts" is a distinction without a difference (that is, an insignificant distinction) -- we're best off adopting the latter rule, phrased simply as "all contexts".
>>
>> Alex
>>
>> On 2/2/2021 3:44 AM, Guoxiong Li wrote:
>>> On Tue, 2 Feb 2021 09:28:59 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:
>>>>> Thanks for the comments,
>>>>>
>>>>> @jbf I'll add a more focused test. For the bug, the original discussion in https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013705.html is specifically about annotations without an explicit `@Target` applying to `MODULE`, I don't think there's anything that needs to be done for [JDK-8231436](https://bugs.openjdk.java.net/browse/JDK-8231436) besides supporting `MODULE`, would you still prefer a separate bug?
>>>>>
>>>>> @jddarcy note that there was already a spec change related to this in [JDK-8231435](https://bugs.openjdk.java.net/browse/JDK-8231435) and the spec bug mentions "this expansion is source, binary, and behaviorally compatible", should I still file a CSR?
>>>>
>>>>  From this follow up here: https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013715.html my interpretation is that this bug was intended to widen it to all contexts, including type use. This has been changed in JLS but not in the normative javadoc and also not in the compiler. I believe we should keep declarations only, and back out the change to JLS.
>>> Maybe we should collect the concrete information about this problem. Here are some materials that I know.
>>> Order by time:
>>> - 2019.08 **Werner Dietl** launched the discussion. [1]
>>> - 2019.09 After the discussion between **Alex Buckley** and **Michael Ernst**, an initiative result came out.[2]
>>> - 2019.09 Two JBS issues were filed. [3][4]
>>> - 2019.12 **Alex Buckley** fixed the JLS(fix version: 14). But the compiler code and javadoc were not fixed. [5][6]
>>> - 2020.10 **Christian Stein** created another issue about it. [7]
>>> - 2020.10 **Guoxiong Li**(me) submitted a PR about it in Github. [8]
>>> - 2020.10 **Joel Borggr?n-Franck** restarted the discussion about the specification. [9]
>>> - 2020.12 Because the JDK16 was nearly at RDP1, we decided to only fix JDK-8254023. And other work left to JDk17.  [7][10][11]
>>> - 2020.12 The issue JDK-8254023 was fixed at JDK16. [7][8][12]
>>> - **Now, we need to discuss the problem(unify the specification, implement and javadoc) that JDK16 has left.**[11]
>>> [1] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-August/013666.html
>>> [2] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013705.html
>>> [3] https://bugs.openjdk.java.net/browse/JDK-8231435
>>> [4] https://bugs.openjdk.java.net/browse/JDK-8231436
>>> [5] https://docs.oracle.com/javase/specs/jls/se14/html/jls-9.html#jls-9.6.4.1
>>> [6] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/annotation/Target.html
>>> [7] https://bugs.openjdk.java.net/browse/JDK-8254023
>>> [8] https://github.com/openjdk/jdk/pull/622
>>> [9] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015197.html
>>> [10] http://openjdk.java.net/projects/jdk/16/
>>> [11] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015503.html
>>> [12] https://github.com/openjdk/jdk16/pull/34
>>> -------------
>>> PR: https://git.openjdk.java.net/jdk/pull/2303
> 

From jlahoda at openjdk.java.net  Wed Feb  3 18:41:40 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 3 Feb 2021 18:41:40 GMT
Subject: RFR: 8241356: Use a more reliable way to encode Symbol flags [v2]
In-Reply-To: <neVWMpNL-T8_rEA4gyN2U9dJdUYMz9L_20T-icWNvMY=.3e743231-3e7e-4f08-8aab-9d863f8dfb66@github.com>
References: <aYRbIKEZmDlWfryC0sW1BSVtzJyIR7BRZS2Vs0XfGaY=.de31b4a7-d2df-489a-9816-08deab0cddef@github.com>
 <BeN0ieY-9mauOUxv6aUlC3VU7lvOy7TA4_n4soZwZ9Y=.806f69e0-635c-4f72-8f75-89c73668572d@github.com>
 <UrON-JG2MMegyFMEN0RnsQXQiBqeWn_xmyioBQCMOaQ=.11c34cc3-e675-437c-b7bc-757fd58563ca@github.com>
 <GPiDNAwNKvMY00tj5H7cN_7Qfx2h5m_JWVn3D7JmroM=.ea9f3d64-7a6b-423d-b47a-a141b390758d@github.com>
 <neVWMpNL-T8_rEA4gyN2U9dJdUYMz9L_20T-icWNvMY=.3e743231-3e7e-4f08-8aab-9d863f8dfb66@github.com>
Message-ID: <gtf1bw-8XKvok8PA18DWx8wMmvDp_5nIHvIckavjt6s=.4cbd9e02-c188-43d2-a928-9d9d4d617513@github.com>

On Wed, 3 Feb 2021 18:05:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I see what you mean - as I said, my worry is that, while this patch addresses the paucity of flags in an effective fashion, the resulting code base end up being worse than it was to begin with, as now a client will have to hunt flags in different enums. If the organization was consistent, I'd have no problem with giving each kind of flag its own enum - but given that the organization is more ad-hoc (e.g. driven by which use cases could be morphed into using enums), I'm unsure.
> 
> I mean, what's the advantage of the proposed solution vs. organizing the set of long flags in Flags by categories - so that there's no enum, but so that e.g. a variable symbol flag can reuse the same value as some other method symbol flag?
> 
> I think it would deliver same saving, w/o the need to change the flag API. Granted, we also not get any protection for when somebody tries to "merge" flags that are not mergeable - but I'm equally not sure as to whether the proposed solution offers a much more principled alternative?

I don't think this is a more principled alternative, the main goal here was to reuse the flag bits as safely as possible. Reusing the same bits across various Symbols manually is basically what we do now, but, for me, it is often difficult to prove that a bit is used only for (e.g.) VarSymbols and I can reuse it for MethodSymbols. With this patch, most of the (symbol-specific) checks are done statically, some are done at runtime (via casts), but we can't easily set a method-only flags on a VariableSymbol by accident.

-------------

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

From neshkeev at yandex.ru  Wed Feb  3 19:42:27 2021
From: neshkeev at yandex.ru (Nikita Eshkeev)
Date: Wed, 03 Feb 2021 22:42:27 +0300
Subject: PreviewFeature on packages and modules
In-Reply-To: <1e843faa-5884-ec9f-d01b-e34f71741551@oracle.com>
References: <222161612366851@mail.yandex.ru>
 <1e843faa-5884-ec9f-d01b-e34f71741551@oracle.com>
Message-ID: <147911612380208@iva4-57c3b416b70c.qloud-c.yandex.net>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210203/de550905/attachment.htm>

From alex.buckley at oracle.com  Wed Feb  3 20:11:36 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 3 Feb 2021 12:11:36 -0800
Subject: [External] : Re: PreviewFeature on packages and modules
In-Reply-To: <147911612380208@iva4-57c3b416b70c.qloud-c.yandex.net>
References: <222161612366851@mail.yandex.ru>
 <1e843faa-5884-ec9f-d01b-e34f71741551@oracle.com>
 <147911612380208@iva4-57c3b416b70c.qloud-c.yandex.net>
Message-ID: <493789ad-5d87-f122-71bf-2522a8e880a8@oracle.com>

On 2/3/2021 11:42 AM, Nikita Eshkeev wrote:
> I haven't seen https://bugs.openjdk.java.net/browse/JDK-8249554 , but 
> I've been perusing JEP-12 https://openjdk.java.net/jeps/12 for quite 
> some time now and it says the following about the modules:
> 
> "To allow for intra-JDK use of a preview API, source code in the same 
> module as a preview API is deemed to be "participating..."
> 
> I can only guess that "intra-JDK" here means that the module is used by 
> other modules inside the JDK, the JEP doesn't mention how modules that 
> are introduced as preview API (annotated with PreviewFeature) is used 
> outside the JDK.

JDK modules are relatively large and rich. It would be unfortunate if a 
preview API in, say, java.base, couldn't be used elsewhere in java.base, 
either in the implementation of a method within java.base or in the 
public signature of some other exported API of java.base. (A flaw of 
incubating APIs is that standard API signatures can't be enhanced to 
accept and return classes of the incubating API. That limits exposure of 
the incubating API, which means less feedback. Preview APIs, with their 
greater claim to stability, appear in java.* packages and can thus 
appear in standard API signatures.)

That's what the intra-JDK scenario is about -- use within the same 
module. We might wish to expand the scenario in future, to allow use by 
other JDK modules that have "some" relationship with the declaring 
module, but that's not been shown to be necessary yet.

I'm not sure what you mean by "the JEP doesn't mention how modules that 
are introduced as preview API is used outside the JDK". A preview API is 
defined to include a module or a package, not just a class or interface, 
so any use of an @PreviewFeature module by non-participating source code 
should trigger the warning/error described in "Use of Preview Features". 
Whether the non-participating source code is in some other java.* 
module, or in some jdk.* module, or in some user module doesn't matter.

> The JEP mentions that the code that is inside a package that is 
> introduced as preview API is considered as participating and doesn't 
> generate compile-time errors/warning, so I conclude that javac hasn't 
> implemented this part yet, but it should.

Right.

Alex

> 03.02.2021, 20:54, "Alex Buckley" <alex.buckley at oracle.com>:
> 
>     It looks like your neshkeev/jdk repo was forked from openjdk/jdk very
>     recently, so your compiler should have the latest support for preview
>     APIs. That support is specified at
>     https://bugs.openjdk.java.net/browse/JDK-8249554
>     <https://bugs.openjdk.java.net/browse/JDK-8249554> -- when preview
>     features are enabled/disabled, no warning/error is due if "The
>     declaration where the use of a preview API element appears is within
>     the
>     same module as the declaration of the preview API element." This rule
>     reflects the JEP 12 policy you refer to, where source code in the same
>     module as a preview API is deemed as "participating" and causes no
>     warnings/errors.
> 
>     I can't tell where your Main.java file lives at compile time, but
>     presumably you are not accidentally placing it in the jdk.neshkeev
>     module. Like you, I expect a warning/error for Main's reference to
>     MyPreviewClass, since Main is not participating in your preview API.
> 
>     Alex
> 
>     On 2/3/2021 8:00 AM, Nikita Eshkeev wrote:
> 
>          ?The PreviewFeature
>          ?(https://github.com/openjdk/jdk/blob/master/src/java.base/sha?
>         <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java__;!!GqivPVa7Brio!LxjKv9JdKyJ8GVP6bYd5mhzj4IQaifeEJOjjdwfCgrWzJ5_pgydVKDGFKjP3a0N-3Us$>
> 
>          ?<https://github.com/openjdk/jdk/blob/master/src/java.base/sha?
>         <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java__;!!GqivPVa7Brio!LxjKv9JdKyJ8GVP6bYd5mhzj4IQaifeEJOjjdwfCgrWzJ5_pgydVKDGFKjP3a0N-3Us$>>)
> 
>          ?annotation can be applied to modules and packages. But I don't
>         get any
>          ?compile-time errors/warnings when I try to use code that is
>         inside of
>          ?either a package or a module that is annotated with
>         PreviewFeature.
>          ?What I did
>          ?1. I added a new module to openjdk with the "jdk.neshkeev" name
>          ?2. I added module-info.java, package-info.java and
>         MyPreviewClass.java
>          ?(which is just an empty class)
>          ?3. I annotated both module-info.java and package-info.java with
>          ?PreviewFeature
>          ?4. I exported jdk.internal.javac package to jdk.neshkeev in
>          ?module-info.java of java.base
>          ?5. `make images` the jdk's source code
>          ?6. I created Main.java with the following content
>          ?class Main {
>          ???{
>          ??? ?new jdk.neshkeev.MyPreviewClass();
>          ???}
>          ?}
>          ?7. I compiled Main.java with my openjdk that was built in the
>         step 5.
>          ?Here is the link to my openjdk fork with the jdk.neshkeev module:
>         https://github.com/neshkeev/jdk
>         <https://urldefense.com/v3/__https://github.com/neshkeev/jdk__;!!GqivPVa7Brio!LxjKv9JdKyJ8GVP6bYd5mhzj4IQaifeEJOjjdwfCgrWzJ5_pgydVKDGFKjP3fmAa7N8$>
>         <https://github.com/neshkeev/jdk
>         <https://urldefense.com/v3/__https://github.com/neshkeev/jdk__;!!GqivPVa7Brio!LxjKv9JdKyJ8GVP6bYd5mhzj4IQaifeEJOjjdwfCgrWzJ5_pgydVKDGFKjP3fmAa7N8$>>
>          ?What is expected
>          ?Since MyPreviewClass is inside of the package that is
>         annotated with
>          ?PreviewFeature and it is also inside of the module that is also
>          ?annotated with PreviewFeature I expect to get compile time
>          ?errors/warnings. I believe that compile-time errors/warnings
>         should
>          ?arise since Main.java can't be considered as participating
>         source code
>          ?What happened
>          ?No compile-time errors/warnings occurred
>          ?Is this a bug?
> 
> 
> 
> 

From jan.lahoda at oracle.com  Wed Feb  3 21:30:09 2021
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Wed, 3 Feb 2021 22:30:09 +0100
Subject: PreviewFeature on packages and modules
In-Reply-To: <1e843faa-5884-ec9f-d01b-e34f71741551@oracle.com>
References: <222161612366851@mail.yandex.ru>
 <1e843faa-5884-ec9f-d01b-e34f71741551@oracle.com>
Message-ID: <fb5edb89-42a9-276d-6cd1-ae8dac3e196d@oracle.com>

On 03. 02. 21 18:54, Alex Buckley wrote:

> It looks like your neshkeev/jdk repo was forked from openjdk/jdk very 
> recently, so your compiler should have the latest support for preview 
> APIs. That support is specified at 
> https://bugs.openjdk.java.net/browse/JDK-8249554 -- when preview 
> features are enabled/disabled, no warning/error is due if "The 
> declaration where the use of a preview API element appears is within 
> the same module as the declaration of the preview API element."? This 
> rule reflects the JEP 12 policy you refer to, where source code in the 
> same module as a preview API is deemed as "participating" and causes 
> no warnings/errors.
>
> I can't tell where your Main.java file lives at compile time, but 
> presumably you are not accidentally placing it in the jdk.neshkeev 
> module. Like you, I expect a warning/error for Main's reference to 
> MyPreviewClass, since Main is not participating in your preview API.


One thing to note here is e.g. @Deprecated on a package does not 
automatically deprecate the classes belonging to the given package. 
Here, we have a package annotated with @PreviewFeature, but not a class 
annotated as a preview feature, and the preview flag is not propagated 
from packages to classes, similarly to the deprecated flag. But we can 
surely make this particular flag to propagate to the classes in the 
package, if desired.

Jan

>
> Alex
>
> On 2/3/2021 8:00 AM, Nikita Eshkeev wrote:
>> The PreviewFeature 
>> (https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java 
>> <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java>) 
>> annotation can be applied to modules and packages. But I don't get 
>> any compile-time errors/warnings when I try to use code that is 
>> inside of either a package or a module that is annotated with 
>> PreviewFeature.
>> What I did
>> 1. I added a new module to openjdk with the "jdk.neshkeev" name
>> 2. I added module-info.java, package-info.java and 
>> MyPreviewClass.java (which is just an empty class)
>> 3. I annotated both module-info.java and package-info.java with 
>> PreviewFeature
>> 4. I exported jdk.internal.javac package to jdk.neshkeev in 
>> module-info.java of java.base
>> 5. `make images` the jdk's source code
>> 6. I created Main.java with the following content
>> class Main {
>> ??{
>> ?? ?new jdk.neshkeev.MyPreviewClass();
>> ??}
>> }
>> 7. I compiled Main.java with my openjdk that was built in the step 5.
>> Here is the link to my openjdk fork with the jdk.neshkeev module: 
>> https://github.com/neshkeev/jdk <https://github.com/neshkeev/jdk>
>> What is expected
>> Since MyPreviewClass is inside of the package that is annotated with 
>> PreviewFeature and it is also inside of the module that is also 
>> annotated with PreviewFeature I expect to get compile time 
>> errors/warnings. I believe that compile-time errors/warnings should 
>> arise since Main.java can't be considered as participating source code
>> What happened
>> No compile-time errors/warnings occurred
>> Is this a bug?

From alex.buckley at oracle.com  Wed Feb  3 22:58:24 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 3 Feb 2021 14:58:24 -0800
Subject: PreviewFeature on packages and modules
In-Reply-To: <fb5edb89-42a9-276d-6cd1-ae8dac3e196d@oracle.com>
References: <222161612366851@mail.yandex.ru>
 <1e843faa-5884-ec9f-d01b-e34f71741551@oracle.com>
 <fb5edb89-42a9-276d-6cd1-ae8dac3e196d@oracle.com>
Message-ID: <5aa38fa0-0fd0-3efa-2d8b-72f7e4a2a4a6@oracle.com>

On 2/3/2021 1:30 PM, Jan Lahoda wrote:
> One thing to note here is e.g. @Deprecated on a package does not 
> automatically deprecate the classes belonging to the given package. 
> Here, we have a package annotated with @PreviewFeature, but not a class 
> annotated as a preview feature, and the preview flag is not propagated 
> from packages to classes, similarly to the deprecated flag. But we can 
> surely make this particular flag to propagate to the classes in the 
> package, if desired.

Thanks for the info. I agree that a package being annotated with 
@PreviewFeature is misleading, since like package deprecation, it's a 
no-op. However, a module being annotated with @PreviewFeature ought to 
have a visible effect if another module `requires` it. If Nikita puts 
Main.java in a module that `requires jdk.neshkeev`, then I'd expect a 
warning/error.

This thread is really about whether explicitly designating a module as a 
preview API implicitly designates every class within the module as a 
preview API. JEP 12 doesn't directly answer that question. It only says 
that every class within the preview module is "participating", and what 
happens if a class _explicitly_ designated as preview is used by other code.

The other way of asking the question is: Should a preview module be able 
to contain non-preview classes? (Where every preview class in the module 
would be marked with @PreviewFeature, and any class not so marked would 
be non-preview.)  First issue: you could "silently" use such non-preview 
classes from code on the classpath without a `requires` clause to 
trigger a warning/error for use of the preview module itself. This 
"silent" use feels undesirable, given the preview module's non-final 
status.  Second issue: preview classes and non-preview classes could 
live in the same package (since preview classes aren't forced into a 
dedicated namespace like incubating classes) -- that's legitimate when a 
few preview classes are added to a classic package in java.base, but we 
didn't really envisage a handful of non-preview classes hanging out in a 
vast crowd of preview classes in a preview module.

In sum, there's a strong case for saying that everything in a preview 
module has preview status. (Where marking anything in the module with 
@PreviewFeature is legal but redundant.) This would be convenient for 
preview API designers, who could write @PreviewFeature once and have it 
trickle down.

I suspect this is either very painful to implement in javac/javadoc, or 
very easy. Jan, please tell us which! :-)

Alex

>> On 2/3/2021 8:00 AM, Nikita Eshkeev wrote:
>>> The PreviewFeature 
>>> (https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java 
>>> <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java>) 
>>> annotation can be applied to modules and packages. But I don't get 
>>> any compile-time errors/warnings when I try to use code that is 
>>> inside of either a package or a module that is annotated with 
>>> PreviewFeature.
>>> What I did
>>> 1. I added a new module to openjdk with the "jdk.neshkeev" name
>>> 2. I added module-info.java, package-info.java and 
>>> MyPreviewClass.java (which is just an empty class)
>>> 3. I annotated both module-info.java and package-info.java with 
>>> PreviewFeature
>>> 4. I exported jdk.internal.javac package to jdk.neshkeev in 
>>> module-info.java of java.base
>>> 5. `make images` the jdk's source code
>>> 6. I created Main.java with the following content
>>> class Main {
>>> ??{
>>> ?? ?new jdk.neshkeev.MyPreviewClass();
>>> ??}
>>> }
>>> 7. I compiled Main.java with my openjdk that was built in the step 5.
>>> Here is the link to my openjdk fork with the jdk.neshkeev module: 
>>> https://github.com/neshkeev/jdk <https://github.com/neshkeev/jdk>
>>> What is expected
>>> Since MyPreviewClass is inside of the package that is annotated with 
>>> PreviewFeature and it is also inside of the module that is also 
>>> annotated with PreviewFeature I expect to get compile time 
>>> errors/warnings. I believe that compile-time errors/warnings should 
>>> arise since Main.java can't be considered as participating source code
>>> What happened
>>> No compile-time errors/warnings occurred
>>> Is this a bug?

From jwilhelm at openjdk.java.net  Thu Feb  4 01:24:02 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 4 Feb 2021 01:24:02 GMT
Subject: RFR: Merge jdk16
Message-ID: <L2_q8bEWe8cQRclrCLPoHGIKlEGdSGlG4MwTiMo9Oe4=.b41c5dbc-ca26-4e13-afdd-acaf1e8a4089@github.com>

Forwardport JDK 16 -> JDK 17

-------------

Commit messages:
 - Merge
 - 8259794: Remove EA from JDK 16 version string starting with Initial RC promotion on Feb 04, 2021(B35)
 - 8260704: ParallelGC: oldgen expansion needs release-store for _end
 - 8260927: StringBuilder::insert is incorrect without Compact Strings
 - 8258378: Final nroff manpage update for JDK 16
 - 8257215: JFR: Events dropped when streaming over a chunk rotation
 - 8260473: [vector] ZGC: VectorReshape test produces incorrect results with ZGC enabled
 - 8260632: Build failures after JDK-8253353
 - 8260339: JVM crashes when executing PhaseIdealLoop::match_fill_loop
 - 8260608: add a regression test for 8260370
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/f025bc1d...dad835ee

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=2392&range=00.0
 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=2392&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/2392/files
  Stats: 2645 lines in 56 files changed: 2497 ins; 69 del; 79 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2392.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2392/head:pull/2392

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

From jonathan.gibbons at oracle.com  Thu Feb  4 01:57:04 2021
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 3 Feb 2021 17:57:04 -0800
Subject: PreviewFeature on packages and modules
In-Reply-To: <5aa38fa0-0fd0-3efa-2d8b-72f7e4a2a4a6@oracle.com>
References: <222161612366851@mail.yandex.ru>
 <1e843faa-5884-ec9f-d01b-e34f71741551@oracle.com>
 <fb5edb89-42a9-276d-6cd1-ae8dac3e196d@oracle.com>
 <5aa38fa0-0fd0-3efa-2d8b-72f7e4a2a4a6@oracle.com>
Message-ID: <4c74222d-5753-50b4-a39e-813f2e26438d@oracle.com>


On 2/3/21 2:58 PM, Alex Buckley wrote:
> On 2/3/2021 1:30 PM, Jan Lahoda wrote:
>> One thing to note here is e.g. @Deprecated on a package does not 
>> automatically deprecate the classes belonging to the given package. 
>> Here, we have a package annotated with @PreviewFeature, but not a 
>> class annotated as a preview feature, and the preview flag is not 
>> propagated from packages to classes, similarly to the deprecated 
>> flag. But we can surely make this particular flag to propagate to the 
>> classes in the package, if desired.
>
> Thanks for the info. I agree that a package being annotated with 
> @PreviewFeature is misleading, since like package deprecation, it's a 
> no-op. However, a module being annotated with @PreviewFeature ought to 
> have a visible effect if another module `requires` it. If Nikita puts 
> Main.java in a module that `requires jdk.neshkeev`, then I'd expect a 
> warning/error.
>
> This thread is really about whether explicitly designating a module as 
> a preview API implicitly designates every class within the module as a 
> preview API. JEP 12 doesn't directly answer that question. It only 
> says that every class within the preview module is "participating", 
> and what happens if a class _explicitly_ designated as preview is used 
> by other code.
>
> The other way of asking the question is: Should a preview module be 
> able to contain non-preview classes? (Where every preview class in the 
> module would be marked with @PreviewFeature, and any class not so 
> marked would be non-preview.)? First issue: you could "silently" use 
> such non-preview classes from code on the classpath without a 
> `requires` clause to trigger a warning/error for use of the preview 
> module itself. This "silent" use feels undesirable, given the preview 
> module's non-final status.? Second issue: preview classes and 
> non-preview classes could live in the same package (since preview 
> classes aren't forced into a dedicated namespace like incubating 
> classes) -- that's legitimate when a few preview classes are added to 
> a classic package in java.base, but we didn't really envisage a 
> handful of non-preview classes hanging out in a vast crowd of preview 
> classes in a preview module.
>
> In sum, there's a strong case for saying that everything in a preview 
> module has preview status. (Where marking anything in the module with 
> @PreviewFeature is legal but redundant.) This would be convenient for 
> preview API designers, who could write @PreviewFeature once and have 
> it trickle down.
>
> I suspect this is either very painful to implement in javac/javadoc, 
> or very easy. Jan, please tell us which! :-)


I would expect this to be almost-zero cost in javadoc, since javadoc 
leverages javac.? For javac, I'll leave Jan to give the definitive 
answer, but I would expect it to be easy since every class knows its 
enclosing package and module.

-- Jon


>
> Alex
>
>>> On 2/3/2021 8:00 AM, Nikita Eshkeev wrote:
>>>> The PreviewFeature 
>>>> (https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java 
>>>> <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java>) 
>>>> annotation can be applied to modules and packages. But I don't get 
>>>> any compile-time errors/warnings when I try to use code that is 
>>>> inside of either a package or a module that is annotated with 
>>>> PreviewFeature.
>>>> What I did
>>>> 1. I added a new module to openjdk with the "jdk.neshkeev" name
>>>> 2. I added module-info.java, package-info.java and 
>>>> MyPreviewClass.java (which is just an empty class)
>>>> 3. I annotated both module-info.java and package-info.java with 
>>>> PreviewFeature
>>>> 4. I exported jdk.internal.javac package to jdk.neshkeev in 
>>>> module-info.java of java.base
>>>> 5. `make images` the jdk's source code
>>>> 6. I created Main.java with the following content
>>>> class Main {
>>>> ??{
>>>> ?? ?new jdk.neshkeev.MyPreviewClass();
>>>> ??}
>>>> }
>>>> 7. I compiled Main.java with my openjdk that was built in the step 5.
>>>> Here is the link to my openjdk fork with the jdk.neshkeev module: 
>>>> https://github.com/neshkeev/jdk <https://github.com/neshkeev/jdk>
>>>> What is expected
>>>> Since MyPreviewClass is inside of the package that is annotated 
>>>> with PreviewFeature and it is also inside of the module that is 
>>>> also annotated with PreviewFeature I expect to get compile time 
>>>> errors/warnings. I believe that compile-time errors/warnings should 
>>>> arise since Main.java can't be considered as participating source code
>>>> What happened
>>>> No compile-time errors/warnings occurred
>>>> Is this a bug?

From jwilhelm at openjdk.java.net  Thu Feb  4 02:09:40 2021
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 4 Feb 2021 02:09:40 GMT
Subject: Integrated: Merge jdk16
In-Reply-To: <L2_q8bEWe8cQRclrCLPoHGIKlEGdSGlG4MwTiMo9Oe4=.b41c5dbc-ca26-4e13-afdd-acaf1e8a4089@github.com>
References: <L2_q8bEWe8cQRclrCLPoHGIKlEGdSGlG4MwTiMo9Oe4=.b41c5dbc-ca26-4e13-afdd-acaf1e8a4089@github.com>
Message-ID: <9bIQlW7tZAt5i8quzTGD6Z6vHAG4-Q8-_saIecOJ4dM=.b1dacc8a-2678-417c-958b-650ff659723f@github.com>

On Thu, 4 Feb 2021 01:17:48 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: 9b7a8f19
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9b7a8f19
Stats:     2645 lines in 56 files changed: 2497 ins; 69 del; 79 mod

Merge

-------------

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

From ihse at openjdk.java.net  Thu Feb  4 10:17:59 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Feb 2021 10:17:59 GMT
Subject: RFR: 8261149: Initial nroff manpage update for JDK 17
Message-ID: <HvPsFX2azuvcaU5K-lTwixZ8Q8fYkTkJakELuAFVnVc=.56d0445a-74e3-48c6-824b-043a008610aa@github.com>

We need to regenerate the exported nroff man pages to include the proper version string. This will also bring in some recent textual updates to the man pages.

-------------

Commit messages:
 - 8261149: Initial nroff manpage update for JDK 17

Changes: https://git.openjdk.java.net/jdk/pull/2402/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2402&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261149
  Stats: 49 lines in 28 files changed: 0 ins; 21 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2402.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2402/head:pull/2402

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

From dholmes at openjdk.java.net  Thu Feb  4 12:25:04 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Thu, 4 Feb 2021 12:25:04 GMT
Subject: RFR: 8261149: Initial nroff manpage update for JDK 17
In-Reply-To: <HvPsFX2azuvcaU5K-lTwixZ8Q8fYkTkJakELuAFVnVc=.56d0445a-74e3-48c6-824b-043a008610aa@github.com>
References: <HvPsFX2azuvcaU5K-lTwixZ8Q8fYkTkJakELuAFVnVc=.56d0445a-74e3-48c6-824b-043a008610aa@github.com>
Message-ID: <63mJCmlChlanzUbpHIZVB-A5k9fpuoxB_wuWUWh4X3w=.ee0f50ac-c5c6-4e4c-9ac9-5644d752ab6a@github.com>

On Thu, 4 Feb 2021 10:13:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We need to regenerate the exported nroff man pages to include the proper version string. This will also bring in some recent textual updates to the man pages.

LGTM.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

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

From erikj at openjdk.java.net  Thu Feb  4 14:00:41 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 4 Feb 2021 14:00:41 GMT
Subject: RFR: 8261149: Initial nroff manpage update for JDK 17
In-Reply-To: <HvPsFX2azuvcaU5K-lTwixZ8Q8fYkTkJakELuAFVnVc=.56d0445a-74e3-48c6-824b-043a008610aa@github.com>
References: <HvPsFX2azuvcaU5K-lTwixZ8Q8fYkTkJakELuAFVnVc=.56d0445a-74e3-48c6-824b-043a008610aa@github.com>
Message-ID: <51s6LyOjlruKlam24RpMwUPMgI0KXr97j0O24UQy6cs=.ebb67cbf-523e-474a-9be8-1a166d1cf70a@github.com>

On Thu, 4 Feb 2021 10:13:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We need to regenerate the exported nroff man pages to include the proper version string. This will also bring in some recent textual updates to the man pages.

Marked as reviewed by erikj (Reviewer).

-------------

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

From ihse at openjdk.java.net  Thu Feb  4 14:40:42 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 4 Feb 2021 14:40:42 GMT
Subject: Integrated: 8261149: Initial nroff manpage update for JDK 17
In-Reply-To: <HvPsFX2azuvcaU5K-lTwixZ8Q8fYkTkJakELuAFVnVc=.56d0445a-74e3-48c6-824b-043a008610aa@github.com>
References: <HvPsFX2azuvcaU5K-lTwixZ8Q8fYkTkJakELuAFVnVc=.56d0445a-74e3-48c6-824b-043a008610aa@github.com>
Message-ID: <1eH5FM0wnnr5jAua6fWKyZ6De4pOpJAllvtAkBHAcyg=.954ff9dd-be33-413c-8b21-31f18b963754@github.com>

On Thu, 4 Feb 2021 10:13:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> We need to regenerate the exported nroff man pages to include the proper version string. This will also bring in some recent textual updates to the man pages.

This pull request has now been integrated.

Changeset: f7a6cff9
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f7a6cff9
Stats:     49 lines in 28 files changed: 0 ins; 21 del; 28 mod

8261149: Initial nroff manpage update for JDK 17

Reviewed-by: dholmes, erikj

-------------

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

From vromero at openjdk.java.net  Thu Feb  4 15:50:41 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 4 Feb 2021 15:50:41 GMT
Subject: RFR: 8260959: remove RECORDS from PreviewFeature.Feature enum
In-Reply-To: <sSZBW2qvql4zH4rQRECkRPHc_G9Fj2y737qf5x9IMns=.272968f6-b601-4226-ad4b-e955cd1e9fdd@github.com>
References: <AwCW8S7x-ls9hLA6AmLnkYLL6hcpSsGT_hEd5swj6n8=.4e4413d6-781a-4169-bf6b-bf592b76708b@github.com>
 <dhjquVIiIWSroAnH-fe1G4P3Jo_xbc-q-aAjk6K5B3E=.6004c3f4-477d-430a-ab9e-d31b445af2dd@github.com>
 <sSZBW2qvql4zH4rQRECkRPHc_G9Fj2y737qf5x9IMns=.272968f6-b601-4226-ad4b-e955cd1e9fdd@github.com>
Message-ID: <KigzZOCfpG6GmF25PAy7MaB4EpDTBL3hwp0nERgYNfk=.fd455c9a-263f-47f1-96bf-3a3825abc12d@github.com>

On Wed, 3 Feb 2021 01:37:28 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Given the scary comment and reference to JDK 15 and boot cycle builds, is it really safe to remove the constant?
>
> So currently, JDK 17 can be built with a boot JDK of 15, 16, or 17 (since JDK-8257459: "Bump minimum boot jdk to JDK 16") hasn't been fixed yet.
> 
> JDK 17 can currently be used as boot JDK only for itself, right? And in the future be used for JDK 18, and 19.

we already did a very similar fix for text blocks, so this patch is just doing the same for RECORDS

-------------

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

From jan.lahoda at oracle.com  Thu Feb  4 16:44:34 2021
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Thu, 4 Feb 2021 17:44:34 +0100
Subject: PreviewFeature on packages and modules
In-Reply-To: <5aa38fa0-0fd0-3efa-2d8b-72f7e4a2a4a6@oracle.com>
References: <222161612366851@mail.yandex.ru>
 <1e843faa-5884-ec9f-d01b-e34f71741551@oracle.com>
 <fb5edb89-42a9-276d-6cd1-ae8dac3e196d@oracle.com>
 <5aa38fa0-0fd0-3efa-2d8b-72f7e4a2a4a6@oracle.com>
Message-ID: <fcc30c53-624b-0e64-b87f-252dcf623493@oracle.com>

On 03. 02. 21 23:58, Alex Buckley wrote:

> On 2/3/2021 1:30 PM, Jan Lahoda wrote:
>> One thing to note here is e.g. @Deprecated on a package does not 
>> automatically deprecate the classes belonging to the given package. 
>> Here, we have a package annotated with @PreviewFeature, but not a 
>> class annotated as a preview feature, and the preview flag is not 
>> propagated from packages to classes, similarly to the deprecated 
>> flag. But we can surely make this particular flag to propagate to the 
>> classes in the package, if desired.
>
> Thanks for the info. I agree that a package being annotated with 
> @PreviewFeature is misleading, since like package deprecation, it's a 
> no-op. However, a module being annotated with @PreviewFeature ought to 
> have a visible effect if another module `requires` it. If Nikita puts 
> Main.java in a module that `requires jdk.neshkeev`, then I'd expect a 
> warning/error.
>
> This thread is really about whether explicitly designating a module as 
> a preview API implicitly designates every class within the module as a 
> preview API. JEP 12 doesn't directly answer that question. It only 
> says that every class within the preview module is "participating", 
> and what happens if a class _explicitly_ designated as preview is used 
> by other code.
>
> The other way of asking the question is: Should a preview module be 
> able to contain non-preview classes? (Where every preview class in the 
> module would be marked with @PreviewFeature, and any class not so 
> marked would be non-preview.)? First issue: you could "silently" use 
> such non-preview classes from code on the classpath without a 
> `requires` clause to trigger a warning/error for use of the preview 
> module itself. This "silent" use feels undesirable, given the preview 
> module's non-final status.? Second issue: preview classes and 
> non-preview classes could live in the same package (since preview 
> classes aren't forced into a dedicated namespace like incubating 
> classes) -- that's legitimate when a few preview classes are added to 
> a classic package in java.base, but we didn't really envisage a 
> handful of non-preview classes hanging out in a vast crowd of preview 
> classes in a preview module.
>
> In sum, there's a strong case for saying that everything in a preview 
> module has preview status. (Where marking anything in the module with 
> @PreviewFeature is legal but redundant.) This would be convenient for 
> preview API designers, who could write @PreviewFeature once and have 
> it trickle down.
>
> I suspect this is either very painful to implement in javac/javadoc, 
> or very easy. Jan, please tell us which! :-)


Propagating the preview flag from module to (top-level, presumably) 
classes seems to be fairly easy when compiling against classfiles. 
Propagating the flag from packages to classes would be more difficult, 
as the preview flag is commonly not read for packages - if we were to 
change that, we would need start reading all package-info.class files, 
with possible implications on performance.


Jan


>
> Alex
>
>>> On 2/3/2021 8:00 AM, Nikita Eshkeev wrote:
>>>> The PreviewFeature 
>>>> (https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java 
>>>> <https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java>) 
>>>> annotation can be applied to modules and packages. But I don't get 
>>>> any compile-time errors/warnings when I try to use code that is 
>>>> inside of either a package or a module that is annotated with 
>>>> PreviewFeature.
>>>> What I did
>>>> 1. I added a new module to openjdk with the "jdk.neshkeev" name
>>>> 2. I added module-info.java, package-info.java and 
>>>> MyPreviewClass.java (which is just an empty class)
>>>> 3. I annotated both module-info.java and package-info.java with 
>>>> PreviewFeature
>>>> 4. I exported jdk.internal.javac package to jdk.neshkeev in 
>>>> module-info.java of java.base
>>>> 5. `make images` the jdk's source code
>>>> 6. I created Main.java with the following content
>>>> class Main {
>>>> ??{
>>>> ?? ?new jdk.neshkeev.MyPreviewClass();
>>>> ??}
>>>> }
>>>> 7. I compiled Main.java with my openjdk that was built in the step 5.
>>>> Here is the link to my openjdk fork with the jdk.neshkeev module: 
>>>> https://github.com/neshkeev/jdk <https://github.com/neshkeev/jdk>
>>>> What is expected
>>>> Since MyPreviewClass is inside of the package that is annotated 
>>>> with PreviewFeature and it is also inside of the module that is 
>>>> also annotated with PreviewFeature I expect to get compile time 
>>>> errors/warnings. I believe that compile-time errors/warnings should 
>>>> arise since Main.java can't be considered as participating source code
>>>> What happened
>>>> No compile-time errors/warnings occurred
>>>> Is this a bug?

From jlahoda at openjdk.java.net  Thu Feb  4 17:01:42 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 4 Feb 2021 17:01:42 GMT
Subject: RFR: 8260959: remove RECORDS from PreviewFeature.Feature enum
In-Reply-To: <AwCW8S7x-ls9hLA6AmLnkYLL6hcpSsGT_hEd5swj6n8=.4e4413d6-781a-4169-bf6b-bf592b76708b@github.com>
References: <AwCW8S7x-ls9hLA6AmLnkYLL6hcpSsGT_hEd5swj6n8=.4e4413d6-781a-4169-bf6b-bf592b76708b@github.com>
Message-ID: <7AhP88PkqXq0JMgrqDY28xB6D5zOAowerLv8raLnPqY=.94a0a77d-2e5f-4dcf-91a7-1f231a3910df@github.com>

On Tue, 2 Feb 2021 18:33:18 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this simple fix that is removing the RECORDS enum constant from the PreviewFeature.Feature enum, now that RECORDS are final in 16 this constant can be safely removed.
> 
> Thanks,
> Vicente

I think that, in this specific case, we can remove the constant. The reason is that the PreviewFeature has been moved to a different package recently, so the JDK 15/16 versions of the API use the original PreviewFeature class, and should not produce any warnings. The builds look OK as well.

-------------

Marked as reviewed by jlahoda (Reviewer).

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

From alex.buckley at oracle.com  Thu Feb  4 17:53:57 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 4 Feb 2021 09:53:57 -0800
Subject: PreviewFeature on packages and modules
In-Reply-To: <fcc30c53-624b-0e64-b87f-252dcf623493@oracle.com>
References: <222161612366851@mail.yandex.ru>
 <1e843faa-5884-ec9f-d01b-e34f71741551@oracle.com>
 <fb5edb89-42a9-276d-6cd1-ae8dac3e196d@oracle.com>
 <5aa38fa0-0fd0-3efa-2d8b-72f7e4a2a4a6@oracle.com>
 <fcc30c53-624b-0e64-b87f-252dcf623493@oracle.com>
Message-ID: <87a3bd1c-2e51-181c-5631-f12e4ccedfc3@oracle.com>

On 2/4/2021 8:44 AM, Jan Lahoda wrote:
> On 03. 02. 21 23:58, Alex Buckley wrote:
>> In sum, there's a strong case for saying that everything in a preview 
>> module has preview status. (Where marking anything in the module with 
>> @PreviewFeature is legal but redundant.) This would be convenient for 
>> preview API designers, who could write @PreviewFeature once and have 
>> it trickle down.
>>
>> I suspect this is either very painful to implement in javac/javadoc, 
>> or very easy. Jan, please tell us which! :-)
> 
> Propagating the preview flag from module to (top-level, presumably) 
> classes seems to be fairly easy when compiling against classfiles. 
> Propagating the flag from packages to classes would be more difficult, 
> as the preview flag is commonly not read for packages - if we were to 
> change that, we would need start reading all package-info.class files, 
> with possible implications on performance.

Thanks Jan (and Jon). Propagating the preview flag from module to 
top-level classes is all that's required. I'm happy to cut packages out 
of the discussion completely, both for the reason you give and because 
package-level annotations were a mistake. (Sharp-eyed readers will 
notice that JLS 9.6.4.6 no longer mentions "package" as a program 
element that can be deprecated.)  If an API designer wishes to preview a 
new package, then every top-level class in the package will need to be 
flagged @PreviewFeature. JEP 12 can document all this after implementation.

Alex

From neshkeev at yandex.ru  Thu Feb  4 20:55:53 2021
From: neshkeev at yandex.ru (Nikita Eshkeev)
Date: Thu, 04 Feb 2021 23:55:53 +0300
Subject: PreviewFeature on packages and modules
In-Reply-To: <87a3bd1c-2e51-181c-5631-f12e4ccedfc3@oracle.com>
References: <222161612366851@mail.yandex.ru>
 <1e843faa-5884-ec9f-d01b-e34f71741551@oracle.com>
 <fb5edb89-42a9-276d-6cd1-ae8dac3e196d@oracle.com>
 <5aa38fa0-0fd0-3efa-2d8b-72f7e4a2a4a6@oracle.com>
 <fcc30c53-624b-0e64-b87f-252dcf623493@oracle.com>
 <87a3bd1c-2e51-181c-5631-f12e4ccedfc3@oracle.com>
Message-ID: <8159381612471997@iva7-56e9317134d0.qloud-c.yandex.net>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210204/a37fe4b0/attachment.htm>

From cushon at openjdk.java.net  Thu Feb  4 20:58:54 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Thu, 4 Feb 2021 20:58:54 GMT
Subject: RFR: 8261088: Repeatable annotations without @Target cannot have
 containers that target module declarations
Message-ID: <5aDBzJlzTWVrxfvLJfya21s-8t2j299igPflTCLRRHc=.bdd1767a-5cb7-4c65-be6c-292bb17ab418@github.com>

Please review this fix to consolidate handling of default `@Target`s for repeated annotations, and permit repeatable annotations without an `@Target` to have container annotations that explicitly target `MODULE`.

-------------

Commit messages:
 - 8261088: Repeatable annotations without @Target cannot have containers that target module declarations

Changes: https://git.openjdk.java.net/jdk/pull/2412/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2412&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261088
  Stats: 88 lines in 4 files changed: 66 ins; 16 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2412.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2412/head:pull/2412

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

From cushon at openjdk.java.net  Thu Feb  4 21:07:40 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Thu, 4 Feb 2021 21:07:40 GMT
Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation
 type
In-Reply-To: <AMFQBSUNCfPhqXJV_sFSoZKdkrdTHEl_kG5aSFP1Jbc=.aa266fbf-3662-497b-9dc0-6e093d25fc85@github.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
 <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
 <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>
 <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com>
 <PEhAZNV434d5RP5m0cH5X5MvUv8tmg-TuPfM1eFqtOQ=.e1483dc5-9c8d-4282-82dc-0d264c7c646d@github.com>
 <AMFQBSUNCfPhqXJV_sFSoZKdkrdTHEl_kG5aSFP1Jbc=.aa266fbf-3662-497b-9dc0-6e093d25fc85@github.com>
Message-ID: <-JJzDCYUAtnxPkJJ67a45ehz6SN8FEJn6vubpKwThTQ=.7c25c4c9-fbf8-42ea-8690-2cc40b56223d@github.com>

On Wed, 3 Feb 2021 18:20:15 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Maybe we should collect the concrete information about this problem. Here are some materials that I know.
>> 
>> Order by time:
>> - 2019.08 **Werner Dietl** launched the discussion. [1]
>> - 2019.09 After the discussion between **Alex Buckley** and **Michael Ernst**, an initiative result came out.[2]
>> - 2019.09 Two JBS issues were filed. [3][4]
>> - 2019.12 **Alex Buckley** fixed the JLS(fix version: 14). But the compiler code and javadoc were not fixed. [5][6]
>> - 2020.10 **Christian Stein** created another issue about it. [7]
>> - 2020.10 **Guoxiong Li**(me) submitted a PR about it in Github. [8]
>> - 2020.10 **Joel Borggr?n-Franck** restarted the discussion about the specification. [9]
>> - 2020.12 Because the JDK16 was nearly at RDP1, we decided to only fix JDK-8254023. And other work left to JDk17.  [7][10][11]
>> - 2020.12 The issue JDK-8254023 was fixed at JDK16. [7][8][12]
>> - **Now, we need to discuss the problem(unify the specification, implement and javadoc) that JDK16 has left.**[11]
>> 
>> [1] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-August/013666.html
>> [2] https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013705.html
>> [3] https://bugs.openjdk.java.net/browse/JDK-8231435
>> [4] https://bugs.openjdk.java.net/browse/JDK-8231436
>> [5] https://docs.oracle.com/javase/specs/jls/se14/html/jls-9.html#jls-9.6.4.1
>> [6] https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/annotation/Target.html
>> [7] https://bugs.openjdk.java.net/browse/JDK-8254023
>> [8] https://github.com/openjdk/jdk/pull/622
>> [9] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015197.html
>> [10] http://openjdk.java.net/projects/jdk/16/
>> [11] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015503.html
>> [12] https://github.com/openjdk/jdk16/pull/34
>
> Thanks, I was missing context here. I now realize this patch is fixing a bug related to [JDK-8254023](https://bugs.openjdk.java.net/browse/JDK-8254023)--when the handling of annotations without `@Target` was updated to allow them to be applied to module declarations, the handling of repeatable annotations without `@Target` should also have been updated. I filed a new bug for the sub-issue that this patch is fixing, and will update it accordingly in a minute: https://bugs.openjdk.java.net/browse/JDK-8261088
> 
> I'm also happy to help with any work to be done on the larger question of interpreting `@Target`-less annotations as applicable to type contexts, if there's agreement about what to do there.

I spun the original change that related specifically to repeatable annotations and `@Target(MODULE)` out into https://github.com/openjdk/jdk/pull/2412 and filed corresponding CSR [JDK-8261181](https://bugs.openjdk.java.net/browse/JDK-8261181).

I will look at updating this review to actually implement the change to make no-`@Target` annotations applicable to all contexts next.

-------------

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

From alex.buckley at oracle.com  Thu Feb  4 21:47:05 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 4 Feb 2021 13:47:05 -0800
Subject: PreviewFeature on packages and modules
In-Reply-To: <87a3bd1c-2e51-181c-5631-f12e4ccedfc3@oracle.com>
References: <222161612366851@mail.yandex.ru>
 <1e843faa-5884-ec9f-d01b-e34f71741551@oracle.com>
 <fb5edb89-42a9-276d-6cd1-ae8dac3e196d@oracle.com>
 <5aa38fa0-0fd0-3efa-2d8b-72f7e4a2a4a6@oracle.com>
 <fcc30c53-624b-0e64-b87f-252dcf623493@oracle.com>
 <87a3bd1c-2e51-181c-5631-f12e4ccedfc3@oracle.com>
Message-ID: <7c82a01d-034f-3d25-a214-62d044facc63@oracle.com>

On 2/4/2021 9:53 AM, Alex Buckley wrote:
> Thanks Jan (and Jon). Propagating the preview flag from module to 
> top-level classes is all that's required. I'm happy to cut packages out 
> of the discussion completely, both for the reason you give and because 
> package-level annotations were a mistake. (Sharp-eyed readers will 
> notice that JLS 9.6.4.6 no longer mentions "package" as a program 
> element that can be deprecated.)? If an API designer wishes to preview a 
> new package, then every top-level class in the package will need to be 
> flagged @PreviewFeature. JEP 12 can document all this after implementation.

We should probably switch "top-level classes" to "public classes, 
whether top level or nested". The preview module might not export a 
package, in which case it doesn't matter that we treat the package's 
public classes as preview (since they're inaccessible); but if the 
preview module does export a package, then we should recognize its 
public nested classes as part of the API alongside its public top level 
classes (consider j.l.i.MethodHandles.Lookup).

Alex

From alex.buckley at oracle.com  Thu Feb  4 21:55:42 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 4 Feb 2021 13:55:42 -0800
Subject: [External] : Re: PreviewFeature on packages and modules
In-Reply-To: <8159381612471997@iva7-56e9317134d0.qloud-c.yandex.net>
References: <222161612366851@mail.yandex.ru>
 <1e843faa-5884-ec9f-d01b-e34f71741551@oracle.com>
 <fb5edb89-42a9-276d-6cd1-ae8dac3e196d@oracle.com>
 <5aa38fa0-0fd0-3efa-2d8b-72f7e4a2a4a6@oracle.com>
 <fcc30c53-624b-0e64-b87f-252dcf623493@oracle.com>
 <87a3bd1c-2e51-181c-5631-f12e4ccedfc3@oracle.com>
 <8159381612471997@iva7-56e9317134d0.qloud-c.yandex.net>
Message-ID: <f9840746-bdd8-5bd2-d208-9591c39d5892@oracle.com>

That text would be corrected to clarify that adding a package 
java.io.fast as a preview API in java.base (a perfectly good concept) 
means the API designer has to flag classes in the package as preview 
APIs (due to how @PreviewFeature is interpreted); and that _all_ classes 
in the package (top level or nested; public or private) are 
"participating". A private nested helper class should obviously be able 
to refer to the in-preview public entrypoints of the API without 
warning/error.

Alex

On 2/4/2021 12:55 PM, Nikita Eshkeev wrote:
> Will JEP lose this part about packages:
> 
>  > For example, if a package java.io.fast is introduced as a preview 
> API, then all of the code in the package would be "participating" and 
> would not generate errors/warnings when referring to the package's own 
> types.
> 
> ?
> 
> 
> 04.02.2021, 20:56, "Alex Buckley" <alex.buckley at oracle.com>:
> 
>     On 2/4/2021 8:44 AM, Jan Lahoda wrote:
> 
>          ?On 03. 02. 21 23:58, Alex Buckley wrote:
> 
>              ?In sum, there's a strong case for saying that everything
>             in a preview
>              ?module has preview status. (Where marking anything in the
>             module with
>              ?@PreviewFeature is legal but redundant.) This would be
>             convenient for
>              ?preview API designers, who could write @PreviewFeature
>             once and have
>              ?it trickle down.
> 
>              ?I suspect this is either very painful to implement in
>             javac/javadoc,
>              ?or very easy. Jan, please tell us which! :-)
> 
> 
>          ?Propagating the preview flag from module to (top-level,
>         presumably)
>          ?classes seems to be fairly easy when compiling against
>         classfiles.
>          ?Propagating the flag from packages to classes would be more
>         difficult,
>          ?as the preview flag is commonly not read for packages - if we
>         were to
>          ?change that, we would need start reading all
>         package-info.class files,
>          ?with possible implications on performance.
> 
> 
>     Thanks Jan (and Jon). Propagating the preview flag from module to
>     top-level classes is all that's required. I'm happy to cut packages out
>     of the discussion completely, both for the reason you give and because
>     package-level annotations were a mistake. (Sharp-eyed readers will
>     notice that JLS 9.6.4.6 no longer mentions "package" as a program
>     element that can be deprecated.) If an API designer wishes to preview a
>     new package, then every top-level class in the package will need to be
>     flagged @PreviewFeature. JEP 12 can document all this after
>     implementation.
> 
>     Alex
> 
> 
> 
> 

From jjg at openjdk.java.net  Thu Feb  4 22:53:41 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 4 Feb 2021 22:53:41 GMT
Subject: RFR: JDK-8257925 enable more support for nested inline tags
In-Reply-To: <5_La30de_lNBPbWoO87kN2bBkdbeUnHJPrf83dXsZvg=.5e41c94a-05a7-4e18-9488-bfbf982ba87f@github.com>
References: <8ywNfJMqNdrdBT2BZb52mnwOVO1sHm2gbpYPGVCH6Ss=.a21bd47b-c78f-466e-b936-2518c3d0a54c@github.com>
 <5_La30de_lNBPbWoO87kN2bBkdbeUnHJPrf83dXsZvg=.5e41c94a-05a7-4e18-9488-bfbf982ba87f@github.com>
Message-ID: <ifS7QRlq5zuDKP4H68BHsnOFTrDRy0kxQ-6B0H-bVwI=.46c3d98f-8cfd-46db-82ba-d04e20f193ec@github.com>

On Wed, 3 Feb 2021 12:28:06 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> I wouldn't expect that latter behavior. Not only nested `<a>` are invalid HTML, but they are also rendered strangely in browsers. In this particular case the trailing `GHI` appears as normal text, not as a hyperlink.

Thanks; it was on my list to check whether nested links were allowed. I'm pleased they're not, and this will be another situation where the `inTags` info is useful.

-------------

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

From jjg at openjdk.java.net  Fri Feb  5 04:44:07 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 5 Feb 2021 04:44:07 GMT
Subject: RFR: JDK-8257925 enable more support for nested inline tags [v2]
In-Reply-To: <8ywNfJMqNdrdBT2BZb52mnwOVO1sHm2gbpYPGVCH6Ss=.a21bd47b-c78f-466e-b936-2518c3d0a54c@github.com>
References: <8ywNfJMqNdrdBT2BZb52mnwOVO1sHm2gbpYPGVCH6Ss=.a21bd47b-c78f-466e-b936-2518c3d0a54c@github.com>
Message-ID: <K6eWyz_Yv4KOTYXkhhYrxFly4avZ9vummGvKPcrplI4=.22c9896d-b887-4a35-a3e4-cb9aa23c1cb3@github.com>

> Please review an update to improve the support, where appropriate, for nested inline tags. 
> 
> It has always been the case that certain inline tags allow text and HTML to appear within them. With tags like `{@return}` and `{@summary}` it becomes desirable to also generally allow nested inline tags to appear in those places as well. The work for this was started with the support for `{@return}` [JDK-8075778](https://bugs.openjdk.java.net/browse/JDK-8075778), but applying the work more generally was out of scope at the time. This change completes the work that was started then.
> 
> The work can be grouped into 4 parts, in 3 commits.
> 
> ## Commit 1
> 
> * Update `DocCommentParser` to syntactically allow nested inline tags in situations that permit text and HTML
> * Update the downstream code to semantically limit nestg where it does not make sense, and provide new tests to verify the behavior.
> 
> A family of new tests are added, each testing the ability to put an inline tag within another of the same kind, with and without doclint being enabled. In addition, test cases are added placing a simple instance `{@value}` in an enclosing tag: this is a useful case just because the expansion is plain text and therefore valid in all situations.  Additional tests and test cases can be added as needed.
> 
> This commit left the `{@index}` tag generating "bad" code when it was nested. The error was "reference to an undeclared ID". The (temporary) solution was to disable the automatic link checking for this specific subtest.
> 
> ## Commit 2
> 
> * `HtmlDocletWriter` and `TagletWriterImpl ` pass around a pair of booleans `isFirstSentence` and `inSummary` to help determine the output to be generated. Conceptually, a third value is added to that group: a set containing the set of nested tag kinds, so that it is possible to determine the enclosing tags for a tag.  But, rather than add a third parameter to be passed around, the 3 are grouped into a new class `TagletWriterImpl.Context` which encapsulates the two booleans and the new set.  The new class is added in a way to minimize code churn.  No tests are affected by this change: all continue to pass.
> 
> ## Commit 3
> 
> * The new `Context#inTags` field is used to help improve the behavior of nested `{@index}` tags even when used incorrectly, with warnings disabled.  As a result, the temporary change in the first commit to disable automatic link checking in one of the test cases is reverted.
> 
> <hr>
> 
> The introduction of the new Context class is arguably more general than we need at this time, but it clears up some erratic and inconsistent use of the `isFirstSentence` and `inSummary` booleans. The new class also provides a better framework for any complex new inline tags we may add in future. We might want to change the `Set<DocTree.Kind>` to some other collection at some point, if needs be (a stack, for example.) We might also want to move more information into the `Context`, such as the related `Element` that is otherwise ubiquitously passed around.
> 
> The overall cleanup also revealed some latent bugs in the code, that were hidden in some of the tests. Most notable was that there were still some cases were `<` and `>` were not being correctly escaped as `&lt;` and `&gt;` leading to output in some tests of the form `List<String>` !  This triggered a minor cleanup/rewrite of the beginning of `HtmlDocletWriter.seeTagsToContent` which was previously a bit too liberal with the use of `new RawHtml`!  The other minor cleanup was more consistent handling of whitespace at the end of the first sentence, as will be seen in a couple of places in one of the tests that was updated.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  improve handling of nested links

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2369/files
  - new: https://git.openjdk.java.net/jdk/pull/2369/files/bd84b5dd..96bfeb59

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

  Stats: 17 lines in 3 files changed: 13 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2369.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2369/head:pull/2369

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

From cushon at openjdk.java.net  Fri Feb  5 08:15:01 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Fri, 5 Feb 2021 08:15:01 GMT
Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation
 type
In-Reply-To: <-JJzDCYUAtnxPkJJ67a45ehz6SN8FEJn6vubpKwThTQ=.7c25c4c9-fbf8-42ea-8690-2cc40b56223d@github.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
 <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
 <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>
 <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com>
 <PEhAZNV434d5RP5m0cH5X5MvUv8tmg-TuPfM1eFqtOQ=.e1483dc5-9c8d-4282-82dc-0d264c7c646d@github.com>
 <AMFQBSUNCfPhqXJV_sFSoZKdkrdTHEl_kG5aSFP1Jbc=.aa266fbf-3662-497b-9dc0-6e093d25fc85@github.com>
 <-JJzDCYUAtnxPkJJ67a45ehz6SN8FEJn6vubpKwThTQ=.7c25c4c9-fbf8-42ea-8690-2cc40b56223d@github.com>
Message-ID: <clkXPwj-Xahr6Rzgiov-jmNuR8K2nebbRMMGwOkuh2A=.9fd334ba-c8a5-4de6-a7b9-dbd0fe33f9c4@github.com>

On Thu, 4 Feb 2021 21:04:51 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Thanks, I was missing context here. I now realize this patch is fixing a bug related to [JDK-8254023](https://bugs.openjdk.java.net/browse/JDK-8254023)--when the handling of annotations without `@Target` was updated to allow them to be applied to module declarations, the handling of repeatable annotations without `@Target` should also have been updated. I filed a new bug for the sub-issue that this patch is fixing, and will update it accordingly in a minute: https://bugs.openjdk.java.net/browse/JDK-8261088
>> 
>> I'm also happy to help with any work to be done on the larger question of interpreting `@Target`-less annotations as applicable to type contexts, if there's agreement about what to do there.
>
> I spun the original change that related specifically to repeatable annotations and `@Target(MODULE)` out into https://github.com/openjdk/jdk/pull/2412 and filed corresponding CSR [JDK-8261181](https://bugs.openjdk.java.net/browse/JDK-8261181).
> 
> I will look at updating this review to actually implement the change to make no-`@Target` annotations applicable to all contexts next.

I pushed an initial implementation of a fix to make no-`@Target` annotation applicable in all contexts, including type contexts.

I have updated affected tier 1 langtools tests, which provides some signal about the compatibility impact. That also uncovered a couple of bugs: one issue where javadoc isn't escaping type annotations in html ([JDK-8261203](https://bugs.openjdk.java.net/browse/JDK-8261203)), and a crash with intersection types and LVTI ([JDK-8261205](https://bugs.openjdk.java.net/browse/JDK-8261205)).

-------------

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

From cushon at openjdk.java.net  Fri Feb  5 08:15:00 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Fri, 5 Feb 2021 08:15:00 GMT
Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation
 type [v2]
In-Reply-To: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
Message-ID: <W54vDvW5oyROWOAykppudCRIG0mz5n3HDLbFCSjEguM=.39aed21d-ed61-42d0-ae9e-1ee43898af92@github.com>

> Please review this fix to add `ElementType.MODULE` to the default list of annotation targets, to allow annotations without an explicit `@Target` to be used on module declarations.

Liam Miller-Cushon 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:

  8231436: Fix the applicability of a no- at Target annotation type

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2303/files
  - new: https://git.openjdk.java.net/jdk/pull/2303/files/b0d6abbc..7e1c404d

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

  Stats: 191 lines in 36 files changed: 115 ins; 36 del; 40 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2303.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2303/head:pull/2303

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

From jan.lahoda at oracle.com  Fri Feb  5 10:55:43 2021
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 5 Feb 2021 11:55:43 +0100
Subject: PreviewFeature on packages and modules
In-Reply-To: <7c82a01d-034f-3d25-a214-62d044facc63@oracle.com>
References: <222161612366851@mail.yandex.ru>
 <1e843faa-5884-ec9f-d01b-e34f71741551@oracle.com>
 <fb5edb89-42a9-276d-6cd1-ae8dac3e196d@oracle.com>
 <5aa38fa0-0fd0-3efa-2d8b-72f7e4a2a4a6@oracle.com>
 <fcc30c53-624b-0e64-b87f-252dcf623493@oracle.com>
 <87a3bd1c-2e51-181c-5631-f12e4ccedfc3@oracle.com>
 <7c82a01d-034f-3d25-a214-62d044facc63@oracle.com>
Message-ID: <bf40525a-317c-e491-a36e-ee9225b05045@oracle.com>

On 04. 02. 21 22:47, Alex Buckley wrote:

> On 2/4/2021 9:53 AM, Alex Buckley wrote:
>> Thanks Jan (and Jon). Propagating the preview flag from module to 
>> top-level classes is all that's required. I'm happy to cut packages 
>> out of the discussion completely, both for the reason you give and 
>> because package-level annotations were a mistake. (Sharp-eyed readers 
>> will notice that JLS 9.6.4.6 no longer mentions "package" as a 
>> program element that can be deprecated.)? If an API designer wishes 
>> to preview a new package, then every top-level class in the package 
>> will need to be flagged @PreviewFeature. JEP 12 can document all this 
>> after implementation.
>
> We should probably switch "top-level classes" to "public classes, 
> whether top level or nested". The preview module might not export a 
> package, in which case it doesn't matter that we treat the package's 
> public classes as preview (since they're inaccessible); but if the 
> preview module does export a package, then we should recognize its 
> public nested classes as part of the API alongside its public top 
> level classes (consider j.l.i.MethodHandles.Lookup).


I'd point out it is not easy to refer to a nested class without first 
referring to the enclosing class (could happen e.g. when the code can 
refer to the nested class using simple name e.g. due to inheritance). 
And showing warnings on both the enclosing and nested class may be 
discouraging.


But there is a possibly bigger question: if we copy the flags from 
modules to nested classes, should we copy them from preview classes (in 
non-preview modules) to their nested classes? Or from preview classes to 
their members and constructors? (This is very unlike e.g. deprecation, 
which does not copy the flag to any enclosed element, AFAIK.)


Jan


>
> Alex

From joel.p.borggren-franck at oracle.com  Fri Feb  5 14:44:42 2021
From: joel.p.borggren-franck at oracle.com (Joel Borggren-Franck)
Date: Fri, 5 Feb 2021 14:44:42 +0000
Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation
 type
In-Reply-To: <3d96a404-9bca-97d7-47fc-2de3c6af8726@oracle.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
 <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
 <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>
 <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com>
 <PEhAZNV434d5RP5m0cH5X5MvUv8tmg-TuPfM1eFqtOQ=.e1483dc5-9c8d-4282-82dc-0d264c7c646d@github.com>
 <54e81069-d66b-d466-77eb-a425ff4ee336@oracle.com>
 <C0E0B8F2-0E5D-4DED-87AE-8D15B39CA372@oracle.com>
 <3d96a404-9bca-97d7-47fc-2de3c6af8726@oracle.com>
Message-ID: <16C4FF5C-7F03-4002-A35E-3A3AC3F4EFAB@oracle.com>

Hi,

Some comments inline,

> On 3 Feb 2021, at 19:39, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> Let me focus first on the design question of what a no- at Target annotation type "means". There's no particular reason why it _shouldn't_ mean "all contexts". Mike gave good reasons why it should mean that. For the corner case of an annotation appearing in one of the ambiguous locations in source code, the annotation will appear in the class file/via reflection exactly as if someone had taken the perfectly legitimate course of spelling out @Target({METHOD, TYPE_USE}) -- the no- at Target case is not a secret door to behavior that's otherwise impossible or undesirable.
> 

I agree that had we done this in one go from scratch, it seems likely that the ?all contexts? default for no- at Target annotation would have been chosen.


> (We could have said "all contexts" for a no- at Target annotation type but then added a rule in 9.7.4 to special-case a no- at Target annotation that appears in an ambiguous location, e.g., to compile the annotation as if it was applicable only in declaration contexts. More compatibility with SE 8, but more complexity, and I don't think anyone really wants that.)

FYI this is what ecj does. They allow all contexts but don?t generate type annotation attributes from the ambiguous contexts.

> Turning to the compatibility concern: yes, JDK-8231435 shouldn't have claimed behavioral compatibility. It was my error to not recognize what Mike was saying in "It is a behavior change from the current specification, but a small one that affects poorly-written programs that have no @Target meta-annotation." Still, at the end of the day, it's no more than a small behavioral incompatibility for annotation processors (they may see more type annotations than they did before), and one which was within the power of the annotation type's owner to induce anyway (annotation processors that look for type annotations can reasonably be expected to ignore type annotations in places they don't care about).
> 
> I have cc'd Mike in case he wants to add anything further, but the design intent of "all contexts" still looks reasonable to me.
> 

In isolation yes, ?all contexts? makes sense, but so does ?all declaration contexts?. What worries me here is that we change the semantics of programs written as far back as 2004. While I don?t think this is an absolute no, we shouldn?t do this lightly, the gain should be substantial, and the risk well quantified. One aspect here is that while annotation interface declarations without @Target might very well be poorly written, it is/was still the only way to specify "all current and future declaration targets?, it is/was also the only alternative with some brevity to specify all current declaration contexts, the alternative being to type out 9 ElementTypes.

An alternative would be to adopt your original proposal, ?all current and future declaration contexts?, and adding an ElementType corresponding to this default. This way the question ?where are annotations applicable?? would be solved, the user can easily and with brevity opt in to all contexts by using something like ?@Target({DECLARATIONS, TYPE_USE})" and the backward compatibility risk is lower. The downside is It would mean more work for us in implementing this.

cheers
/Joel

From alex.buckley at oracle.com  Fri Feb  5 20:14:48 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 5 Feb 2021 12:14:48 -0800
Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation
 type
In-Reply-To: <16C4FF5C-7F03-4002-A35E-3A3AC3F4EFAB@oracle.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
 <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
 <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>
 <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com>
 <PEhAZNV434d5RP5m0cH5X5MvUv8tmg-TuPfM1eFqtOQ=.e1483dc5-9c8d-4282-82dc-0d264c7c646d@github.com>
 <54e81069-d66b-d466-77eb-a425ff4ee336@oracle.com>
 <C0E0B8F2-0E5D-4DED-87AE-8D15B39CA372@oracle.com>
 <3d96a404-9bca-97d7-47fc-2de3c6af8726@oracle.com>
 <16C4FF5C-7F03-4002-A35E-3A3AC3F4EFAB@oracle.com>
Message-ID: <fd25d05c-a344-3451-774e-099ddc302646@oracle.com>

On 2/5/2021 6:44 AM, Joel Borggren-Franck wrote:
> In isolation yes, ?all contexts? makes sense, but so does ?all
> declaration contexts?. What worries me here is that we change the
> semantics of programs written as far back as 2004. While I don?t
> think this is an absolute no, we shouldn?t do this lightly, the gain
> should be substantial, and the risk well quantified. One aspect here
> is that while annotation interface declarations without @Target might
> very well be poorly written, it is/was still the only way to specify
> "all current and future declaration targets?, it is/was also the only
> alternative with some brevity to specify all current declaration
> contexts, the alternative being to type out 9 ElementTypes.

The original meaning of no- at Target in 2004 was open-ended, the "all 
contexts" of its day -- "If a Target meta-annotation is not present on 
an annotation type declaration, the declared type may be used on any 
program element."

When Java 8 added annotations on declarations of type parameters (a 
declaration context overlooked by Java 5, and addressed by JSR 308), we 
should arguably have thrown that new declaration context into the "all 
contexts" pot from Java 5 and leveraged Java 8's richer terminology to 
state the meaning of no- at Target as "all declaration contexts". We didn't 
do that out of an abundance of caution, not wanting to change the 
semantics of programs written back to 2004. Instead, we gave what I now 
regard as undue weight to what was important in 2012: Java 7's 
locations, a.k.a. Java 5's locations. This led to a weird 
backward-looking policy that does poorly when new declaration contexts 
(MODULE, RECORD_COMPONENT) are added.

I think your dislike of no- at Target meaning "all contexts" is not that it 
includes type contexts as such, but rather that when it meets the corner 
case of ambiguous locations, it causes some annotations to be written 
into the class file twice. If the corner case somehow didn't exist, I 
think you would appreciate the brevity of being able to get all 
declaration contexts without spelling out nine targets, and you just 
wouldn't think about the type contexts coming along for the ride.

The corner case is a fact of Java life (and I might even concede it's 
larger than a corner case, given the prominence of the ambiguous 
locations), but I don't want it to dominate the decision about the 
meaning of no- at Target. The simplicity of "all contexts" was appealing in 
2004 and it's appealing in 2021. The cost of carelessly omitting @Target 
was _always_ that an annotation processor might see @Foo in locations it 
didn't expect as Java evolved, and now there may be some class file 
overhead too. The power to avoid surprises is entirely in the hands of 
Foo's owner -- they're declaring what looks like an API but is really a 
new modifier for Java programs, so they ought to be concerned with how 
their annotations affect user code.

Encouraging the owner to specify @Target by offering an 
ElementType.DECLARATIONS constant that means "all [current and future] 
declaration contexts" is a good idea, balancing how ElementType.TYPE_USE 
means "all [current and future] type contexts".

(In Java 15, TYPE_USE implied 16 type contexts; in Java 16, TYPE_USE 
implies 17 type contexts, the addition being the type in a record 
component declaration. Open-ended rules work! They embody "lumping, not 
splitting".)

Alex

> An alternative would be to adopt your original proposal, ?all current
> and future declaration contexts?, and adding an ElementType
> corresponding to this default. This way the question ?where are
> annotations applicable?? would be solved, the user can easily and
> with brevity opt in to all contexts by using something like
> ?@Target({DECLARATIONS, TYPE_USE})" and the backward compatibility
> risk is lower. The downside is It would mean more work for us in
> implementing this.
> 
> cheers /Joel

From alex.buckley at oracle.com  Fri Feb  5 20:55:20 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 5 Feb 2021 12:55:20 -0800
Subject: PreviewFeature on packages and modules
In-Reply-To: <bf40525a-317c-e491-a36e-ee9225b05045@oracle.com>
References: <222161612366851@mail.yandex.ru>
 <1e843faa-5884-ec9f-d01b-e34f71741551@oracle.com>
 <fb5edb89-42a9-276d-6cd1-ae8dac3e196d@oracle.com>
 <5aa38fa0-0fd0-3efa-2d8b-72f7e4a2a4a6@oracle.com>
 <fcc30c53-624b-0e64-b87f-252dcf623493@oracle.com>
 <87a3bd1c-2e51-181c-5631-f12e4ccedfc3@oracle.com>
 <7c82a01d-034f-3d25-a214-62d044facc63@oracle.com>
 <bf40525a-317c-e491-a36e-ee9225b05045@oracle.com>
Message-ID: <4244c562-f8e8-4ac3-37a8-94d9ed8f3aec@oracle.com>

On 2/5/2021 2:55 AM, Jan Lahoda wrote:
>> On 2/4/2021 9:53 AM, Alex Buckley wrote:
>> We should probably switch "top-level classes" to "public classes, 
>> whether top level or nested". The preview module might not export a 
>> package, in which case it doesn't matter that we treat the package's 
>> public classes as preview (since they're inaccessible); but if the 
>> preview module does export a package, then we should recognize its 
>> public nested classes as part of the API alongside its public top 
>> level classes (consider j.l.i.MethodHandles.Lookup).
> 
> I'd point out it is not easy to refer to a nested class without first 
> referring to the enclosing class (could happen e.g. when the code can 
> refer to the nested class using simple name e.g. due to inheritance). 

I'm completely with you. My concern is that if JEP 12 focuses on 
[public] _top level_ classes in [an exported package of] a preview 
module, then Nikita will be along two minutes later to ask if [public] 
nested classes inside those top level classes are preview APIs too. The 
answer is "yes", so in some sense the [public] nested classes should be 
treated as having @PreviewFeature too. (Please don't respond yet. Please 
keep reading.)

> And showing warnings on both the enclosing and nested class may be 
> discouraging.

Again, you're right, and javac as a quality-of-implementation matter 
could choose to give only a warning for the enclosing class name.

> But there is a possibly bigger question: if we copy the flags from 
> modules to nested classes, should we copy them from preview classes (in 
> non-preview modules) to their nested classes? Or from preview classes to 
> their members and constructors? (This is very unlike e.g. deprecation, 
> which does not copy the flag to any enclosed element, AFAIK.)

Yes, we were heading for this question regardless of Nikita's question 
about packages and modules. Conceptually, putting @PreviewFeature on a 
top level class means that all of its public members and ctors are a 
preview API. Practically, I agree with your earlier comment that it's 
hard to use a member without using the enclosing class name. So, while 
JEP 12 will clarify that a preview module causes all its accessible 
public classes (top level or nested) to be in preview, I think javac 
need only copy preview status from module to top level classes in order 
to tell clients what they're using.

Alex

From cushon at google.com  Sat Feb  6 00:18:53 2021
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 5 Feb 2021 16:18:53 -0800
Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation
 type
In-Reply-To: <fd25d05c-a344-3451-774e-099ddc302646@oracle.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
 <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
 <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>
 <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com>
 <PEhAZNV434d5RP5m0cH5X5MvUv8tmg-TuPfM1eFqtOQ=.e1483dc5-9c8d-4282-82dc-0d264c7c646d@github.com>
 <54e81069-d66b-d466-77eb-a425ff4ee336@oracle.com>
 <C0E0B8F2-0E5D-4DED-87AE-8D15B39CA372@oracle.com>
 <3d96a404-9bca-97d7-47fc-2de3c6af8726@oracle.com>
 <16C4FF5C-7F03-4002-A35E-3A3AC3F4EFAB@oracle.com>
 <fd25d05c-a344-3451-774e-099ddc302646@oracle.com>
Message-ID: <CAL4QsgsqX9Sj+AwoLAAy=+7hx__wHU6VhHjNocWrEUwM4HnZxw@mail.gmail.com>

On Fri, Feb 5, 2021 at 6:45 AM Joel Borggren-Franck <
joel.p.borggren-franck at oracle.com> wrote:

> An alternative would be to adopt your original proposal, ?all current and
> future declaration contexts?, and adding an ElementType corresponding to
> this default. This way the question ?where are annotations applicable??
> would be solved, the user can easily and with brevity opt in to all
> contexts by using something like ?@Target({DECLARATIONS, TYPE_USE})" and
> the backward compatibility risk is lower. The downside is It would mean
> more work for us in implementing this.


On Fri, Feb 5, 2021 at 12:15 PM Alex Buckley <alex.buckley at oracle.com>
wrote:

> Encouraging the owner to specify @Target by offering an
> ElementType.DECLARATIONS constant that means "all [current and future]
> declaration contexts" is a good idea, balancing how ElementType.TYPE_USE
> means "all [current and future] type contexts".
>

I had a similar thought while updating the affected tests:
`@Target(DECLARATIONS)` would have been useful for a number of them.

I don't have a strong opinion either way about whether this change is worth
pursuing, or worth pursuing now. The simplicity of @Target-less annotations
applying to everything is appealing. I also think there's going to be some
noticeable compatibility impact, due to the number of annotations that will
start appearing in type contexts, and the number of tools that process
annotations that will need to become more robust in their handling of type
annotations.

If there's a tentative agreement that making @Target-less annotations apply
to everything together with introducing ElementType.DECLARATIONS is a
reasonable path forward, I can work on a proposal for that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210205/251fb622/attachment.htm>

From alex.buckley at oracle.com  Sat Feb  6 00:51:54 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 5 Feb 2021 16:51:54 -0800
Subject: [External] : Re: RFR: 8231436: Fix the applicability of a
 no-@Target annotation type
In-Reply-To: <CAL4QsgsqX9Sj+AwoLAAy=+7hx__wHU6VhHjNocWrEUwM4HnZxw@mail.gmail.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
 <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
 <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>
 <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com>
 <PEhAZNV434d5RP5m0cH5X5MvUv8tmg-TuPfM1eFqtOQ=.e1483dc5-9c8d-4282-82dc-0d264c7c646d@github.com>
 <54e81069-d66b-d466-77eb-a425ff4ee336@oracle.com>
 <C0E0B8F2-0E5D-4DED-87AE-8D15B39CA372@oracle.com>
 <3d96a404-9bca-97d7-47fc-2de3c6af8726@oracle.com>
 <16C4FF5C-7F03-4002-A35E-3A3AC3F4EFAB@oracle.com>
 <fd25d05c-a344-3451-774e-099ddc302646@oracle.com>
 <CAL4QsgsqX9Sj+AwoLAAy=+7hx__wHU6VhHjNocWrEUwM4HnZxw@mail.gmail.com>
Message-ID: <6c503662-6d2d-5a3e-18b8-67618f4b4945@oracle.com>

On 2/5/2021 4:18 PM, Liam Miller-Cushon wrote:
> I don't have a strong opinion either way about whether this change is 
> worth pursuing, or worth pursuing now. The simplicity of?@Target-less 
> annotations applying to everything is appealing. I also think there's 
> going to be some noticeable compatibility impact, due to the number of 
> annotations that will start appearing in type contexts, and the number 
> of tools that process annotations that will need to become more robust 
> in their handling of type annotations.
Suppose that the no- at Target annotation @Foo is today a declaration 
annotation on a method declaration, but tomorrow (due to recompiling Foo 
and the aforementioned method declaration) @Foo becomes a declaration 
annotation _and a type annotation that applies to the return type of the 
method_. Hardly any annotation processor will care, because it'll be 
calling Method::getAnnotations that only exposes declaration 
annotations. Type annotations are exposed by a different API, 
Method::getAnnotatedReturnType & friends.

Of course a type-checking annotation processor might be calling 
Method::getAnnotatedReturnType to look for, say, @NonNull, but I have a 
hard time believing that such a processor will be unable to cope with 
@Foo's presence. And the owner of Foo can choose at any time to add an 
@Target that makes @Foo appear as both declaration and type annotation.

Is there a compatibility impact I am overlooking?

Alex

From cushon at google.com  Sat Feb  6 01:13:47 2021
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 5 Feb 2021 17:13:47 -0800
Subject: [External] : Re: RFR: 8231436: Fix the applicability of a
 no-@Target annotation type
In-Reply-To: <6c503662-6d2d-5a3e-18b8-67618f4b4945@oracle.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
 <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
 <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>
 <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com>
 <PEhAZNV434d5RP5m0cH5X5MvUv8tmg-TuPfM1eFqtOQ=.e1483dc5-9c8d-4282-82dc-0d264c7c646d@github.com>
 <54e81069-d66b-d466-77eb-a425ff4ee336@oracle.com>
 <C0E0B8F2-0E5D-4DED-87AE-8D15B39CA372@oracle.com>
 <3d96a404-9bca-97d7-47fc-2de3c6af8726@oracle.com>
 <16C4FF5C-7F03-4002-A35E-3A3AC3F4EFAB@oracle.com>
 <fd25d05c-a344-3451-774e-099ddc302646@oracle.com>
 <CAL4QsgsqX9Sj+AwoLAAy=+7hx__wHU6VhHjNocWrEUwM4HnZxw@mail.gmail.com>
 <6c503662-6d2d-5a3e-18b8-67618f4b4945@oracle.com>
Message-ID: <CAL4Qsgtp93JMT6NiMhCiJCoMqRUycjd2aOdZdcDQ0kDRzWinOA@mail.gmail.com>

On Fri, Feb 5, 2021 at 4:52 PM Alex Buckley <alex.buckley at oracle.com> wrote:

> Is there a compatibility impact I am overlooking?
>

I don't think there's anything major, it's just the usual concern that this
is changing observable behaviour, and all observable behaviour of a system
will be depended on by somebody [1].

The least contrived example I can think of is that an annotation processor
might rely on TypeMirror#toString, and the string representation of types
will more often include type annotations, which could affect logic in the
processor or code that gets generated. (I think the javadoc bug I
encountered in JDK-8261203
<https://bugs.openjdk.java.net/browse/JDK-8261203> might be something like
that, where it's converting an annotated type to a string and not escaping
a string literal in the annotation element).

The additional attributes in the class file will also make them slightly
larger, which I think will increase metaspace usage ever so slightly, which
may be observable for some applications.

I agree that being able to add an explicitly @Target to annotations where
this is undesired is a relatively good and inexpensive workaround for the
cases that are affected.

If I was writing a CSR for this I'd probably estimate the compatibility
impact as 'low'--I think it's more than 'minimal', and it may deserve a
release note, but it's likely not prohibitively high. Does that sound right?

[1] https://www.hyrumslaw.com/  <https://www.hyrumslaw.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210205/46ebc845/attachment-0001.htm>

From alex.buckley at oracle.com  Sat Feb  6 01:56:12 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Fri, 5 Feb 2021 17:56:12 -0800
Subject: [External] : Re: RFR: 8231436: Fix the applicability of a
 no-@Target annotation type
In-Reply-To: <CAL4Qsgtp93JMT6NiMhCiJCoMqRUycjd2aOdZdcDQ0kDRzWinOA@mail.gmail.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
 <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>
 <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com>
 <PEhAZNV434d5RP5m0cH5X5MvUv8tmg-TuPfM1eFqtOQ=.e1483dc5-9c8d-4282-82dc-0d264c7c646d@github.com>
 <54e81069-d66b-d466-77eb-a425ff4ee336@oracle.com>
 <C0E0B8F2-0E5D-4DED-87AE-8D15B39CA372@oracle.com>
 <3d96a404-9bca-97d7-47fc-2de3c6af8726@oracle.com>
 <16C4FF5C-7F03-4002-A35E-3A3AC3F4EFAB@oracle.com>
 <fd25d05c-a344-3451-774e-099ddc302646@oracle.com>
 <CAL4QsgsqX9Sj+AwoLAAy=+7hx__wHU6VhHjNocWrEUwM4HnZxw@mail.gmail.com>
 <6c503662-6d2d-5a3e-18b8-67618f4b4945@oracle.com>
 <CAL4Qsgtp93JMT6NiMhCiJCoMqRUycjd2aOdZdcDQ0kDRzWinOA@mail.gmail.com>
Message-ID: <db39c7a4-d616-a474-2330-6d4af75d6574@oracle.com>

On 2/5/2021 5:13 PM, Liam Miller-Cushon wrote:
> If I was writing a CSR for this I'd probably estimate the compatibility 
> impact as 'low'--I think it's more than 'minimal', and it may deserve a 
> release note, but it's likely not prohibitively high. Does that sound right?

Yes. The real issue is that _any_ open-ended definition, even the 
middle-ground "all declaration contexts" one, can lead to 
incompatibilities in processors when annotations are applied in places 
newer than the processor. (Consider a no- at Target @Foo annotation being 
applied to a record component declaration, and thus showing up as a 
declaration annotation on both the corresponding component field and 
accessor method, versus an annotation processor that assumed @Foo would 
only ever appear on class declarations.)  We accept the low risk of 
incompatibilities because open-ended definitions are simple and because 
programmers can easily opt out by giving their desired applicability.

> [1] https://www.hyrumslaw.com/ 

a.k.a. Martin Buchholz's "Every change is an incompatible change."

From kartikohri13 at gmail.com  Mon Feb  8 09:34:42 2021
From: kartikohri13 at gmail.com (Kartik Ohri)
Date: Mon, 8 Feb 2021 15:04:42 +0530
Subject: Using Map.computeIfAbsent in jdk.compiler moduel
In-Reply-To: <CAASLQ4O2ocjNT2orxMSvRc+NEVaS0OQ3C=XObHGEJ1pyyzX1bg@mail.gmail.com>
References: <CAASLQ4O2ocjNT2orxMSvRc+NEVaS0OQ3C=XObHGEJ1pyyzX1bg@mail.gmail.com>
Message-ID: <CAASLQ4N_UH2EEDFh6Xdt0+3e5kSe_UM+NG4Qmz5UDz0cAqOnZw@mail.gmail.com>

Hi!
I have proposed a patch to utilise Map.computeIfAbsent in the jdk.compiler
module. https://github.com/openjdk/jdk/pull/2455. Kindly take a look. If it
is fine to include to this patch in the OpenJDK, please open an issue in
the bug tracker so that I can update the PR.
Thanks.
Regards
Kartik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210208/74a64838/attachment.htm>

From jlahoda at openjdk.java.net  Mon Feb  8 09:39:43 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 8 Feb 2021 09:39:43 GMT
Subject: Integrated: JDK-8260593: javac can skip a temporary local variable
 when pattern matching over a local variable
In-Reply-To: <K3mcIdlZxb_NWWtbtka1dWx0GouNlv4rnFhxHZPveY4=.dbf12096-6ed5-401c-a893-7d4b37c0f179@github.com>
References: <K3mcIdlZxb_NWWtbtka1dWx0GouNlv4rnFhxHZPveY4=.dbf12096-6ed5-401c-a893-7d4b37c0f179@github.com>
Message-ID: <9kpl79_zriBsWmR9IjCw4yCRQFUW9vOZdrFA0RSJTLo=.5b696a2e-e0d9-49c4-830c-b2b4eb37f7ce@github.com>

On Fri, 29 Jan 2021 12:22:00 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> When translating type test like `<expr> instanceof String s`, javac needs to a) check if the value of `<expr>` is a String, and if yes, b) create a new variable `s`, and assign the value of `<expr>` into it. But, `<expr>` needs to be evaluated only once. So, javac will create a temporary local variable to hold the value of `<expr>`. But, if `<expr>` itself is a local variable, there is no need to create another temporary local variable, javac can read the original local variable twice, leading to a shorter bytecode.

This pull request has now been integrated.

Changeset: d0a8f2f7
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d0a8f2f7
Stats:     224 lines in 5 files changed: 209 ins; 4 del; 11 mod

8260593: javac can skip a temporary local variable when pattern matching over a local variable

Reviewed-by: vromero

-------------

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

From alanb at openjdk.java.net  Mon Feb  8 14:06:55 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 8 Feb 2021 14:06:55 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
Message-ID: <BjeBGs7wE7XNdWCI-kZPfaiQqWgrnV9u8i7VdpZXvRU=.812757b3-3920-48f5-844b-7017e1d94df7@github.com>

On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   revert changes in Apache Santuario

src/java.management/share/classes/javax/management/loading/MLet.java line 1147:

> 1145:                                       .toFile();
> 1146:                      file.deleteOnExit();
> 1147:                      Files.copy(is, file.toPath());

One thing to check here is the existing behavior when the file already exists (as Files.copy will fail if the file exists, need to specify REPLACE_EXISTING to get the semantics of the existing code).

The code that follows checks if the file exists, this will always be true when Files.copy succeeds.

src/java.base/share/classes/sun/net/www/MimeLauncher.java line 2:

> 1: /*
> 2:  * Copyright (c) 1994, 2020, Oracle and/or its affiliates. All rights reserved.

Is MimeEntry.launch still used? I'm wondering if the MimeLauncher can be deleted.

-------------

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

From weijun at openjdk.java.net  Mon Feb  8 14:42:44 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Mon, 8 Feb 2021 14:42:44 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
Message-ID: <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>

On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   revert changes in Apache Santuario

The other security-related code changes look good to me.

src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java line 49:

> 47:         throws IOException
> 48:     {
> 49:         return is.readAllBytes();

This is also from Apache Santuario. It's better to keep it unchanged.

-------------

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

From neshkeev at yandex.ru  Mon Feb  8 16:00:16 2021
From: neshkeev at yandex.ru (Nikita Eshkeev)
Date: Mon, 08 Feb 2021 19:00:16 +0300
Subject: PreviewFeature on packages and modules
In-Reply-To: <4244c562-f8e8-4ac3-37a8-94d9ed8f3aec@oracle.com>
References: <222161612366851@mail.yandex.ru>
 <1e843faa-5884-ec9f-d01b-e34f71741551@oracle.com>
 <fb5edb89-42a9-276d-6cd1-ae8dac3e196d@oracle.com>
 <5aa38fa0-0fd0-3efa-2d8b-72f7e4a2a4a6@oracle.com>
 <fcc30c53-624b-0e64-b87f-252dcf623493@oracle.com>
 <87a3bd1c-2e51-181c-5631-f12e4ccedfc3@oracle.com>
 <7c82a01d-034f-3d25-a214-62d044facc63@oracle.com>
 <bf40525a-317c-e491-a36e-ee9225b05045@oracle.com>
 <4244c562-f8e8-4ac3-37a8-94d9ed8f3aec@oracle.com>
Message-ID: <248221612798250@mail.yandex.ru>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210208/296ecf44/attachment.htm>

From jboes at openjdk.java.net  Mon Feb  8 16:21:56 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Mon, 8 Feb 2021 16:21:56 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v7]
In-Reply-To: <PncFUlxLFmz5-8oLVuhmy3aRoi6dM3FVbLLHhWWYdvA=.5693ccd6-7e39-4118-9d86-3d05a0597d31@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <PncFUlxLFmz5-8oLVuhmy3aRoi6dM3FVbLLHhWWYdvA=.5693ccd6-7e39-4118-9d86-3d05a0597d31@github.com>
Message-ID: <JJEyunSQDMsmXDFNw9SV1U_-BIBx3cP1LXyPalKKrjU=.a199c063-bd12-4772-a1dc-4f362d80c58c@github.com>

On Mon, 21 Dec 2020 08:19:08 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo
>
> Andrey Turbanov 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.

src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 29:

> 27: 
> 28: import java.io.ByteArrayInputStream;
> 29: import java.io.IOException;

The copyright year needs to be updated for this file and changed to 2021 in the other files where applicable.

-------------

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

From jboes at openjdk.java.net  Mon Feb  8 16:42:42 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Mon, 8 Feb 2021 16:42:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
Message-ID: <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>

On Mon, 8 Feb 2021 14:40:16 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   revert changes in Apache Santuario
>
> The other security-related code changes look good to me.

I've updated the issue summary to better reflect the changes, the PR summary should be renamed accordingly. 
As mentioned earlier, have you run the tests for the affected areas? Here's some information on how to do that: http://openjdk.java.net/guide/#testing-the-jdk

-------------

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

From alex.buckley at oracle.com  Mon Feb  8 18:13:42 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 8 Feb 2021 10:13:42 -0800
Subject: PreviewFeature on packages and modules
In-Reply-To: <248221612798250@mail.yandex.ru>
References: <222161612366851@mail.yandex.ru>
 <1e843faa-5884-ec9f-d01b-e34f71741551@oracle.com>
 <fb5edb89-42a9-276d-6cd1-ae8dac3e196d@oracle.com>
 <5aa38fa0-0fd0-3efa-2d8b-72f7e4a2a4a6@oracle.com>
 <fcc30c53-624b-0e64-b87f-252dcf623493@oracle.com>
 <87a3bd1c-2e51-181c-5631-f12e4ccedfc3@oracle.com>
 <7c82a01d-034f-3d25-a214-62d044facc63@oracle.com>
 <bf40525a-317c-e491-a36e-ee9225b05045@oracle.com>
 <4244c562-f8e8-4ac3-37a8-94d9ed8f3aec@oracle.com>
 <248221612798250@mail.yandex.ru>
Message-ID: <424ce018-b843-59b4-c058-98a8e82b3113@oracle.com>

On 2/8/2021 8:00 AM, Nikita Eshkeev wrote:
> Additional questions:
> 1. If a module is annotated with PreviewFeature then javac raises a 
> compile-time errors/warnings when it's used in a requires statement of 
> another module. Is this true?

It should be.

> 2. If a module is not annotated with PreviewFeature then each export 
> statement of a package that is annotated with PreviewFeaturein in 
> module-info.java should lead to compile-time errors/warnings. Is this true?

Package annotations are a no-op. Don't expect any warnings/errors from 
javac if your module `exports` a package annotated @PreviewFeature.

> 3. If a module is not annotated with PreviewFeature then each provides 
> statement of a class that is annotated with PreviewFeature in 
> module-info.java should lead to compile-time errors/warnings. Is this true?

Yes, that counts as a source code reference to a preview API element.

> 4. If a class inherits/implements a class/interface that is marked as 
> PreviewFeature then the class is considered a PreviewFeature. Is this true?

No, that's an over-reading of JEP 12. Assuming that the 
inheriting/implementing class C is not "participating" for the preview 
class P, C's `extends`/`implements` clause will generate a warning/error 
and C.class will be marked as depending on preview features, just as if 
C had declared a field of type P or C's code had used a preview language 
feature. The javadoc for C will display that C's 
superclass/superinterface is a preview API.

Alex

From github.com+741251+turbanoff at openjdk.java.net  Mon Feb  8 20:50:41 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 8 Feb 2021 20:50:41 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <BjeBGs7wE7XNdWCI-kZPfaiQqWgrnV9u8i7VdpZXvRU=.812757b3-3920-48f5-844b-7017e1d94df7@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <BjeBGs7wE7XNdWCI-kZPfaiQqWgrnV9u8i7VdpZXvRU=.812757b3-3920-48f5-844b-7017e1d94df7@github.com>
Message-ID: <BdQsbXFMxgTxyaKoAeQOdJ-52AnWCrUUUmKQe_ilUaY=.74983229-9463-43a0-ac22-8ae2c48ca0fe@github.com>

On Mon, 8 Feb 2021 14:01:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   revert changes in Apache Santuario
>
> src/java.management/share/classes/javax/management/loading/MLet.java line 1147:
> 
>> 1145:                                       .toFile();
>> 1146:                      file.deleteOnExit();
>> 1147:                      Files.copy(is, file.toPath());
> 
> One thing to check here is the existing behavior when the file already exists (as Files.copy will fail if the file exists, need to specify REPLACE_EXISTING to get the semantics of the existing code).
> 
> The code that follows checks if the file exists, this will always be true when Files.copy succeeds.

fixed

-------------

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Feb  8 20:54:47 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 8 Feb 2021 20:54:47 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v7]
In-Reply-To: <JJEyunSQDMsmXDFNw9SV1U_-BIBx3cP1LXyPalKKrjU=.a199c063-bd12-4772-a1dc-4f362d80c58c@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <PncFUlxLFmz5-8oLVuhmy3aRoi6dM3FVbLLHhWWYdvA=.5693ccd6-7e39-4118-9d86-3d05a0597d31@github.com>
 <JJEyunSQDMsmXDFNw9SV1U_-BIBx3cP1LXyPalKKrjU=.a199c063-bd12-4772-a1dc-4f362d80c58c@github.com>
Message-ID: <NDGqsqvKpgvsi0OCV7briRodMEnNwFVseA72F4zbCG0=.5c9554cb-5116-4467-82dd-d919ed4fe5f3@github.com>

On Mon, 8 Feb 2021 16:19:17 GMT, Julia Boes <jboes at openjdk.org> wrote:

>> Andrey Turbanov 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.
>
> src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 29:
> 
>> 27: 
>> 28: import java.io.ByteArrayInputStream;
>> 29: import java.io.IOException;
> 
> The copyright year needs to be updated for this file and changed to 2021 in the other files where applicable.

done

-------------

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Feb  8 20:54:48 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 8 Feb 2021 20:54:48 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
Message-ID: <xIcOD_gjq-dnpKfNpMGm13Uax_5YLkZtatTYWgtBpGc=.78ab950f-b902-4dee-8545-9d0574d75cef@github.com>

On Mon, 8 Feb 2021 14:38:52 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   revert changes in Apache Santuario
>
> src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/Utils.java line 49:
> 
>> 47:         throws IOException
>> 48:     {
>> 49:         return is.readAllBytes();
> 
> This is also from Apache Santuario. It's better to keep it unchanged.

reverted

-------------

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Feb  8 20:58:01 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 8 Feb 2021 20:58:01 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v9]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <oyAwqFESfH7q3wJicuQNF0Hds0Sp69dN5bzxYAIBaOQ=.df45bf24-3f70-457d-9df9-8a5b3022f1e1@github.com>

> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  fix review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/94e99817..6a8a3ae6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=07-08

  Stats: 29 lines in 10 files changed: 16 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

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

From github.com+471021+marschall at openjdk.java.net  Mon Feb  8 21:21:44 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Mon, 8 Feb 2021 21:21:44 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v9]
In-Reply-To: <oyAwqFESfH7q3wJicuQNF0Hds0Sp69dN5bzxYAIBaOQ=.df45bf24-3f70-457d-9df9-8a5b3022f1e1@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <oyAwqFESfH7q3wJicuQNF0Hds0Sp69dN5bzxYAIBaOQ=.df45bf24-3f70-457d-9df9-8a5b3022f1e1@github.com>
Message-ID: <WtXQ3xGo_psAegHONwjHWSSdAGsvsW9yN6eXAGL8Sbc=.c5c0ef89-24c9-428d-a86d-71db7437d6d3@github.com>

On Mon, 8 Feb 2021 20:58:01 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   fix review comments

src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 230:

> 228:                 // Copy the entire input stream into an InputStream that does
> 229:                 // support mark
> 230:                 is = new ByteArrayInputStream(is.readAllBytes());

I don't understand why the check for #markSupported is done there. The InputStream constructor of PKCS7 creates a DataInputStream on the InputStream only to then call #readFully. I can't find a place where a call to #mark happens. Since the InputStream constructor reads all bytes anyway I wonder whether we could remove this if and unconditionally do:

PKCS7 pkcs7 = new PKCS7(is.readAllBytes());

-------------

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

From github.com+471021+marschall at openjdk.java.net  Tue Feb  9 11:42:34 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Tue, 9 Feb 2021 11:42:34 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v9]
In-Reply-To: <oyAwqFESfH7q3wJicuQNF0Hds0Sp69dN5bzxYAIBaOQ=.df45bf24-3f70-457d-9df9-8a5b3022f1e1@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <oyAwqFESfH7q3wJicuQNF0Hds0Sp69dN5bzxYAIBaOQ=.df45bf24-3f70-457d-9df9-8a5b3022f1e1@github.com>
Message-ID: <4-2EVrWdbxsKykSlYd3bAuxS7iuzZbxKPEhrE-y_fMk=.986e5094-e940-4a89-a70e-5aad77dde26d@github.com>

On Mon, 8 Feb 2021 20:58:01 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   fix review comments

src/java.base/share/classes/java/util/jar/JarInputStream.java line 93:

> 91:         if (e != null && JarFile.MANIFEST_NAME.equalsIgnoreCase(e.getName())) {
> 92:             man = new Manifest();
> 93:             byte[] bytes = new BufferedInputStream(this).readAllBytes();

I wonder if it makes sense to avoid reading the entire manifest into a byte[] when we don't need to verify the JAR. This may help avoiding some intermediate allocation and copying. This make be noticeable for some of the larger manifests (Java EE, OSGi, ...). A possible implementation may look like this https://github.com/marschall/jdk/commit/c50880ffb18607077c4da3456b27957d1df8edb7.

In either case since we're calling #readAllBytes I don't see why we are wrapping in a BufferedInputStream rather than calling #readAllBytes directly.

-------------

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

From redestad at openjdk.java.net  Tue Feb  9 13:59:49 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 9 Feb 2021 13:59:49 GMT
Subject: RFR: 8261444: Remove unused fields in Lower
Message-ID: <ZhoWWyFI9rzWHBEKRUCpH4fR42s8wOCr23Dy1AqHIV4=.ccb66909-b5ef-49a4-8406-3d1c0c8057d6@github.com>

A small code cleanup in Lower, removing a few unused fields.

Last usage of classDollar was removed by JDK-8175191, and dollarCloseResource was removed by JDK-8194978

Testing: tier1-2

-------------

Commit messages:
 - Remove unused fields in Lower

Changes: https://git.openjdk.java.net/jdk/pull/2482/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2482&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261444
  Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2482.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2482/head:pull/2482

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

From brian.goetz at oracle.com  Tue Feb  9 14:34:41 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 9 Feb 2021 09:34:41 -0500
Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation
 type
In-Reply-To: <3d96a404-9bca-97d7-47fc-2de3c6af8726@oracle.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
 <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
 <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>
 <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com>
 <PEhAZNV434d5RP5m0cH5X5MvUv8tmg-TuPfM1eFqtOQ=.e1483dc5-9c8d-4282-82dc-0d264c7c646d@github.com>
 <54e81069-d66b-d466-77eb-a425ff4ee336@oracle.com>
 <C0E0B8F2-0E5D-4DED-87AE-8D15B39CA372@oracle.com>
 <3d96a404-9bca-97d7-47fc-2de3c6af8726@oracle.com>
Message-ID: <eb9c8beb-5e9f-a640-edea-7ec9bc499984@oracle.com>

We appear to have painted ourselves into a corner quite nicely.

In Java 5, the interpretation of "a no- at Target annotation (NTA) is 
applicable in all contexts" made perfect sense; you could use the 
@Target meta-annotation to narrow the set of targets if you were fussy.? 
Then along came type annotations, and we picked the sensible rule that 
the default for an NTA would be all _declaration_ annotations.? This 
avoided short-term incompatibility, but what it did was set type 
annotations apart from all the other places where annotations can go.

I agree with Joel that:
> I agree that had we done this in one go from scratch, it seems likely that the ?all contexts? default for no- at Target annotation would have been chosen.
but, we didn't do this in one go from scratch.? I also agree with Joe 
that the reality seems to be that "one of these things is not like the 
others", and that this is a decision best made by the author of the 
annotation:

> To me, it seems that intending an annotation to be used on 
> declarations or on types is a basic design decision of the annotation 
> type. 

The concern now seems mostly to be about "but, there are old moldy 
annotations (most of them some spelling of "non null"), that we'd like 
to be applicable in all places, but were written without a @Target, but 
which we'd like to interpret as type annotations." Understandable, but 
it seems that the fix for that is to convince the maintainers of those 
annotations of this fact, not change the language to absolve them from 
responsibility for updating their design intent in their code.

So I agree with Joe that:

> I think it can be reasonable to interpret lack of @Target to mean 
> "usable in any declaration context," but ill-advised to silently 
> reinterpret absence of a @Target to indicate types and declarations. 

and prefer that we leave the existing interpretation of "all declaration 
contexts" for NTAs.? Like raw types, which we convinced ourselves we 
could get rid of eventually, sometimes this turns out to be wishful 
thinking.






On 2/3/2021 1:39 PM, Alex Buckley wrote:
> Let me focus first on the design question of what a no- at Target 
> annotation type "means". There's no particular reason why it 
> _shouldn't_ mean "all contexts". Mike gave good reasons why it should 
> mean that. For the corner case of an annotation appearing in one of 
> the ambiguous locations in source code, the annotation will appear in 
> the class file/via reflection exactly as if someone had taken the 
> perfectly legitimate course of spelling out @Target({METHOD, 
> TYPE_USE}) -- the no- at Target case is not a secret door to behavior 
> that's otherwise impossible or undesirable.
>
> (We could have said "all contexts" for a no- at Target annotation type 
> but then added a rule in 9.7.4 to special-case a no- at Target annotation 
> that appears in an ambiguous location, e.g., to compile the annotation 
> as if it was applicable only in declaration contexts. More 
> compatibility with SE 8, but more complexity, and I don't think anyone 
> really wants that.)
>
> Turning to the compatibility concern: yes, JDK-8231435 shouldn't have 
> claimed behavioral compatibility. It was my error to not recognize 
> what Mike was saying in "It is a behavior change from the current 
> specification, but a small one that affects poorly-written programs 
> that have no @Target meta-annotation." Still, at the end of the day, 
> it's no more than a small behavioral incompatibility for annotation 
> processors (they may see more type annotations than they did before), 
> and one which was within the power of the annotation type's owner to 
> induce anyway (annotation processors that look for type annotations 
> can reasonably be expected to ignore type annotations in places they 
> don't care about).
>
> I have cc'd Mike in case he wants to add anything further, but the 
> design intent of "all contexts" still looks reasonable to me.
>
> Alex
>
> On 2/3/2021 5:29 AM, Joel Borggren-Franck wrote:
>> Hi Alex,
>>
>> Looking at? the class file, and therefore reflection, there is a 
>> difference between ?all declaration contexts? and ?all contexts, 
>> declaration + type?. For the 5 ambiguous locations we would have to 
>> produce type annotation attributes if there is an annotation present 
>> whose declaration lack @Target. While this may or may not be 
>> desirable, and I?m leaning towards not, it is surely significant as 
>> it would change the semantics of reflective annotation processors in 
>> use.
>>
>> cheers
>> /Joel
>>
>>> On 2 Feb 2021, at 19:50, Alex Buckley <alex.buckley at oracle.com> wrote:
>>>
>>> I initially proposed "all declaration contexts" as the smallest 
>>> possible streamlining of the SE 7-oriented rule defined in SE 8. It 
>>> would have ensured that legacy annotation types without @Target were 
>>> locked out of the new world of type uses enabled in SE 8 by JSR 308. 
>>> As it turned out, my conservative approach was unnecessary because 
>>> Mike was fine with admitting those legacy annotation types for type 
>>> uses via the "all contexts" rule. In the real world, "all 
>>> declaration contexts" versus "all declaration contexts + all type 
>>> contexts" is a distinction without a difference (that is, an 
>>> insignificant distinction) -- we're best off adopting the latter 
>>> rule, phrased simply as "all contexts".
>>>
>>> Alex
>>>
>>> On 2/2/2021 3:44 AM, Guoxiong Li wrote:
>>>> On Tue, 2 Feb 2021 09:28:59 GMT, Joel Borggr?n-Franck 
>>>> <jfranck at openjdk.org> wrote:
>>>>>> Thanks for the comments,
>>>>>>
>>>>>> @jbf I'll add a more focused test. For the bug, the original 
>>>>>> discussion in 
>>>>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013705.html 
>>>>>> is specifically about annotations without an explicit `@Target` 
>>>>>> applying to `MODULE`, I don't think there's anything that needs 
>>>>>> to be done for 
>>>>>> [JDK-8231436](https://bugs.openjdk.java.net/browse/JDK-8231436) 
>>>>>> besides supporting `MODULE`, would you still prefer a separate bug?
>>>>>>
>>>>>> @jddarcy note that there was already a spec change related to 
>>>>>> this in 
>>>>>> [JDK-8231435](https://bugs.openjdk.java.net/browse/JDK-8231435) 
>>>>>> and the spec bug mentions "this expansion is source, binary, and 
>>>>>> behaviorally compatible", should I still file a CSR?
>>>>>
>>>>> ?From this follow up here: 
>>>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013715.html 
>>>>> my interpretation is that this bug was intended to widen it to all 
>>>>> contexts, including type use. This has been changed in JLS but not 
>>>>> in the normative javadoc and also not in the compiler. I believe 
>>>>> we should keep declarations only, and back out the change to JLS.
>>>> Maybe we should collect the concrete information about this 
>>>> problem. Here are some materials that I know.
>>>> Order by time:
>>>> - 2019.08 **Werner Dietl** launched the discussion. [1]
>>>> - 2019.09 After the discussion between **Alex Buckley** and 
>>>> **Michael Ernst**, an initiative result came out.[2]
>>>> - 2019.09 Two JBS issues were filed. [3][4]
>>>> - 2019.12 **Alex Buckley** fixed the JLS(fix version: 14). But the 
>>>> compiler code and javadoc were not fixed. [5][6]
>>>> - 2020.10 **Christian Stein** created another issue about it. [7]
>>>> - 2020.10 **Guoxiong Li**(me) submitted a PR about it in Github. [8]
>>>> - 2020.10 **Joel Borggr?n-Franck** restarted the discussion about 
>>>> the specification. [9]
>>>> - 2020.12 Because the JDK16 was nearly at RDP1, we decided to only 
>>>> fix JDK-8254023. And other work left to JDk17. [7][10][11]
>>>> - 2020.12 The issue JDK-8254023 was fixed at JDK16. [7][8][12]
>>>> - **Now, we need to discuss the problem(unify the specification, 
>>>> implement and javadoc) that JDK16 has left.**[11]
>>>> [1] 
>>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-August/013666.html
>>>> [2] 
>>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013705.html
>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8231435
>>>> [4] https://bugs.openjdk.java.net/browse/JDK-8231436
>>>> [5] 
>>>> https://docs.oracle.com/javase/specs/jls/se14/html/jls-9.html#jls-9.6.4.1
>>>> [6] 
>>>> https://docs.oracle.com/en/java/javase/14/docs/api/java.base/java/lang/annotation/Target.html
>>>> [7] https://bugs.openjdk.java.net/browse/JDK-8254023
>>>> [8] https://github.com/openjdk/jdk/pull/622
>>>> [9] 
>>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015197.html
>>>> [10] http://openjdk.java.net/projects/jdk/16/
>>>> [11] 
>>>> https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015503.html
>>>> [12] https://github.com/openjdk/jdk16/pull/34
>>>> -------------
>>>> PR: https://git.openjdk.java.net/jdk/pull/2303
>>


From vromero at openjdk.java.net  Tue Feb  9 15:06:02 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 9 Feb 2021 15:06:02 GMT
Subject: RFR: 8261444: Remove unused fields in Lower
In-Reply-To: <ZhoWWyFI9rzWHBEKRUCpH4fR42s8wOCr23Dy1AqHIV4=.ccb66909-b5ef-49a4-8406-3d1c0c8057d6@github.com>
References: <ZhoWWyFI9rzWHBEKRUCpH4fR42s8wOCr23Dy1AqHIV4=.ccb66909-b5ef-49a4-8406-3d1c0c8057d6@github.com>
Message-ID: <y4VcaXYBxnR_yI3-fvrMGoyewIGXOUyfqx8WI1-qSWw=.f90e365e-89cd-428c-8d4f-4d5ba73a11d8@github.com>

On Tue, 9 Feb 2021 13:46:47 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A small code cleanup in Lower, removing a few unused fields.
> 
> Last usage of classDollar was removed by JDK-8175191, and dollarCloseResource was removed by JDK-8194978
> 
> Testing: tier1-2

looks good

-------------

Marked as reviewed by vromero (Reviewer).

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

From redestad at openjdk.java.net  Thu Feb 11 10:44:40 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 11 Feb 2021 10:44:40 GMT
Subject: RFR: 8261444: Remove unused fields in Lower
In-Reply-To: <y4VcaXYBxnR_yI3-fvrMGoyewIGXOUyfqx8WI1-qSWw=.f90e365e-89cd-428c-8d4f-4d5ba73a11d8@github.com>
References: <ZhoWWyFI9rzWHBEKRUCpH4fR42s8wOCr23Dy1AqHIV4=.ccb66909-b5ef-49a4-8406-3d1c0c8057d6@github.com>
 <y4VcaXYBxnR_yI3-fvrMGoyewIGXOUyfqx8WI1-qSWw=.f90e365e-89cd-428c-8d4f-4d5ba73a11d8@github.com>
Message-ID: <6qznNwefmbIVB2qim27qJYCtmIn1EKLxjJGvXTZcs3M=.34066147-1324-46c1-b9fc-26a89556acaf@github.com>

On Tue, 9 Feb 2021 14:19:56 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> A small code cleanup in Lower, removing a few unused fields.
>> 
>> Last usage of classDollar was removed by JDK-8175191, and dollarCloseResource was removed by JDK-8194978
>> 
>> Testing: tier1-2
>
> looks good

Thanks Vicente!

-------------

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

From redestad at openjdk.java.net  Thu Feb 11 10:44:42 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 11 Feb 2021 10:44:42 GMT
Subject: Integrated: 8261444: Remove unused fields in Lower
In-Reply-To: <ZhoWWyFI9rzWHBEKRUCpH4fR42s8wOCr23Dy1AqHIV4=.ccb66909-b5ef-49a4-8406-3d1c0c8057d6@github.com>
References: <ZhoWWyFI9rzWHBEKRUCpH4fR42s8wOCr23Dy1AqHIV4=.ccb66909-b5ef-49a4-8406-3d1c0c8057d6@github.com>
Message-ID: <DY1IZ06WfglHr8hvaCk3KP7Ezp9a4Bguud83viZQ3zs=.0a3f2571-f260-44c6-801a-0e4b66ee4acb@github.com>

On Tue, 9 Feb 2021 13:46:47 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> A small code cleanup in Lower, removing a few unused fields.
> 
> Last usage of classDollar was removed by JDK-8175191, and dollarCloseResource was removed by JDK-8194978
> 
> Testing: tier1-2

This pull request has now been integrated.

Changeset: 5e1b8092
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5e1b8092
Stats:     8 lines in 1 file changed: 0 ins; 8 del; 0 mod

8261444: Remove unused fields in Lower

Reviewed-by: vromero

-------------

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

From alex.buckley at oracle.com  Thu Feb 11 17:51:38 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 11 Feb 2021 09:51:38 -0800
Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation
 type
In-Reply-To: <eb9c8beb-5e9f-a640-edea-7ec9bc499984@oracle.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
 <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
 <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>
 <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com>
 <PEhAZNV434d5RP5m0cH5X5MvUv8tmg-TuPfM1eFqtOQ=.e1483dc5-9c8d-4282-82dc-0d264c7c646d@github.com>
 <54e81069-d66b-d466-77eb-a425ff4ee336@oracle.com>
 <C0E0B8F2-0E5D-4DED-87AE-8D15B39CA372@oracle.com>
 <3d96a404-9bca-97d7-47fc-2de3c6af8726@oracle.com>
 <eb9c8beb-5e9f-a640-edea-7ec9bc499984@oracle.com>
Message-ID: <a0b5d385-f95b-ec32-65a4-52d64a273d24@oracle.com>

On 2/9/2021 6:34 AM, Brian Goetz wrote:
> So I agree with Joe that:
> 
>> I think it can be reasonable to interpret lack of @Target to mean 
>> "usable in any declaration context," but ill-advised to silently 
>> reinterpret absence of a @Target to indicate types and declarations. 
> 
> and prefer that we leave the existing interpretation of "all declaration 
> contexts" for NTAs.

Thanks Brian. I will proceed with that policy by filing a new spec bug 
to overrule JDK-8231435.

A coarse DECLARATIONS target that explicitly indicates "all declaration 
contexts" (and that serves as a dual to the coarse TYPE_USE target) can 
be left for another day/thread/RFE.

Alex

From cushon at google.com  Thu Feb 11 19:28:00 2021
From: cushon at google.com (Liam Miller-Cushon)
Date: Thu, 11 Feb 2021 11:28:00 -0800
Subject: RFR: 8231436: Fix the applicability of a no-@Target annotation
 type
In-Reply-To: <a0b5d385-f95b-ec32-65a4-52d64a273d24@oracle.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
 <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
 <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>
 <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com>
 <PEhAZNV434d5RP5m0cH5X5MvUv8tmg-TuPfM1eFqtOQ=.e1483dc5-9c8d-4282-82dc-0d264c7c646d@github.com>
 <54e81069-d66b-d466-77eb-a425ff4ee336@oracle.com>
 <C0E0B8F2-0E5D-4DED-87AE-8D15B39CA372@oracle.com>
 <3d96a404-9bca-97d7-47fc-2de3c6af8726@oracle.com>
 <eb9c8beb-5e9f-a640-edea-7ec9bc499984@oracle.com>
 <a0b5d385-f95b-ec32-65a4-52d64a273d24@oracle.com>
Message-ID: <CAL4QsgsOe-iaD+zUP5W2_OwbCHHXP5Cx6DUK5hRV1NhwFSfhYQ@mail.gmail.com>

On Thu, Feb 11, 2021 at 9:52 AM Alex Buckley <alex.buckley at oracle.com>
wrote:

> On 2/9/2021 6:34 AM, Brian Goetz wrote:
> > So I agree with Joe that:
> >
> >> I think it can be reasonable to interpret lack of @Target to mean
> >> "usable in any declaration context," but ill-advised to silently
> >> reinterpret absence of a @Target to indicate types and declarations.
> >
> > and prefer that we leave the existing interpretation of "all declaration
> > contexts" for NTAs.
>
> Thanks Brian. I will proceed with that policy by filing a new spec bug
> to overrule JDK-8231435.
>

Thanks all. I will close this review.

To confirm, is there still consensus that "all declaration contexts" for
NTAs includes declaration contexts introduced in later language levels,
i.e. NTAs should be applicable to module declarations in Java >= 9, and
that it's OK to proceed with JDK-8261088?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210211/cfad4665/attachment.htm>

From cushon at openjdk.java.net  Thu Feb 11 19:32:41 2021
From: cushon at openjdk.java.net (Liam Miller-Cushon)
Date: Thu, 11 Feb 2021 19:32:41 GMT
Subject: Withdrawn: 8231436: Fix the applicability of a no-@Target annotation
 type
In-Reply-To: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
Message-ID: <9iftTI7kUftd5N4ey0JAdLGKO-2u7sfkkOgNrPvrOKA=.bd76d363-cd18-4ec8-9945-37d5d352dc76@github.com>

On Thu, 28 Jan 2021 22:33:53 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Please review this fix to add `ElementType.MODULE` to the default list of annotation targets, to allow annotations without an explicit `@Target` to be used on module declarations.

This pull request has been closed without being integrated.

-------------

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

From alex.buckley at oracle.com  Thu Feb 11 20:29:00 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 11 Feb 2021 12:29:00 -0800
Subject: [External] : Re: RFR: 8231436: Fix the applicability of a
 no-@Target annotation type
In-Reply-To: <CAL4QsgsOe-iaD+zUP5W2_OwbCHHXP5Cx6DUK5hRV1NhwFSfhYQ@mail.gmail.com>
References: <542-Oy2NaC85JYPJCuT-x2DpGr4e357tB2OG4JOHQhQ=.093a50bd-681a-4ea9-91da-b05f69fb1519@github.com>
 <ZBQlsIpTnDo2fIaC8n64rqV8CTrAOwaqQ4Vfk0aTjHQ=.bec56d86-8a15-4758-b7ef-e135047f78d8@github.com>
 <BRGAdWO_fsl95wyErFOmQUA_z-WcdglQmjtyrEGOWe4=.f7f82667-5044-41ab-9799-d595fa1e12f4@github.com>
 <J0dnYgyf8QIECBcKi1UvoFPnMHwvLkhovqAOe4uPr78=.5d9fd7b6-7377-4ca6-9997-6f3243470533@github.com>
 <8SYkVUATvK-NwcOpoGRYGMSN2b33muGHMbP86pL02eA=.a9718845-aa54-4100-8794-4dfa86f5ea32@github.com>
 <PEhAZNV434d5RP5m0cH5X5MvUv8tmg-TuPfM1eFqtOQ=.e1483dc5-9c8d-4282-82dc-0d264c7c646d@github.com>
 <54e81069-d66b-d466-77eb-a425ff4ee336@oracle.com>
 <C0E0B8F2-0E5D-4DED-87AE-8D15B39CA372@oracle.com>
 <3d96a404-9bca-97d7-47fc-2de3c6af8726@oracle.com>
 <eb9c8beb-5e9f-a640-edea-7ec9bc499984@oracle.com>
 <a0b5d385-f95b-ec32-65a4-52d64a273d24@oracle.com>
 <CAL4QsgsOe-iaD+zUP5W2_OwbCHHXP5Cx6DUK5hRV1NhwFSfhYQ@mail.gmail.com>
Message-ID: <3fe25ce0-3f4c-886d-1492-796bfd8c5804@oracle.com>

On 2/11/2021 11:28 AM, Liam Miller-Cushon wrote:
> On Thu, Feb 11, 2021 at 9:52 AM Alex Buckley <alex.buckley at oracle.com 
> <mailto:alex.buckley at oracle.com>> wrote:
> 
>     On 2/9/2021 6:34 AM, Brian Goetz wrote:
>      > So I agree with Joe that:
>      >
>      >> I think it can be reasonable to interpret lack of @Target to mean
>      >> "usable in any declaration context," but ill-advised to silently
>      >> reinterpret absence of a @Target to indicate types and
>     declarations.
>      >
>      > and prefer that we leave the existing interpretation of "all
>     declaration
>      > contexts" for NTAs.
> 
>     Thanks Brian. I will proceed with that policy by filing a new spec bug
>     to overrule JDK-8231435.
> 
> 
> Thanks all. I will close this review.

I have filed spec bug https://bugs.openjdk.java.net/browse/JDK-8261610

Since the javac bug JDK-8231436 never got beyond New status, I think it 
would be reasonable to use it as the carrier for javac changes connected 
with the new spec bug.

> To confirm, is there still consensus?that "all declaration contexts" for 
> NTAs includes declaration contexts introduced in later language levels, 
> i.e. NTAs should be applicable to module declarations in Java >= 9, and 
> that it's OK to proceed with?JDK-8261088?

Yes. The spec bug discusses the open-ended nature of "all declaration 
contexts", including that it captures module declarations added in 9. 
For JDK-8261088, the anno.interface T (applicable in all declaration 
contexts, including modules) should be able to nominate a containing 
anno.interface that's applicable in only the module declaration context.

Alex

From jjg at openjdk.java.net  Fri Feb 12 00:16:42 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 12 Feb 2021 00:16:42 GMT
Subject: RFR: 8241356: Use a more reliable way to encode Symbol flags [v2]
In-Reply-To: <BeN0ieY-9mauOUxv6aUlC3VU7lvOy7TA4_n4soZwZ9Y=.806f69e0-635c-4f72-8f75-89c73668572d@github.com>
References: <aYRbIKEZmDlWfryC0sW1BSVtzJyIR7BRZS2Vs0XfGaY=.de31b4a7-d2df-489a-9816-08deab0cddef@github.com>
 <BeN0ieY-9mauOUxv6aUlC3VU7lvOy7TA4_n4soZwZ9Y=.806f69e0-635c-4f72-8f75-89c73668572d@github.com>
Message-ID: <tJe6uIJyv9P7NfMGwupM69VXjzsQSOcvuo5n2tppX94=.7ef20990-bc5d-4d18-b0a4-9c13de8538af@github.com>

On Tue, 2 Feb 2021 16:28:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> [This is a GitHub copy of: https://mail.openjdk.java.net/pipermail/compiler-dev/2020-March/014389.html ]
>> 
>> Currently, (com.sun.tools.javac.code.)Symbol/s have a long field "flags_field", which holds various one-bit information ("Flags") about the given Symbol.
>> 
>> We currently have around 64 such Flags, which means we are out of bits in the long field, and adding new flags is not easy.
>> 
>> We could change the "flags_field" to be a Set over enums, but this would increase the memory footprint notably, and would also slow-down access to flags. Currently, flags operations in javac are very fast and very common, so this is probably too much burden. There are also flags to which we need to access as bit masks, e.g. due to writing to classfile.
>> 
>> My proposal here is to use an intermediate solution, until we find a better solution, or until a better solution is possible (like due to Valhalla). The idea is as follows:
>> -the current long-based Flags are split into 4 groups:
>> --"flat" Flags, long based, work exactly as before.
>> --enum-based TypeSymbolFlags, MethodSymbolFlags and VarSymbolFlags, which are only applicable to TypeSymbols, MethodSymbols and VarSymbols, respectively, and are checked using methods like Symbol.isFlagSet and set/clear using methods Symbol.setFlag and Symbol.clearFlag. So these flags are mostly encapsulated, even though physically they are currently stored in the flags_field as well.
>> 
>> There are ~~37~~ 40 "flat" flags and ~~16~~ 17 TypeSymbolFlags (methods and vars have less flags), 57 in total. This gives us at least 7 new flags before we run out of long bits in flags_field again - but even if we do, there are several easy mitigation strategies we could use, like:
>> -create a new int/long field on TypeSymbols for the TypeSymbolFlags (probably preferable)
>> -split TypeSymbolFlags into Class/Package/MethodSymbolFlags
>> 
>> The positives of this solution include:
>> -safe(r) access to the flags - the access to the extra/symbol-kind-specific flags is mostly encapsulated, and hence mostly safe
>> -improves the abstractions at least for some flags
>> -reasonably complex patch (attempts to encapsulate all the flags were troublesome in previous experiments)
>> -the performances appears to be acceptable.
>> 
>> The negative that I see is that the code includes several incompatible types of flags now. These cannot be easily confused by accident (as the type system will complain), but still we need to be aware of them when writing code.
>> 
>> Some more alternatives:
>> -add a new field to Symbol, like long extraFlags, and continue with bit masks as we did so far using this new field. The drawback is that it is more error prone (it would be difficult to ensure only the new/extra flags would be stored and read from extraFlags).
>> -have a new field, and "flat" and non-"flat" enum-based encapsulated Flags, but don't separate Type/Method/Var flags. Probably something to consider, even though I am a bit reluctant to add new fields without trying to avoid it .
>> 
>> Any feedback is welcome!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing merge tags are noted on the review - thanks!

I've reviewed the one javadoc change, and made a comment there. Although I approve the change to that one file, I will leave the review/approval of the javac changes to the javac experts.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java line 594:

> 592:         } else {
> 593:             ModuleSymbol msym = (ModuleSymbol) me;
> 594:             return msym.isFlagSet(TypeSymbolFlags.AUTOMATIC_MODULE);

The change is OK, but the code being changed is not. There should not be references to any `javac.code.*` types outside of the `WorkArounds` class.  Ideally, this function (`isAutomaticModule`) should be on the `Elements` class.

-------------

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

From jjg at openjdk.java.net  Fri Feb 12 00:52:41 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 12 Feb 2021 00:52:41 GMT
Subject: RFR: 8241356: Use a more reliable way to encode Symbol flags [v2]
In-Reply-To: <tJe6uIJyv9P7NfMGwupM69VXjzsQSOcvuo5n2tppX94=.7ef20990-bc5d-4d18-b0a4-9c13de8538af@github.com>
References: <aYRbIKEZmDlWfryC0sW1BSVtzJyIR7BRZS2Vs0XfGaY=.de31b4a7-d2df-489a-9816-08deab0cddef@github.com>
 <BeN0ieY-9mauOUxv6aUlC3VU7lvOy7TA4_n4soZwZ9Y=.806f69e0-635c-4f72-8f75-89c73668572d@github.com>
 <tJe6uIJyv9P7NfMGwupM69VXjzsQSOcvuo5n2tppX94=.7ef20990-bc5d-4d18-b0a4-9c13de8538af@github.com>
Message-ID: <YRKJrpVwLauQfuH67QuiSOKFU6IVdmAZN6P-h_d3FQo=.51e07234-4c3d-45c7-978c-27c98ce3e509@github.com>

On Fri, 12 Feb 2021 00:12:07 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removing merge tags are noted on the review - thanks!
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Extern.java line 594:
> 
>> 592:         } else {
>> 593:             ModuleSymbol msym = (ModuleSymbol) me;
>> 594:             return msym.isFlagSet(TypeSymbolFlags.AUTOMATIC_MODULE);
> 
> The change is OK, but the code being changed is not. There should not be references to any `javac.code.*` types outside of the `WorkArounds` class.  Ideally, this function (`isAutomaticModule`) should be on the `Elements` class.

FYI, PR 2537 will move this code to the `Workarounds` class.

-------------

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

From prappo at openjdk.java.net  Fri Feb 12 13:52:39 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 12 Feb 2021 13:52:39 GMT
Subject: RFR: JDK-8257925 enable more support for nested inline tags [v2]
In-Reply-To: <K6eWyz_Yv4KOTYXkhhYrxFly4avZ9vummGvKPcrplI4=.22c9896d-b887-4a35-a3e4-cb9aa23c1cb3@github.com>
References: <8ywNfJMqNdrdBT2BZb52mnwOVO1sHm2gbpYPGVCH6Ss=.a21bd47b-c78f-466e-b936-2518c3d0a54c@github.com>
 <K6eWyz_Yv4KOTYXkhhYrxFly4avZ9vummGvKPcrplI4=.22c9896d-b887-4a35-a3e4-cb9aa23c1cb3@github.com>
Message-ID: <f4BpuWoL_Dy2RlLbqV8-Ct_H0WcFWczKuuPFPnxOpyQ=.91b8ae04-9004-458f-b90e-ca749a9b2bd4@github.com>

On Fri, 5 Feb 2021 04:44:07 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review an update to improve the support, where appropriate, for nested inline tags. 
>> 
>> It has always been the case that certain inline tags allow text and HTML to appear within them. With tags like `{@return}` and `{@summary}` it becomes desirable to also generally allow nested inline tags to appear in those places as well. The work for this was started with the support for `{@return}` [JDK-8075778](https://bugs.openjdk.java.net/browse/JDK-8075778), but applying the work more generally was out of scope at the time. This change completes the work that was started then.
>> 
>> The work can be grouped into 4 parts, in 3 commits.
>> 
>> ## Commit 1
>> 
>> * Update `DocCommentParser` to syntactically allow nested inline tags in situations that permit text and HTML
>> * Update the downstream code to semantically limit nestg where it does not make sense, and provide new tests to verify the behavior.
>> 
>> A family of new tests are added, each testing the ability to put an inline tag within another of the same kind, with and without doclint being enabled. In addition, test cases are added placing a simple instance `{@value}` in an enclosing tag: this is a useful case just because the expansion is plain text and therefore valid in all situations.  Additional tests and test cases can be added as needed.
>> 
>> This commit left the `{@index}` tag generating "bad" code when it was nested. The error was "reference to an undeclared ID". The (temporary) solution was to disable the automatic link checking for this specific subtest.
>> 
>> ## Commit 2
>> 
>> * `HtmlDocletWriter` and `TagletWriterImpl ` pass around a pair of booleans `isFirstSentence` and `inSummary` to help determine the output to be generated. Conceptually, a third value is added to that group: a set containing the set of nested tag kinds, so that it is possible to determine the enclosing tags for a tag.  But, rather than add a third parameter to be passed around, the 3 are grouped into a new class `TagletWriterImpl.Context` which encapsulates the two booleans and the new set.  The new class is added in a way to minimize code churn.  No tests are affected by this change: all continue to pass.
>> 
>> ## Commit 3
>> 
>> * The new `Context#inTags` field is used to help improve the behavior of nested `{@index}` tags even when used incorrectly, with warnings disabled.  As a result, the temporary change in the first commit to disable automatic link checking in one of the test cases is reverted.
>> 
>> <hr>
>> 
>> The introduction of the new Context class is arguably more general than we need at this time, but it clears up some erratic and inconsistent use of the `isFirstSentence` and `inSummary` booleans. The new class also provides a better framework for any complex new inline tags we may add in future. We might want to change the `Set<DocTree.Kind>` to some other collection at some point, if needs be (a stack, for example.) We might also want to move more information into the `Context`, such as the related `Element` that is otherwise ubiquitously passed around.
>> 
>> The overall cleanup also revealed some latent bugs in the code, that were hidden in some of the tests. Most notable was that there were still some cases were `<` and `>` were not being correctly escaped as `&lt;` and `&gt;` leading to output in some tests of the form `List<String>` !  This triggered a minor cleanup/rewrite of the beginning of `HtmlDocletWriter.seeTagsToContent` which was previously a bit too liberal with the use of `new RawHtml`!  The other minor cleanup was more consistent handling of whitespace at the end of the first sentence, as will be seen in a couple of places in one of the tests that was updated.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve handling of nested links

Thanks for fixing the nested `<a>` issue. With your last commit (96bfeb5) the output from

    /** First sentence. {@link #m1() ABC {@link #m2() DEF} GHI} */

looks like this

    First sentence. <a href="#m1()"><code>ABC DEF GHI</code></a>

and if doclint is enabled, javadoc issues a warning

    warning: nested tag: @link
    /** First sentence. {@link #m1() ABC {@link #m2() DEF} GHI} */
                                         ^

I would recommend comparing JDK API documentation before and after, if only to bring any uncovered surprises to maintainers' attention early.

-------------

Marked as reviewed by prappo (Reviewer).

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

From hannesw at openjdk.java.net  Fri Feb 12 15:12:44 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 12 Feb 2021 15:12:44 GMT
Subject: RFR: JDK-8257925 enable more support for nested inline tags [v2]
In-Reply-To: <K6eWyz_Yv4KOTYXkhhYrxFly4avZ9vummGvKPcrplI4=.22c9896d-b887-4a35-a3e4-cb9aa23c1cb3@github.com>
References: <8ywNfJMqNdrdBT2BZb52mnwOVO1sHm2gbpYPGVCH6Ss=.a21bd47b-c78f-466e-b936-2518c3d0a54c@github.com>
 <K6eWyz_Yv4KOTYXkhhYrxFly4avZ9vummGvKPcrplI4=.22c9896d-b887-4a35-a3e4-cb9aa23c1cb3@github.com>
Message-ID: <k5VE_VlKxPvcsjhn6aNqf73F_0iKTzt6SU2AWT-FDkc=.6c2ab4f1-290b-4550-9d7d-af6bb3645411@github.com>

On Fri, 5 Feb 2021 04:44:07 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review an update to improve the support, where appropriate, for nested inline tags. 
>> 
>> It has always been the case that certain inline tags allow text and HTML to appear within them. With tags like `{@return}` and `{@summary}` it becomes desirable to also generally allow nested inline tags to appear in those places as well. The work for this was started with the support for `{@return}` [JDK-8075778](https://bugs.openjdk.java.net/browse/JDK-8075778), but applying the work more generally was out of scope at the time. This change completes the work that was started then.
>> 
>> The work can be grouped into 4 parts, in 3 commits.
>> 
>> ## Commit 1
>> 
>> * Update `DocCommentParser` to syntactically allow nested inline tags in situations that permit text and HTML
>> * Update the downstream code to semantically limit nestg where it does not make sense, and provide new tests to verify the behavior.
>> 
>> A family of new tests are added, each testing the ability to put an inline tag within another of the same kind, with and without doclint being enabled. In addition, test cases are added placing a simple instance `{@value}` in an enclosing tag: this is a useful case just because the expansion is plain text and therefore valid in all situations.  Additional tests and test cases can be added as needed.
>> 
>> This commit left the `{@index}` tag generating "bad" code when it was nested. The error was "reference to an undeclared ID". The (temporary) solution was to disable the automatic link checking for this specific subtest.
>> 
>> ## Commit 2
>> 
>> * `HtmlDocletWriter` and `TagletWriterImpl ` pass around a pair of booleans `isFirstSentence` and `inSummary` to help determine the output to be generated. Conceptually, a third value is added to that group: a set containing the set of nested tag kinds, so that it is possible to determine the enclosing tags for a tag.  But, rather than add a third parameter to be passed around, the 3 are grouped into a new class `TagletWriterImpl.Context` which encapsulates the two booleans and the new set.  The new class is added in a way to minimize code churn.  No tests are affected by this change: all continue to pass.
>> 
>> ## Commit 3
>> 
>> * The new `Context#inTags` field is used to help improve the behavior of nested `{@index}` tags even when used incorrectly, with warnings disabled.  As a result, the temporary change in the first commit to disable automatic link checking in one of the test cases is reverted.
>> 
>> <hr>
>> 
>> The introduction of the new Context class is arguably more general than we need at this time, but it clears up some erratic and inconsistent use of the `isFirstSentence` and `inSummary` booleans. The new class also provides a better framework for any complex new inline tags we may add in future. We might want to change the `Set<DocTree.Kind>` to some other collection at some point, if needs be (a stack, for example.) We might also want to move more information into the `Context`, such as the related `Element` that is otherwise ubiquitously passed around.
>> 
>> The overall cleanup also revealed some latent bugs in the code, that were hidden in some of the tests. Most notable was that there were still some cases were `<` and `>` were not being correctly escaped as `&lt;` and `&gt;` leading to output in some tests of the form `List<String>` !  This triggered a minor cleanup/rewrite of the beginning of `HtmlDocletWriter.seeTagsToContent` which was previously a bit too liberal with the use of `new RawHtml`!  The other minor cleanup was more consistent handling of whitespace at the end of the first sentence, as will be seen in a couple of places in one of the tests that was updated.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improve handling of nested links

That's a very nice improvement! I have added a few comments and suggestions, but nothing of major importance.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1082:

> 1080:                     default -> {
> 1081:                         assert false;
> 1082:                         return HtmlTree.EMPTY;

What is the reason to `assert false` here and in other places instead of, say, always throw a RuntimeException?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1615:

> 1613:                         if (label.isEmpty()) {
> 1614:                             label = new StringContent(node.getReference().getSignature());
> 1615:                         }

That's quite a bit of work for something probably very few people should try...

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1637:

> 1635:                 public Boolean visitSee(SeeTree node, Content c) {
> 1636:                     // we need to pass the DocTreeImpl here, so ignore node
> 1637:                     result.add(seeTagToContent(element, tag, context));

Is above comment still correct? Aren't `tag` and `node` the same object?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java line 165:

> 163:      */
> 164:     public TagletWriterImpl(HtmlDocletWriter htmlWriter, boolean isFirstSentence, boolean inSummary) {
> 165:         super(isFirstSentence);

To avoid almost identical constructors this one could be implemented as 

    this(htmlWriter, new Context(isFirstSentence, inSummary));

test/langtools/jdk/javadoc/doclet/testNestedInlineTags/TestNestedLinkTag.java line 108:

> 106:                 "ABC <a href=\"#m2()\"");
> 107:         checkOutput("p/C.html", true,
> 108:                 "ABC DEF GHI");

Since you are running this with and without doclint, should this or any test in this file check for doclint warnings?

-------------

Marked as reviewed by hannesw (Reviewer).

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 12 21:09:41 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Feb 2021 21:09:41 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
Message-ID: <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>

On Fri, 12 Feb 2021 21:03:04 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> I've updated the issue summary to better reflect the changes, the PR summary should be renamed accordingly. 
>> As mentioned earlier, have you run the tests for the affected areas? Here's some information on how to do that: http://openjdk.java.net/guide/#testing-the-jdk
>
> I rebased my changes onto master. (commit 837bd8930d0a010110f1318b947c036609d3aa33)
> and checked tier2 and tier3.
> What I got:
> 
>     ==============================
>     Test summary
>     ==============================
>        TEST                                              TOTAL  PASS  FAIL ERROR   
>     >> jtreg:test/jdk:tier2                               3698  3690     6     2 <<
>     >> jtreg:test/langtools:tier2                           12    11     1     0 <<
>        jtreg:test/jaxp:tier2                               450   450     0     0   
>     ==============================
>     TEST FAILURE
> 
> 
> 
> 
>     ==============================
>     Test summary
>     ==============================
>        TEST                                              TOTAL  PASS  FAIL ERROR   
>     >> jtreg:test/jdk:tier3                               1190  1188     2     0 <<
>        jtreg:test/langtools:tier3                            0     0     0     0   
>        jtreg:test/jaxp:tier3                                 0     0     0     0   
>     ==============================
>     TEST FAILURE
> 
> 
> Failed tests:
> 
>      tier2:
>      java/io/File/GetXSpace.java                                                                         Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
>      java/net/MulticastSocket/MulticastAddresses.java                                                    Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file.
>      java/net/MulticastSocket/SetLoopbackMode.java                                                       Failed. Execution failed: `main' threw exception: java.net.NoRouteToHostException: No route to host: no further information
>      java/nio/file/Files/CopyAndMove.java                                                                Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>      java/security/AccessController/DoPrivAccompliceTest.java                                            Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'user' found in stderr
>      tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java                                        Failed. Execution failed: `main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
>      
>      sun/security/tools/jarsigner/TimestampCheck.java                                                    Error. Agent error: java.lang.Exception: Agent 72 timed out with a timeout of 2400 seconds; check console log for any additional details
>      sun/security/tools/keytool/DefaultOptions.java                                                      Error. Agent error: java.lang.Exception: Agent 77 timed out with a timeout of 480 seconds; check console log for any additional details
>      
>      jdk/jshell/ToolBasicTest.java                              Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
>      
>      tier3:
>      sanity/client/SwingSet/src/SwingSet2DemoTest.java                                                                  Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
>      sanity/client/SwingSet/src/ColorChooserDemoTest.java                                                               Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1

Then I tried to run tests separately:
## java/io/File/GetXSpace.java


    make test TEST="jtreg:test/jdk/java/io/File/GetXSpace.java"

    STDERR:
    java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
            at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
            at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
            at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
            at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
            at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230)
            at java.base/java.io.File.toPath(File.java:2316)
            at GetXSpace.compare(GetXSpace.java:219)
            at GetXSpace.testDF(GetXSpace.java:394)
            at GetXSpace.main(GetXSpace.java:428)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
            at java.base/java.lang.Thread.run(Thread.java:831)

    JavaTest Message: Test threw exception: java.nio.file.InvalidPathException
    JavaTest Message: shutting down test

    STDOUT:
    --- Testing df
    C:/Programs/cygwin64   350809332  172573816 178235516      50% /
    D:                    3702215676 2812548988 889666688      76% /cygdrive/d
    E:                    3906885628 3544182676 362702952      91% /cygdrive/e
    F:                     250057724  240917056   9140668      97% /cygdrive/f


    SecurityManager = null
    C:/Programs/cygwin64:
      df   total= 359228755968 free =            0 usable = 182513168384
      getX total= 359228755968 free = 182513168384 usable = 182513168384
    ::
      df   total= 3791068852224 free =            0 usable = 911018688512
      getX total=            0 free =            0 usable =            0

    TEST RESULT: Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
--------------------------------------------------


https://bugs.openjdk.java.net/browse/JDK-8251466 looks like there is already known bug for similar cygwin output.

-------------

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 12 21:09:41 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Feb 2021 21:09:41 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
Message-ID: <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>

On Fri, 12 Feb 2021 21:04:54 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> I rebased my changes onto master. (commit 837bd8930d0a010110f1318b947c036609d3aa33)
>> and checked tier2 and tier3.
>> What I got:
>> 
>>     ==============================
>>     Test summary
>>     ==============================
>>        TEST                                              TOTAL  PASS  FAIL ERROR   
>>     >> jtreg:test/jdk:tier2                               3698  3690     6     2 <<
>>     >> jtreg:test/langtools:tier2                           12    11     1     0 <<
>>        jtreg:test/jaxp:tier2                               450   450     0     0   
>>     ==============================
>>     TEST FAILURE
>> 
>> 
>> 
>> 
>>     ==============================
>>     Test summary
>>     ==============================
>>        TEST                                              TOTAL  PASS  FAIL ERROR   
>>     >> jtreg:test/jdk:tier3                               1190  1188     2     0 <<
>>        jtreg:test/langtools:tier3                            0     0     0     0   
>>        jtreg:test/jaxp:tier3                                 0     0     0     0   
>>     ==============================
>>     TEST FAILURE
>> 
>> 
>> Failed tests:
>> 
>>      tier2:
>>      java/io/File/GetXSpace.java                                                                         Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
>>      java/net/MulticastSocket/MulticastAddresses.java                                                    Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file.
>>      java/net/MulticastSocket/SetLoopbackMode.java                                                       Failed. Execution failed: `main' threw exception: java.net.NoRouteToHostException: No route to host: no further information
>>      java/nio/file/Files/CopyAndMove.java                                                                Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>>      java/security/AccessController/DoPrivAccompliceTest.java                                            Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'user' found in stderr
>>      tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java                                        Failed. Execution failed: `main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
>>      
>>      sun/security/tools/jarsigner/TimestampCheck.java                                                    Error. Agent error: java.lang.Exception: Agent 72 timed out with a timeout of 2400 seconds; check console log for any additional details
>>      sun/security/tools/keytool/DefaultOptions.java                                                      Error. Agent error: java.lang.Exception: Agent 77 timed out with a timeout of 480 seconds; check console log for any additional details
>>      
>>      jdk/jshell/ToolBasicTest.java                              Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
>>      
>>      tier3:
>>      sanity/client/SwingSet/src/SwingSet2DemoTest.java                                                                  Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
>>      sanity/client/SwingSet/src/ColorChooserDemoTest.java                                                               Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
>
> Then I tried to run tests separately:
> ## java/io/File/GetXSpace.java
> 
> 
>     make test TEST="jtreg:test/jdk/java/io/File/GetXSpace.java"
> 
>     STDERR:
>     java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
>             at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
>             at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
>             at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
>             at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
>             at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230)
>             at java.base/java.io.File.toPath(File.java:2316)
>             at GetXSpace.compare(GetXSpace.java:219)
>             at GetXSpace.testDF(GetXSpace.java:394)
>             at GetXSpace.main(GetXSpace.java:428)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
> 
>     JavaTest Message: Test threw exception: java.nio.file.InvalidPathException
>     JavaTest Message: shutting down test
> 
>     STDOUT:
>     --- Testing df
>     C:/Programs/cygwin64   350809332  172573816 178235516      50% /
>     D:                    3702215676 2812548988 889666688      76% /cygdrive/d
>     E:                    3906885628 3544182676 362702952      91% /cygdrive/e
>     F:                     250057724  240917056   9140668      97% /cygdrive/f
> 
> 
>     SecurityManager = null
>     C:/Programs/cygwin64:
>       df   total= 359228755968 free =            0 usable = 182513168384
>       getX total= 359228755968 free = 182513168384 usable = 182513168384
>     ::
>       df   total= 3791068852224 free =            0 usable = 911018688512
>       getX total=            0 free =            0 usable =            0
> 
>     TEST RESULT: Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
> --------------------------------------------------
> 
> 
> https://bugs.openjdk.java.net/browse/JDK-8251466 looks like there is already known bug for similar cygwin output.

## java/net/MulticastSocket/MulticastAddresses.java

    make test TEST="jtreg:test/jdk/java/net/MulticastSocket/MulticastAddresses.java"

    STDOUT:
    Test: /224.80.80.80  ni: name:eth1 (PANGP Virtual Ethernet Adapter)
        joinGroup(InetAddress)     Passed.
        joinGroup(InetAddress,NetworkInterface)     Passed.
    Test: /129.1.1.1
        joinGroup(InetAddress)
        Passed: Not a multicast address
    Test: /ff01:0:0:0:0:0:0:1  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
        joinGroup(InetAddress) Failed: No route to host: no further information
    Test: /ff02:0:0:0:0:0:0:1234  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
        joinGroup(InetAddress)     Passed.
        joinGroup(InetAddress,NetworkInterface)     Passed.
    Test: /ff05:0:0:0:0:0:0:a  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
        joinGroup(InetAddress)     Passed.
        joinGroup(InetAddress,NetworkInterface)     Passed.
    Test: /ff0e:0:0:0:0:0:1234:a  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
        joinGroup(InetAddress)     Passed.
        joinGroup(InetAddress,NetworkInterface)     Passed.
    Test: /0:0:0:0:0:0:0:1
        joinGroup(InetAddress)
        Passed: Not a multicast address
    Test: /0:0:0:0:0:0:8101:101
        joinGroup(InetAddress)
        Passed: Not a multicast address
    Test: /fe80:0:0:0:a00:20ff:fee5:bc02
        joinGroup(InetAddress)
        Passed: Not a multicast address
    STDERR:
    java.lang.Exception: 1 test(s) failed - see log file.
            at MulticastAddresses.runTest(MulticastAddresses.java:93)
            at MulticastAddresses.main(MulticastAddresses.java:138)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
            at java.base/java.lang.Thread.run(Thread.java:831)

    JavaTest Message: Test threw exception: java.lang.Exception
    JavaTest Message: shutting down test


    TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file.


I connected debbuger and got this stack trace:

    java.net.NoRouteToHostException: No route to host: no further information
        at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method)
        at java.base/sun.nio.ch.Net.join6(Net.java:734)
        at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515)
        at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551)
        at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532)
        at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479)
        at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318)
        at MulticastAddresses.runTest(MulticastAddresses.java:56)
        at MulticastAddresses.main(MulticastAddresses.java:138)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
        at java.base/java.lang.Thread.run(Thread.java:831)
        
Not sure what actual cause. Will investigate further.

-------------

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 12 21:09:41 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Feb 2021 21:09:41 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
Message-ID: <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>

On Mon, 8 Feb 2021 16:39:55 GMT, Julia Boes <jboes at openjdk.org> wrote:

>> The other security-related code changes look good to me.
>
> I've updated the issue summary to better reflect the changes, the PR summary should be renamed accordingly. 
> As mentioned earlier, have you run the tests for the affected areas? Here's some information on how to do that: http://openjdk.java.net/guide/#testing-the-jdk

I rebased my changes onto master. (commit 837bd8930d0a010110f1318b947c036609d3aa33)
and checked tier2 and tier3.
What I got:

    ==============================
    Test summary
    ==============================
       TEST                                              TOTAL  PASS  FAIL ERROR   
    >> jtreg:test/jdk:tier2                               3698  3690     6     2 <<
    >> jtreg:test/langtools:tier2                           12    11     1     0 <<
       jtreg:test/jaxp:tier2                               450   450     0     0   
    ==============================
    TEST FAILURE




    ==============================
    Test summary
    ==============================
       TEST                                              TOTAL  PASS  FAIL ERROR   
    >> jtreg:test/jdk:tier3                               1190  1188     2     0 <<
       jtreg:test/langtools:tier3                            0     0     0     0   
       jtreg:test/jaxp:tier3                                 0     0     0     0   
    ==============================
    TEST FAILURE


Failed tests:

     tier2:
     java/io/File/GetXSpace.java                                                                         Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
     java/net/MulticastSocket/MulticastAddresses.java                                                    Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file.
     java/net/MulticastSocket/SetLoopbackMode.java                                                       Failed. Execution failed: `main' threw exception: java.net.NoRouteToHostException: No route to host: no further information
     java/nio/file/Files/CopyAndMove.java                                                                Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
     java/security/AccessController/DoPrivAccompliceTest.java                                            Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: 'user' found in stderr
     tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java                                        Failed. Execution failed: `main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
     
     sun/security/tools/jarsigner/TimestampCheck.java                                                    Error. Agent error: java.lang.Exception: Agent 72 timed out with a timeout of 2400 seconds; check console log for any additional details
     sun/security/tools/keytool/DefaultOptions.java                                                      Error. Agent error: java.lang.Exception: Agent 77 timed out with a timeout of 480 seconds; check console log for any additional details
     
     jdk/jshell/ToolBasicTest.java                              Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
     
     tier3:
     sanity/client/SwingSet/src/SwingSet2DemoTest.java                                                                  Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
     sanity/client/SwingSet/src/ColorChooserDemoTest.java                                                               Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1

-------------

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 12 21:14:40 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Feb 2021 21:14:40 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
Message-ID: <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>

On Fri, 12 Feb 2021 21:06:24 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Then I tried to run tests separately:
>> ## java/io/File/GetXSpace.java
>> 
>> 
>>     make test TEST="jtreg:test/jdk/java/io/File/GetXSpace.java"
>> 
>>     STDERR:
>>     java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
>>             at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
>>             at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
>>             at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
>>             at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
>>             at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230)
>>             at java.base/java.io.File.toPath(File.java:2316)
>>             at GetXSpace.compare(GetXSpace.java:219)
>>             at GetXSpace.testDF(GetXSpace.java:394)
>>             at GetXSpace.main(GetXSpace.java:428)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>> 
>>     JavaTest Message: Test threw exception: java.nio.file.InvalidPathException
>>     JavaTest Message: shutting down test
>> 
>>     STDOUT:
>>     --- Testing df
>>     C:/Programs/cygwin64   350809332  172573816 178235516      50% /
>>     D:                    3702215676 2812548988 889666688      76% /cygdrive/d
>>     E:                    3906885628 3544182676 362702952      91% /cygdrive/e
>>     F:                     250057724  240917056   9140668      97% /cygdrive/f
>> 
>> 
>>     SecurityManager = null
>>     C:/Programs/cygwin64:
>>       df   total= 359228755968 free =            0 usable = 182513168384
>>       getX total= 359228755968 free = 182513168384 usable = 182513168384
>>     ::
>>       df   total= 3791068852224 free =            0 usable = 911018688512
>>       getX total=            0 free =            0 usable =            0
>> 
>>     TEST RESULT: Failed. Execution failed: `main' threw exception: java.nio.file.InvalidPathException: Illegal char <:> at index 0: :
>> --------------------------------------------------
>> 
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8251466 looks like there is already known bug for similar cygwin output.
>
> ## java/net/MulticastSocket/MulticastAddresses.java
> 
>     make test TEST="jtreg:test/jdk/java/net/MulticastSocket/MulticastAddresses.java"
> 
>     STDOUT:
>     Test: /224.80.80.80  ni: name:eth1 (PANGP Virtual Ethernet Adapter)
>         joinGroup(InetAddress)     Passed.
>         joinGroup(InetAddress,NetworkInterface)     Passed.
>     Test: /129.1.1.1
>         joinGroup(InetAddress)
>         Passed: Not a multicast address
>     Test: /ff01:0:0:0:0:0:0:1  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>         joinGroup(InetAddress) Failed: No route to host: no further information
>     Test: /ff02:0:0:0:0:0:0:1234  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>         joinGroup(InetAddress)     Passed.
>         joinGroup(InetAddress,NetworkInterface)     Passed.
>     Test: /ff05:0:0:0:0:0:0:a  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>         joinGroup(InetAddress)     Passed.
>         joinGroup(InetAddress,NetworkInterface)     Passed.
>     Test: /ff0e:0:0:0:0:0:1234:a  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>         joinGroup(InetAddress)     Passed.
>         joinGroup(InetAddress,NetworkInterface)     Passed.
>     Test: /0:0:0:0:0:0:0:1
>         joinGroup(InetAddress)
>         Passed: Not a multicast address
>     Test: /0:0:0:0:0:0:8101:101
>         joinGroup(InetAddress)
>         Passed: Not a multicast address
>     Test: /fe80:0:0:0:a00:20ff:fee5:bc02
>         joinGroup(InetAddress)
>         Passed: Not a multicast address
>     STDERR:
>     java.lang.Exception: 1 test(s) failed - see log file.
>             at MulticastAddresses.runTest(MulticastAddresses.java:93)
>             at MulticastAddresses.main(MulticastAddresses.java:138)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
> 
>     JavaTest Message: Test threw exception: java.lang.Exception
>     JavaTest Message: shutting down test
> 
> 
>     TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file.
> 
> 
> I connected debbuger and got this stack trace:
> 
>     java.net.NoRouteToHostException: No route to host: no further information
>         at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method)
>         at java.base/sun.nio.ch.Net.join6(Net.java:734)
>         at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515)
>         at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551)
>         at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532)
>         at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479)
>         at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318)
>         at MulticastAddresses.runTest(MulticastAddresses.java:56)
>         at MulticastAddresses.main(MulticastAddresses.java:138)
>         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>         at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>         at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>         at java.base/java.lang.Thread.run(Thread.java:831)
>         
> Not sure what actual cause. Will investigate further.

## java/net/MulticastSocket/SetLoopbackMode.java

    make test TEST="jtreg:test/jdk/java/net/MulticastSocket/SetLoopbackMode.java"
    
    
    STDOUT:
    IPv6 can be used
    Default network interface: null

    Test will use multicast group: /ff01:0:0:0:0:0:0:1
    NetworkInterface.getByInetAddress(grp): null
    STDERR:
    java.net.NoRouteToHostException: No route to host: no further information
            at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method)
            at java.base/sun.nio.ch.Net.join6(Net.java:734)
            at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515)
            at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551)
            at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532)
            at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479)
            at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318)
            at SetLoopbackMode.main(SetLoopbackMode.java:132)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
            at java.base/java.lang.Thread.run(Thread.java:831)

    JavaTest Message: Test threw exception: java.net.NoRouteToHostException: No route to host: no further information
    JavaTest Message: shutting down test

    STATUS:Failed.`main' threw exception: java.net.NoRouteToHostException: No route to host: no further information
    
Cause looks similar to `MulticastAddresses`: virtualbox network interface:
Test: /ff01:0:0:0:0:0:0:1  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
    joinGroup(InetAddress) Failed: No route to host: no further information
Will investigate futher.

-------------

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 12 21:34:41 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Feb 2021 21:34:41 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
 <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
Message-ID: <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>

On Fri, 12 Feb 2021 21:12:14 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> ## java/net/MulticastSocket/MulticastAddresses.java
>> 
>>     make test TEST="jtreg:test/jdk/java/net/MulticastSocket/MulticastAddresses.java"
>> 
>>     STDOUT:
>>     Test: /224.80.80.80  ni: name:eth1 (PANGP Virtual Ethernet Adapter)
>>         joinGroup(InetAddress)     Passed.
>>         joinGroup(InetAddress,NetworkInterface)     Passed.
>>     Test: /129.1.1.1
>>         joinGroup(InetAddress)
>>         Passed: Not a multicast address
>>     Test: /ff01:0:0:0:0:0:0:1  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>>         joinGroup(InetAddress) Failed: No route to host: no further information
>>     Test: /ff02:0:0:0:0:0:0:1234  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>>         joinGroup(InetAddress)     Passed.
>>         joinGroup(InetAddress,NetworkInterface)     Passed.
>>     Test: /ff05:0:0:0:0:0:0:a  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>>         joinGroup(InetAddress)     Passed.
>>         joinGroup(InetAddress,NetworkInterface)     Passed.
>>     Test: /ff0e:0:0:0:0:0:1234:a  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>>         joinGroup(InetAddress)     Passed.
>>         joinGroup(InetAddress,NetworkInterface)     Passed.
>>     Test: /0:0:0:0:0:0:0:1
>>         joinGroup(InetAddress)
>>         Passed: Not a multicast address
>>     Test: /0:0:0:0:0:0:8101:101
>>         joinGroup(InetAddress)
>>         Passed: Not a multicast address
>>     Test: /fe80:0:0:0:a00:20ff:fee5:bc02
>>         joinGroup(InetAddress)
>>         Passed: Not a multicast address
>>     STDERR:
>>     java.lang.Exception: 1 test(s) failed - see log file.
>>             at MulticastAddresses.runTest(MulticastAddresses.java:93)
>>             at MulticastAddresses.main(MulticastAddresses.java:138)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>> 
>>     JavaTest Message: Test threw exception: java.lang.Exception
>>     JavaTest Message: shutting down test
>> 
>> 
>>     TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: 1 test(s) failed - see log file.
>> 
>> 
>> I connected debbuger and got this stack trace:
>> 
>>     java.net.NoRouteToHostException: No route to host: no further information
>>         at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method)
>>         at java.base/sun.nio.ch.Net.join6(Net.java:734)
>>         at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515)
>>         at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551)
>>         at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532)
>>         at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479)
>>         at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318)
>>         at MulticastAddresses.runTest(MulticastAddresses.java:56)
>>         at MulticastAddresses.main(MulticastAddresses.java:138)
>>         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>         at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>         at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>         at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>>         at java.base/java.lang.Thread.run(Thread.java:831)
>>         
>> Not sure what actual cause. Will investigate further.
>
> ## java/net/MulticastSocket/SetLoopbackMode.java
> 
>     make test TEST="jtreg:test/jdk/java/net/MulticastSocket/SetLoopbackMode.java"
>     
>     
>     STDOUT:
>     IPv6 can be used
>     Default network interface: null
> 
>     Test will use multicast group: /ff01:0:0:0:0:0:0:1
>     NetworkInterface.getByInetAddress(grp): null
>     STDERR:
>     java.net.NoRouteToHostException: No route to host: no further information
>             at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method)
>             at java.base/sun.nio.ch.Net.join6(Net.java:734)
>             at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515)
>             at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551)
>             at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532)
>             at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479)
>             at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318)
>             at SetLoopbackMode.main(SetLoopbackMode.java:132)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>             at java.base/java.lang.Thread.run(Thread.java:831)
> 
>     JavaTest Message: Test threw exception: java.net.NoRouteToHostException: No route to host: no further information
>     JavaTest Message: shutting down test
> 
>     STATUS:Failed.`main' threw exception: java.net.NoRouteToHostException: No route to host: no further information
>     
> Cause looks similar to `MulticastAddresses`: virtualbox network interface:
> Test: /ff01:0:0:0:0:0:0:1  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>     joinGroup(InetAddress) Failed: No route to host: no further information
> Will investigate futher.

## java/nio/file/Files/CopyAndMove.java    
    
    make test TEST="jtreg:java/nio/file/Files/CopyAndMove.java"
    
    STDOUT:
    Seed from RandomFactory = 704532001916725417L
    STDERR:
    dir1: f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_nio_file_Files_CopyAndMove_java\tmp\name9678927043623070601 (NTFS)
    dir2: .\name1900089232270637553 (NTFS)
    java.lang.RuntimeException: AtomicMoveNotSupportedException expected
            at CopyAndMove.testMove(CopyAndMove.java:369)
            at CopyAndMove.main(CopyAndMove.java:74)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
            at java.base/java.lang.Thread.run(Thread.java:831)

    JavaTest Message: Test threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
    JavaTest Message: shutting down test

    STATUS:Failed.`main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected

Checked in debugger:

    Files.getFileStore(dir1) = {WindowsFileStore at 1211} "ssd (f:)"
    Files.getFileStore(dir2) = {WindowsFileStore at 1213} "ssd (F:)"
    sameDevice = false

https://bugs.openjdk.java.net/browse/JDK-8219644 looks like there is already known bug this test.

-------------

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 12 21:55:43 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Feb 2021 21:55:43 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
 <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
 <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>
Message-ID: <hGiSvYyNa6D0BuKfIh-3CkelapBMNrFaQ_prF3xzPQQ=.64336055-18e5-4428-bc5b-40d484ed18ba@github.com>

On Fri, 12 Feb 2021 21:32:04 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> ## java/net/MulticastSocket/SetLoopbackMode.java
>> 
>>     make test TEST="jtreg:test/jdk/java/net/MulticastSocket/SetLoopbackMode.java"
>>     
>>     
>>     STDOUT:
>>     IPv6 can be used
>>     Default network interface: null
>> 
>>     Test will use multicast group: /ff01:0:0:0:0:0:0:1
>>     NetworkInterface.getByInetAddress(grp): null
>>     STDERR:
>>     java.net.NoRouteToHostException: No route to host: no further information
>>             at java.base/sun.nio.ch.Net.joinOrDrop6(Native Method)
>>             at java.base/sun.nio.ch.Net.join6(Net.java:734)
>>             at java.base/sun.nio.ch.DatagramChannelImpl.innerJoin(DatagramChannelImpl.java:1515)
>>             at java.base/sun.nio.ch.DatagramChannelImpl.join(DatagramChannelImpl.java:1551)
>>             at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:532)
>>             at java.base/sun.nio.ch.DatagramSocketAdaptor.joinGroup(DatagramSocketAdaptor.java:479)
>>             at java.base/java.net.MulticastSocket.joinGroup(MulticastSocket.java:318)
>>             at SetLoopbackMode.main(SetLoopbackMode.java:132)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>> 
>>     JavaTest Message: Test threw exception: java.net.NoRouteToHostException: No route to host: no further information
>>     JavaTest Message: shutting down test
>> 
>>     STATUS:Failed.`main' threw exception: java.net.NoRouteToHostException: No route to host: no further information
>>     
>> Cause looks similar to `MulticastAddresses`: virtualbox network interface:
>> Test: /ff01:0:0:0:0:0:0:1  ni: name:eth10 (VirtualBox Host-Only Ethernet Adapter)
>>     joinGroup(InetAddress) Failed: No route to host: no further information
>> Will investigate futher.
>
> ## java/nio/file/Files/CopyAndMove.java    
>     
>     make test TEST="jtreg:java/nio/file/Files/CopyAndMove.java"
>     
>     STDOUT:
>     Seed from RandomFactory = 704532001916725417L
>     STDERR:
>     dir1: f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_nio_file_Files_CopyAndMove_java\tmp\name9678927043623070601 (NTFS)
>     dir2: .\name1900089232270637553 (NTFS)
>     java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>             at CopyAndMove.testMove(CopyAndMove.java:369)
>             at CopyAndMove.main(CopyAndMove.java:74)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>             at java.base/java.lang.Thread.run(Thread.java:831)
> 
>     JavaTest Message: Test threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>     JavaTest Message: shutting down test
> 
>     STATUS:Failed.`main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
> 
> Checked in debugger:
> 
>     Files.getFileStore(dir1) = {WindowsFileStore at 1211} "ssd (f:)"
>     Files.getFileStore(dir2) = {WindowsFileStore at 1213} "ssd (F:)"
>     sameDevice = false
> 
> https://bugs.openjdk.java.net/browse/JDK-8219644 looks like there is already known bug this test.

## java/security/AccessController/DoPrivAccompliceTest.java

    make test TEST="jtreg:java/security/AccessController/DoPrivAccompliceTest.java"

    STDOUT:
    Adding DoPrivAccomplice.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar

    Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
    Adding DoPrivTest.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar

    Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
    Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
    Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\win
 dows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ]
    [2021-02-12T21:42:29.297091800Z] Gathering output for process 12712
    [2021-02-12T21:42:29.544092Z] Waiting for completion for process 12712
    [2021-02-12T21:42:29.544092Z] Waiting for completion finished for process 12712
    Output and diagnostic info for process 12712 was saved into 'pid-12712-output.log'
    [2021-02-12T21:42:29.547092500Z] Waiting for completion for process 12712
    [2021-02-12T21:42:29.547092500Z] Waiting for completion finished for process 12712
    Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
    Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\win
 dows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ]
    [2021-02-12T21:42:29.553092400Z] Gathering output for process 10560
    [2021-02-12T21:42:29.783092500Z] Waiting for completion for process 10560
    [2021-02-12T21:42:29.783092500Z] Waiting for completion finished for process 10560
    Output and diagnostic info for process 10560 was saved into 'pid-10560-output.log'
    [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560
    [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560
    [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560
    [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560
    STDERR:
     stdout: [];
     stderr: [Exception in thread "main" java.security.AccessControlException: access denied ("java.util.PropertyPermission" "user.name" "read")
            at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
            at java.base/java.security.AccessController.checkPermission(AccessController.java:1036)
            at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408)
            at java.base/java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1152)
            at java.base/java.lang.System.getProperty(System.java:833)
            at DoPrivAccomplice.lambda$go$0(DoPrivAccomplice.java:31)
            at java.base/java.security.AccessController.doPrivileged(AccessController.java:312)
            at DoPrivAccomplice.go(DoPrivAccomplice.java:30)
            at DoPrivTest.main(DoPrivTest.java:29)
    ]
     exitValue = 1

    java.lang.RuntimeException: 'user' found in stderr

            at jdk.test.lib.process.OutputAnalyzer.shouldNotContain(OutputAnalyzer.java:256)
            at DoPrivAccompliceTest.main(DoPrivAccompliceTest.java:112)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
            at java.base/java.lang.Thread.run(Thread.java:831)

    JavaTest Message: Test threw exception: java.lang.RuntimeException: 'user' found in stderr

    JavaTest Message: shutting down test

    STATUS:Failed.`main' threw exception: java.lang.RuntimeException: 'user' found in stderr
    
Looks like test is not ready for username `user`, which I use locally.

-------------

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 12 22:15:43 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 12 Feb 2021 22:15:43 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <hGiSvYyNa6D0BuKfIh-3CkelapBMNrFaQ_prF3xzPQQ=.64336055-18e5-4428-bc5b-40d484ed18ba@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
 <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
 <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>
 <hGiSvYyNa6D0BuKfIh-3CkelapBMNrFaQ_prF3xzPQQ=.64336055-18e5-4428-bc5b-40d484ed18ba@github.com>
Message-ID: <ADR73RPzLPNb5SY61wNVAQNB0JdNFrXgwmsdteeicVU=.1c5f04db-c639-4028-b472-c56999c4746c@github.com>

On Fri, 12 Feb 2021 21:53:13 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> ## java/nio/file/Files/CopyAndMove.java    
>>     
>>     make test TEST="jtreg:java/nio/file/Files/CopyAndMove.java"
>>     
>>     STDOUT:
>>     Seed from RandomFactory = 704532001916725417L
>>     STDERR:
>>     dir1: f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_nio_file_Files_CopyAndMove_java\tmp\name9678927043623070601 (NTFS)
>>     dir2: .\name1900089232270637553 (NTFS)
>>     java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>>             at CopyAndMove.testMove(CopyAndMove.java:369)
>>             at CopyAndMove.main(CopyAndMove.java:74)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>> 
>>     JavaTest Message: Test threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>>     JavaTest Message: shutting down test
>> 
>>     STATUS:Failed.`main' threw exception: java.lang.RuntimeException: AtomicMoveNotSupportedException expected
>> 
>> Checked in debugger:
>> 
>>     Files.getFileStore(dir1) = {WindowsFileStore at 1211} "ssd (f:)"
>>     Files.getFileStore(dir2) = {WindowsFileStore at 1213} "ssd (F:)"
>>     sameDevice = false
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8219644 looks like there is already known bug this test.
>
> ## java/security/AccessController/DoPrivAccompliceTest.java
> 
>     make test TEST="jtreg:java/security/AccessController/DoPrivAccompliceTest.java"
> 
>     STDOUT:
>     Adding DoPrivAccomplice.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
> 
>     Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
>     Adding DoPrivTest.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
> 
>     Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
>     Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
>     Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\w
 indows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ]
>     [2021-02-12T21:42:29.297091800Z] Gathering output for process 12712
>     [2021-02-12T21:42:29.544092Z] Waiting for completion for process 12712
>     [2021-02-12T21:42:29.544092Z] Waiting for completion finished for process 12712
>     Output and diagnostic info for process 12712 was saved into 'pid-12712-output.log'
>     [2021-02-12T21:42:29.547092500Z] Waiting for completion for process 12712
>     [2021-02-12T21:42:29.547092500Z] Waiting for completion finished for process 12712
>     Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
>     Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\w
 indows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ]
>     [2021-02-12T21:42:29.553092400Z] Gathering output for process 10560
>     [2021-02-12T21:42:29.783092500Z] Waiting for completion for process 10560
>     [2021-02-12T21:42:29.783092500Z] Waiting for completion finished for process 10560
>     Output and diagnostic info for process 10560 was saved into 'pid-10560-output.log'
>     [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560
>     [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560
>     [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560
>     [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560
>     STDERR:
>      stdout: [];
>      stderr: [Exception in thread "main" java.security.AccessControlException: access denied ("java.util.PropertyPermission" "user.name" "read")
>             at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>             at java.base/java.security.AccessController.checkPermission(AccessController.java:1036)
>             at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408)
>             at java.base/java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1152)
>             at java.base/java.lang.System.getProperty(System.java:833)
>             at DoPrivAccomplice.lambda$go$0(DoPrivAccomplice.java:31)
>             at java.base/java.security.AccessController.doPrivileged(AccessController.java:312)
>             at DoPrivAccomplice.go(DoPrivAccomplice.java:30)
>             at DoPrivTest.main(DoPrivTest.java:29)
>     ]
>      exitValue = 1
> 
>     java.lang.RuntimeException: 'user' found in stderr
> 
>             at jdk.test.lib.process.OutputAnalyzer.shouldNotContain(OutputAnalyzer.java:256)
>             at DoPrivAccompliceTest.main(DoPrivAccompliceTest.java:112)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>             at java.base/java.lang.Thread.run(Thread.java:831)
> 
>     JavaTest Message: Test threw exception: java.lang.RuntimeException: 'user' found in stderr
> 
>     JavaTest Message: shutting down test
> 
>     STATUS:Failed.`main' threw exception: java.lang.RuntimeException: 'user' found in stderr
>     
> Looks like test is not ready for username `user`, which I use locally.

## tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java

    make test TEST="jtreg:tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java"

    STDOUT:
    [00:56:54.598] Parsing [--jpt-run=jdk.jpackage.tests.UnicodeArgsTest]...
    [00:56:54.650] jdk.jpackage.tests.UnicodeArgsTest.test8246042 -> [public void jdk.jpackage.tests.UnicodeArgsTest.test8246042(boolean)]
    [00:56:54.682] Create: UnicodeArgsTest.test8246042(true)
    [00:56:54.684] Create: UnicodeArgsTest.test8246042(false)
    [00:56:54.688] [ RUN      ] UnicodeArgsTest.test8246042(false)
    [00:56:54.693] TRACE: Test string code points: [0x00e9]
    [00:56:54.875] TRACE: exec: Execute tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)...
    [00:56:55.996] TRACE: exec: Done. Exit code: 0
    [00:56:55.997] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code
    [00:56:56.014] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7)...
    [00:56:56.188] TRACE: exec: Done. Exit code: 0
    [00:56:56.188] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7) exited with 0 code
    [00:56:56.196] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17)...
    [00:56:56.225] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output
    [00:57:07.680] Command:
        jlink --output .\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,java.xml,jdk.xml.dom,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.jsobject,jdk.sctp,java.smartcardio,jdk.jlink,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.naming.rmi,jdk.internal.opt,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.internal.jvmstat,jdk.incubator.foreign,java.instrume
 nt,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files
    [00:57:07.680] Output:
        WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign

    [00:57:07.681] Returned: 0

    [00:57:07.685] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize).
    [00:57:07.707] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage16485063537873697224".
    [00:57:07.712] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize).
    [00:57:07.746] Succeeded in building Windows Application Image package
    [00:57:07.748] TRACE: exec: Done. Exit code: 0
    [00:57:07.748] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17) exited with 0 code
    [00:57:07.766] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package
    [00:57:07.768] TRACE: assertStringListEquals(1, .\test8246042.9782d070\output\8246042UnicodeArgsTest\app.jpackage.xml)
    [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] path exists
    [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] is a directory
    [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists
    [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file
    [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable
    [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists
    [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file
    [00:57:07.780] TRACE: Clearing PATH in environment
    [00:57:07.780] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1); inherit I/O; in directory [.\test8246042.9782d070]...
    hello: Environment supports a display
    hello: Environment supports a desktop
    [0x0065]
    jpackage test application
    args.length: 1
    e
    hello: Output file: [appOutput.txt]
    [00:57:09.302] TRACE: exec: Done. Exit code: 0
    [00:57:09.302] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1) exited with 0 code
    [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] path exists
    [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] is a file
    [00:57:09.305] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
    [00:57:09.305] TRACE: assertStringListEquals(1, jpackage test application)
    [00:57:09.306] TRACE: assertStringListEquals(2, args.length: 1)
    [00:57:09.307] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
    [00:57:09.308] [  FAILED  ] UnicodeArgsTest.test8246042(false); checks=15
    [00:57:09.310] [ RUN      ] UnicodeArgsTest.test8246042(true)
    [00:57:09.312] TRACE: Test string code points: [0x00e9]
    [00:57:09.314] TRACE: exec: Execute tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)...
    [00:57:09.658] TRACE: exec: Done. Exit code: 0
    [00:57:09.659] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code
    [00:57:09.661] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7)...
    [00:57:09.667] TRACE: exec: Done. Exit code: 0
    [00:57:09.667] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7) exited with 0 code
    [00:57:09.670] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15)...
    [00:57:09.670]
    jpackage argument list:
    [--input, .\test8246042.b31bae11\input, --dest, .\test8246042.b31bae11\output, --name, 8246042UnicodeArgsTest, --type, app-image, --main-jar, hello.jar, --main-class, Hello, --win-console, --verbose]

    [00:57:09.679] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output
    [00:57:18.770] Command:
        jlink --output .\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,jdk.sctp,jdk.jsobject,java.sql.rowset,jdk.jlink,java.smartcardio,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instrume
 nt,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,jdk.jpackage,java.management.rmi,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files
    [00:57:18.770] Output:
        WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign

    [00:57:18.770] Returned: 0

    [00:57:18.771] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize).
    [00:57:18.778] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage8738450931736312275".
    [00:57:18.779] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize).
    [00:57:18.787] Succeeded in building Windows Application Image package
    [00:57:18.788] TRACE: exec: Done. Exit code: 0
    [00:57:18.789] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15) exited with 0 code
    [00:57:18.804] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package
    [00:57:18.804] TRACE: assertStringListEquals(1, .\test8246042.b31bae11\output\8246042UnicodeArgsTest\app.jpackage.xml)
    [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] path exists
    [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] is a directory
    [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists
    [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file
    [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable
    [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists
    [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file
    [00:57:18.808] TRACE: Clearing PATH in environment
    [00:57:18.808] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2); inherit I/O; in directory [.\test8246042.b31bae11]...
    hello: Environment supports a display
    hello: Environment supports a desktop
    [0x0065]
    jpackage test application
    args.length: 1
    e
    hello: Output file: [appOutput.txt]
    [00:57:20.327] TRACE: exec: Done. Exit code: 0
    [00:57:20.328] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2) exited with 0 code
    [00:57:20.328] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] path exists
    [00:57:20.329] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] is a file
    [00:57:20.330] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
    [00:57:20.330] TRACE: assertStringListEquals(1, jpackage test application)
    [00:57:20.330] TRACE: assertStringListEquals(2, args.length: 1)
    [00:57:20.330] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
    [00:57:20.331] [  FAILED  ] UnicodeArgsTest.test8246042(true); checks=15
    [00:57:20.332] [==========] 2 tests ran
    [00:57:20.333] [  PASSED  ] 0 tests
    [00:57:20.334] [  FAILED  ] 2 tests, listed below
    [00:57:20.335] [  FAILED  ] UnicodeArgsTest.test8246042(false); workDir=[.\test8246042.9782d070]
    [00:57:20.335] [  FAILED  ] UnicodeArgsTest.test8246042(true); workDir=[.\test8246042.b31bae11]
    [00:57:20.336] 2 FAILED TESTS
    STDERR:
    java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
            at jdk.jpackage.test.TKit.error(TKit.java:293)
            at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765)
            at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
            at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
            at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
            at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
            at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
            at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
            at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
            at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
            at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
            at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759)
            at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225)
            at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204)
            at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405)
            at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417)
            at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319)
            at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:67)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145)
            at jdk.jpackage.test.TestInstance.run(TestInstance.java:230)
            at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155)
            at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140)
            at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
            at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
            at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137)
            at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
            at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
            at jdk.jpackage.test.TKit.runTests(TKit.java:136)
            at jdk.jpackage.test.Main.runTests(Main.java:79)
            at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
            at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
            at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
            at jdk.jpackage.test.Main.main(Main.java:75)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
            at java.base/java.lang.Thread.run(Thread.java:831)
    java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
            at jdk.jpackage.test.TKit.error(TKit.java:293)
            at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765)
            at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
            at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
            at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
            at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
            at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
            at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
            at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
            at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
            at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
            at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759)
            at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225)
            at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204)
            at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405)
            at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417)
            at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319)
            at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:65)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145)
            at jdk.jpackage.test.TestInstance.run(TestInstance.java:230)
            at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155)
            at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140)
            at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
            at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
            at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137)
            at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
            at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
            at jdk.jpackage.test.TKit.runTests(TKit.java:136)
            at jdk.jpackage.test.Main.runTests(Main.java:79)
            at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
            at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
            at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
            at jdk.jpackage.test.Main.main(Main.java:75)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
            at java.base/java.lang.Thread.run(Thread.java:831)
    jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
            at jdk.jpackage.test.Functional.rethrowUnchecked(Functional.java:161)
            at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:107)
            at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
            at jdk.jpackage.test.Main.main(Main.java:75)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
            at java.base/java.lang.Thread.run(Thread.java:831)
    Caused by: java.lang.RuntimeException: 2 FAILED TESTS
            at jdk.jpackage.test.Main.reportSummary(Main.java:130)
            at jdk.jpackage.test.Main.runTests(Main.java:90)
            at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
            at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
            ... 8 more

    JavaTest Message: Test threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
    JavaTest Message: shutting down test

    STATUS:Failed.`main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS

Oh. This one is tricky. Will investigate later.

-------------

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

From github.com+741251+turbanoff at openjdk.java.net  Sat Feb 13 10:23:43 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sat, 13 Feb 2021 10:23:43 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <ADR73RPzLPNb5SY61wNVAQNB0JdNFrXgwmsdteeicVU=.1c5f04db-c639-4028-b472-c56999c4746c@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
 <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
 <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>
 <hGiSvYyNa6D0BuKfIh-3CkelapBMNrFaQ_prF3xzPQQ=.64336055-18e5-4428-bc5b-40d484ed18ba@github.com>
 <ADR73RPzLPNb5SY61wNVAQNB0JdNFrXgwms
 dteeicVU=.1c5f04db-c639-4028-b472-c56999c4746c@github.com>
Message-ID: <h1cjvuqNbm9Chz7atbi8daeCmDWgzzAKdFoHdgngjR8=.543211a7-9513-4d5f-8f45-9b0d300cdf00@github.com>

On Fri, 12 Feb 2021 22:12:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> ## java/security/AccessController/DoPrivAccompliceTest.java
>> 
>>     make test TEST="jtreg:java/security/AccessController/DoPrivAccompliceTest.java"
>> 
>>     STDOUT:
>>     Adding DoPrivAccomplice.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
>> 
>>     Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
>>     Adding DoPrivTest.class to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
>> 
>>     Created jar file F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
>>     Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar
>>     Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\
 windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ]
>>     [2021-02-12T21:42:29.297091800Z] Gathering output for process 12712
>>     [2021-02-12T21:42:29.544092Z] Waiting for completion for process 12712
>>     [2021-02-12T21:42:29.544092Z] Waiting for completion finished for process 12712
>>     Output and diagnostic info for process 12712 was saved into 'pid-12712-output.log'
>>     [2021-02-12T21:42:29.547092500Z] Waiting for completion for process 12712
>>     [2021-02-12T21:42:29.547092500Z] Waiting for completion finished for process 12712
>>     Created policy for F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar
>>     Command line: [f:\projects\official_openjdk\build\windows-x86_64-server-release\images\jdk\bin\java.exe -cp F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\java\security\AccessController\DoPrivAccompliceTest.d;F:\Projects\official_openjdk\test\jdk\java\security\AccessController;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\classes\0\test\lib;F:\Projects\official_openjdk\test\lib;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\javatest.jar;C:\Programs\jtreg-4.2.0-tip\jtreg\lib\jtreg.jar -Xmx512m -XX:MaxRAMPercentage=6 -Djava.io.tmpdir=f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\tmp -ea -esa -Djava.security.manager -Djava.security.policy=F:\Projects\official_openjdk\build\
 windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\java.policy -classpath F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivAccomplice.jar;F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_java_security_AccessController_DoPrivAccompliceTest_java\scratch\0.\DoPrivTest.jar DoPrivTest ]
>>     [2021-02-12T21:42:29.553092400Z] Gathering output for process 10560
>>     [2021-02-12T21:42:29.783092500Z] Waiting for completion for process 10560
>>     [2021-02-12T21:42:29.783092500Z] Waiting for completion finished for process 10560
>>     Output and diagnostic info for process 10560 was saved into 'pid-10560-output.log'
>>     [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560
>>     [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560
>>     [2021-02-12T21:42:29.785092800Z] Waiting for completion for process 10560
>>     [2021-02-12T21:42:29.785092800Z] Waiting for completion finished for process 10560
>>     STDERR:
>>      stdout: [];
>>      stderr: [Exception in thread "main" java.security.AccessControlException: access denied ("java.util.PropertyPermission" "user.name" "read")
>>             at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>>             at java.base/java.security.AccessController.checkPermission(AccessController.java:1036)
>>             at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:408)
>>             at java.base/java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1152)
>>             at java.base/java.lang.System.getProperty(System.java:833)
>>             at DoPrivAccomplice.lambda$go$0(DoPrivAccomplice.java:31)
>>             at java.base/java.security.AccessController.doPrivileged(AccessController.java:312)
>>             at DoPrivAccomplice.go(DoPrivAccomplice.java:30)
>>             at DoPrivTest.main(DoPrivTest.java:29)
>>     ]
>>      exitValue = 1
>> 
>>     java.lang.RuntimeException: 'user' found in stderr
>> 
>>             at jdk.test.lib.process.OutputAnalyzer.shouldNotContain(OutputAnalyzer.java:256)
>>             at DoPrivAccompliceTest.main(DoPrivAccompliceTest.java:112)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>> 
>>     JavaTest Message: Test threw exception: java.lang.RuntimeException: 'user' found in stderr
>> 
>>     JavaTest Message: shutting down test
>> 
>>     STATUS:Failed.`main' threw exception: java.lang.RuntimeException: 'user' found in stderr
>>     
>> Looks like test is not ready for username `user`, which I use locally.
>
> ## tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java
> 
>     make test TEST="jtreg:tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java"
> 
>     STDOUT:
>     [00:56:54.598] Parsing [--jpt-run=jdk.jpackage.tests.UnicodeArgsTest]...
>     [00:56:54.650] jdk.jpackage.tests.UnicodeArgsTest.test8246042 -> [public void jdk.jpackage.tests.UnicodeArgsTest.test8246042(boolean)]
>     [00:56:54.682] Create: UnicodeArgsTest.test8246042(true)
>     [00:56:54.684] Create: UnicodeArgsTest.test8246042(false)
>     [00:56:54.688] [ RUN      ] UnicodeArgsTest.test8246042(false)
>     [00:56:54.693] TRACE: Test string code points: [0x00e9]
>     [00:56:54.875] TRACE: exec: Execute tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)...
>     [00:56:55.996] TRACE: exec: Done. Exit code: 0
>     [00:56:55.997] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code
>     [00:56:56.014] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7)...
>     [00:56:56.188] TRACE: exec: Done. Exit code: 0
>     [00:56:56.188] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7) exited with 0 code
>     [00:56:56.196] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17)...
>     [00:56:56.225] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output
>     [00:57:07.680] Command:
>         jlink --output .\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,java.xml,jdk.xml.dom,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.jsobject,jdk.sctp,java.smartcardio,jdk.jlink,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.naming.rmi,jdk.internal.opt,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.internal.jvmstat,jdk.incubator.foreign,java.instru
 ment,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files
>     [00:57:07.680] Output:
>         WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign
> 
>     [00:57:07.681] Returned: 0
> 
>     [00:57:07.685] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize).
>     [00:57:07.707] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage16485063537873697224".
>     [00:57:07.712] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize).
>     [00:57:07.746] Succeeded in building Windows Application Image package
>     [00:57:07.748] TRACE: exec: Done. Exit code: 0
>     [00:57:07.748] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17) exited with 0 code
>     [00:57:07.766] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package
>     [00:57:07.768] TRACE: assertStringListEquals(1, .\test8246042.9782d070\output\8246042UnicodeArgsTest\app.jpackage.xml)
>     [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] path exists
>     [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] is a directory
>     [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists
>     [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file
>     [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable
>     [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists
>     [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file
>     [00:57:07.780] TRACE: Clearing PATH in environment
>     [00:57:07.780] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1); inherit I/O; in directory [.\test8246042.9782d070]...
>     hello: Environment supports a display
>     hello: Environment supports a desktop
>     [0x0065]
>     jpackage test application
>     args.length: 1
>     e
>     hello: Output file: [appOutput.txt]
>     [00:57:09.302] TRACE: exec: Done. Exit code: 0
>     [00:57:09.302] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1) exited with 0 code
>     [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] path exists
>     [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] is a file
>     [00:57:09.305] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
>     [00:57:09.305] TRACE: assertStringListEquals(1, jpackage test application)
>     [00:57:09.306] TRACE: assertStringListEquals(2, args.length: 1)
>     [00:57:09.307] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
>     [00:57:09.308] [  FAILED  ] UnicodeArgsTest.test8246042(false); checks=15
>     [00:57:09.310] [ RUN      ] UnicodeArgsTest.test8246042(true)
>     [00:57:09.312] TRACE: Test string code points: [0x00e9]
>     [00:57:09.314] TRACE: exec: Execute tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)...
>     [00:57:09.658] TRACE: exec: Done. Exit code: 0
>     [00:57:09.659] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code
>     [00:57:09.661] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7)...
>     [00:57:09.667] TRACE: exec: Done. Exit code: 0
>     [00:57:09.667] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7) exited with 0 code
>     [00:57:09.670] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15)...
>     [00:57:09.670]
>     jpackage argument list:
>     [--input, .\test8246042.b31bae11\input, --dest, .\test8246042.b31bae11\output, --name, 8246042UnicodeArgsTest, --type, app-image, --main-jar, hello.jar, --main-class, Hello, --win-console, --verbose]
> 
>     [00:57:09.679] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output
>     [00:57:18.770] Command:
>         jlink --output .\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,jdk.sctp,jdk.jsobject,java.sql.rowset,jdk.jlink,java.smartcardio,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instru
 ment,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,jdk.jpackage,java.management.rmi,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files
>     [00:57:18.770] Output:
>         WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign
> 
>     [00:57:18.770] Returned: 0
> 
>     [00:57:18.771] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize).
>     [00:57:18.778] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage8738450931736312275".
>     [00:57:18.779] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize).
>     [00:57:18.787] Succeeded in building Windows Application Image package
>     [00:57:18.788] TRACE: exec: Done. Exit code: 0
>     [00:57:18.789] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15) exited with 0 code
>     [00:57:18.804] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package
>     [00:57:18.804] TRACE: assertStringListEquals(1, .\test8246042.b31bae11\output\8246042UnicodeArgsTest\app.jpackage.xml)
>     [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] path exists
>     [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] is a directory
>     [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists
>     [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file
>     [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable
>     [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists
>     [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file
>     [00:57:18.808] TRACE: Clearing PATH in environment
>     [00:57:18.808] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2); inherit I/O; in directory [.\test8246042.b31bae11]...
>     hello: Environment supports a display
>     hello: Environment supports a desktop
>     [0x0065]
>     jpackage test application
>     args.length: 1
>     e
>     hello: Output file: [appOutput.txt]
>     [00:57:20.327] TRACE: exec: Done. Exit code: 0
>     [00:57:20.328] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2) exited with 0 code
>     [00:57:20.328] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] path exists
>     [00:57:20.329] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] is a file
>     [00:57:20.330] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
>     [00:57:20.330] TRACE: assertStringListEquals(1, jpackage test application)
>     [00:57:20.330] TRACE: assertStringListEquals(2, args.length: 1)
>     [00:57:20.330] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
>     [00:57:20.331] [  FAILED  ] UnicodeArgsTest.test8246042(true); checks=15
>     [00:57:20.332] [==========] 2 tests ran
>     [00:57:20.333] [  PASSED  ] 0 tests
>     [00:57:20.334] [  FAILED  ] 2 tests, listed below
>     [00:57:20.335] [  FAILED  ] UnicodeArgsTest.test8246042(false); workDir=[.\test8246042.9782d070]
>     [00:57:20.335] [  FAILED  ] UnicodeArgsTest.test8246042(true); workDir=[.\test8246042.b31bae11]
>     [00:57:20.336] 2 FAILED TESTS
>     STDERR:
>     java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
>             at jdk.jpackage.test.TKit.error(TKit.java:293)
>             at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765)
>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>             at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>             at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>             at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>             at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
>             at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>             at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
>             at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759)
>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225)
>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204)
>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405)
>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417)
>             at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319)
>             at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:67)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145)
>             at jdk.jpackage.test.TestInstance.run(TestInstance.java:230)
>             at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155)
>             at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140)
>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>             at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>             at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137)
>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>             at jdk.jpackage.test.TKit.runTests(TKit.java:136)
>             at jdk.jpackage.test.Main.runTests(Main.java:79)
>             at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>             at jdk.jpackage.test.Main.main(Main.java:75)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>             at java.base/java.lang.Thread.run(Thread.java:831)
>     java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
>             at jdk.jpackage.test.TKit.error(TKit.java:293)
>             at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765)
>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>             at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>             at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>             at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>             at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
>             at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>             at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
>             at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759)
>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225)
>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204)
>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405)
>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417)
>             at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319)
>             at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:65)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145)
>             at jdk.jpackage.test.TestInstance.run(TestInstance.java:230)
>             at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155)
>             at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140)
>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>             at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>             at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137)
>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>             at jdk.jpackage.test.TKit.runTests(TKit.java:136)
>             at jdk.jpackage.test.Main.runTests(Main.java:79)
>             at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>             at jdk.jpackage.test.Main.main(Main.java:75)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>             at java.base/java.lang.Thread.run(Thread.java:831)
>     jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
>             at jdk.jpackage.test.Functional.rethrowUnchecked(Functional.java:161)
>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:107)
>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>             at jdk.jpackage.test.Main.main(Main.java:75)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>             at java.base/java.lang.Thread.run(Thread.java:831)
>     Caused by: java.lang.RuntimeException: 2 FAILED TESTS
>             at jdk.jpackage.test.Main.reportSummary(Main.java:130)
>             at jdk.jpackage.test.Main.runTests(Main.java:90)
>             at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>             ... 8 more
> 
>     JavaTest Message: Test threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
>     JavaTest Message: shutting down test
> 
>     STATUS:Failed.`main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
> 
> Oh. This one is tricky. Will investigate later.

This fours tests pass without problems, when I run them separately.

## sun/security/tools/jarsigner/TimestampCheck.java
## sun/security/tools/keytool/DefaultOptions.java
## sanity/client/SwingSet/src/ColorChooserDemoTest.java
## sanity/client/SwingSet/src/SwingSet2DemoTest.java

    make test TEST="jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java"
    
    Building target 'test' in configuration 'windows-x86_64-server-release'
    Test selection 'jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java', will run:
    * jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
    * jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
    * jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
    * jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java

    Running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
    Passed: sun/security/tools/jarsigner/TimestampCheck.java
    Test results: passed: 1
    Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java\html\report.html
    Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java
    Finished running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
    Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java

    Running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
    Passed: sun/security/tools/keytool/DefaultOptions.java
    Test results: passed: 1
    Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java\html\report.html
    Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java
    Finished running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
    Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java

    Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
    Passed: sanity/client/SwingSet/src/SwingSet2DemoTest.java
    Test results: passed: 1
    Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java\html\report.html
    Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
    Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
    Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java

    Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
    Passed: sanity/client/SwingSet/src/ColorChooserDemoTest.java
    Test results: passed: 1
    Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java\html\report.html
    Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
    Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
    Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java

    ==============================
    Test summary
    ==============================
       TEST                                              TOTAL  PASS  FAIL ERROR
       jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
                                                             1     1     0     0
       jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
                                                             1     1     0     0
       jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
                                                             1     1     0     0
       jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
                                                             1     1     0     0
    ==============================
    TEST SUCCESS

    Finished building target 'test' in configuration 'windows-x86_64-server-release'

-------------

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

From github.com+741251+turbanoff at openjdk.java.net  Sat Feb 13 10:59:38 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sat, 13 Feb 2021 10:59:38 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <h1cjvuqNbm9Chz7atbi8daeCmDWgzzAKdFoHdgngjR8=.543211a7-9513-4d5f-8f45-9b0d300cdf00@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
 <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
 <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>
 <hGiSvYyNa6D0BuKfIh-3CkelapBMNrFaQ_prF3xzPQQ=.64336055-18e5-4428-bc5b-40d484ed18ba@github.com>
 <ADR73RPzLPNb5SY61wNVAQNB0JdNFrXgwms
 dteeicVU=.1c5f04db-c639-4028-b472-c56999c4746c@github.com>
 <h1cjvuqNbm9Chz7atbi8daeCmDWgzzAKdFoHdgngjR8=.543211a7-9513-4d5f-8f45-9b0d300cdf00@github.com>
Message-ID: <emFkGJxXluWeFGg6QcYXtftGN-MGDOgEAcZu-mKF9Lk=.38224ed4-2847-4947-bed4-09d3e437d58b@github.com>

On Sat, 13 Feb 2021 10:20:29 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> ## tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java
>> 
>>     make test TEST="jtreg:tools/jpackage/share/jdk/jpackage/tests/UnicodeArgsTest.java"
>> 
>>     STDOUT:
>>     [00:56:54.598] Parsing [--jpt-run=jdk.jpackage.tests.UnicodeArgsTest]...
>>     [00:56:54.650] jdk.jpackage.tests.UnicodeArgsTest.test8246042 -> [public void jdk.jpackage.tests.UnicodeArgsTest.test8246042(boolean)]
>>     [00:56:54.682] Create: UnicodeArgsTest.test8246042(true)
>>     [00:56:54.684] Create: UnicodeArgsTest.test8246042(false)
>>     [00:56:54.688] [ RUN      ] UnicodeArgsTest.test8246042(false)
>>     [00:56:54.693] TRACE: Test string code points: [0x00e9]
>>     [00:56:54.875] TRACE: exec: Execute tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)...
>>     [00:56:55.996] TRACE: exec: Done. Exit code: 0
>>     [00:56:55.997] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.9782d070\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code
>>     [00:56:56.014] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7)...
>>     [00:56:56.188] TRACE: exec: Done. Exit code: 0
>>     [00:56:56.188] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.9782d070\input\hello.jar -C .\test8246042.9782d070\jar-workdir .](7) exited with 0 code
>>     [00:56:56.196] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17)...
>>     [00:56:56.225] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output
>>     [00:57:07.680] Command:
>>         jlink --output .\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,java.xml,jdk.xml.dom,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,java.sql.rowset,jdk.jsobject,jdk.sctp,java.smartcardio,jdk.jlink,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.naming.rmi,jdk.internal.opt,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.internal.jvmstat,jdk.incubator.foreign,java.instr
 ument,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,java.management.rmi,jdk.jpackage,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files
>>     [00:57:07.680] Output:
>>         WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign
>> 
>>     [00:57:07.681] Returned: 0
>> 
>>     [00:57:07.685] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize).
>>     [00:57:07.707] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage16485063537873697224".
>>     [00:57:07.712] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize).
>>     [00:57:07.746] Succeeded in building Windows Application Image package
>>     [00:57:07.748] TRACE: exec: Done. Exit code: 0
>>     [00:57:07.748] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.9782d070\input --dest .\test8246042.9782d070\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --arguments ? --verbose](17) exited with 0 code
>>     [00:57:07.766] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package
>>     [00:57:07.768] TRACE: assertStringListEquals(1, .\test8246042.9782d070\output\8246042UnicodeArgsTest\app.jpackage.xml)
>>     [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] path exists
>>     [00:57:07.769] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\runtime] is a directory
>>     [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists
>>     [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file
>>     [00:57:07.770] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable
>>     [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists
>>     [00:57:07.771] TRACE: assertTrue(): Check [.\test8246042.9782d070\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file
>>     [00:57:07.780] TRACE: Clearing PATH in environment
>>     [00:57:07.780] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1); inherit I/O; in directory [.\test8246042.9782d070]...
>>     hello: Environment supports a display
>>     hello: Environment supports a desktop
>>     [0x0065]
>>     jpackage test application
>>     args.length: 1
>>     e
>>     hello: Output file: [appOutput.txt]
>>     [00:57:09.302] TRACE: exec: Done. Exit code: 0
>>     [00:57:09.302] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.9782d070\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe](1) exited with 0 code
>>     [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] path exists
>>     [00:57:09.303] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] is a file
>>     [00:57:09.305] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
>>     [00:57:09.305] TRACE: assertStringListEquals(1, jpackage test application)
>>     [00:57:09.306] TRACE: assertStringListEquals(2, args.length: 1)
>>     [00:57:09.307] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
>>     [00:57:09.308] [  FAILED  ] UnicodeArgsTest.test8246042(false); checks=15
>>     [00:57:09.310] [ RUN      ] UnicodeArgsTest.test8246042(true)
>>     [00:57:09.312] TRACE: Test string code points: [0x00e9]
>>     [00:57:09.314] TRACE: exec: Execute tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4)...
>>     [00:57:09.658] TRACE: exec: Done. Exit code: 0
>>     [00:57:09.659] TRACE: assertEquals(0): Check command tool provider [javac -d .\test8246042.b31bae11\jar-workdir F:\Projects\official_openjdk\test\jdk\tools\jpackage\apps\image\Hello.java](4) exited with 0 code
>>     [00:57:09.661] TRACE: exec: Execute tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7)...
>>     [00:57:09.667] TRACE: exec: Done. Exit code: 0
>>     [00:57:09.667] TRACE: assertEquals(0): Check command tool provider [jar -c -f .\test8246042.b31bae11\input\hello.jar -C .\test8246042.b31bae11\jar-workdir .](7) exited with 0 code
>>     [00:57:09.670] TRACE: exec: Execute tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15)...
>>     [00:57:09.670]
>>     jpackage argument list:
>>     [--input, .\test8246042.b31bae11\input, --dest, .\test8246042.b31bae11\output, --name, 8246042UnicodeArgsTest, --type, app-image, --main-jar, hello.jar, --main-class, Hello, --win-console, --verbose]
>> 
>>     [00:57:09.679] Creating app package: 8246042UnicodeArgsTest in F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output
>>     [00:57:18.770] Command:
>>         jlink --output .\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime --module-path f:\\projects\\official_openjdk\\build\\windows-x86_64-server-release\\images\\jdk\\jmods --add-modules jdk.management.jfr,java.rmi,jdk.jdi,jdk.charsets,jdk.xml.dom,java.xml,java.datatransfer,jdk.jstatd,jdk.httpserver,java.desktop,java.security.sasl,jdk.zipfs,java.base,jdk.crypto.ec,jdk.javadoc,jdk.management.agent,jdk.jshell,jdk.editpad,jdk.sctp,jdk.jsobject,java.sql.rowset,jdk.jlink,java.smartcardio,jdk.unsupported,java.security.jgss,java.compiler,jdk.nio.mapmode,jdk.dynalink,jdk.unsupported.desktop,jdk.accessibility,jdk.security.jgss,java.sql,jdk.incubator.vector,java.xml.crypto,java.logging,java.transaction.xa,jdk.jfr,jdk.crypto.cryptoki,jdk.net,java.naming,jdk.internal.ed,java.prefs,java.net.http,jdk.compiler,jdk.internal.opt,jdk.naming.rmi,jdk.jconsole,jdk.attach,jdk.crypto.mscapi,jdk.internal.le,java.management,jdk.jdwp.agent,jdk.incubator.foreign,jdk.internal.jvmstat,java.instr
 ument,jdk.management,jdk.security.auth,java.scripting,jdk.jdeps,jdk.jartool,jdk.jpackage,java.management.rmi,jdk.naming.dns,jdk.localedata --strip-native-commands --strip-debug --no-man-pages --no-header-files
>>     [00:57:18.770] Output:
>>         WARNING: Using incubator modules: jdk.incubator.vector, jdk.incubator.foreign
>> 
>>     [00:57:18.770] Returned: 0
>> 
>>     [00:57:18.771] Using default package resource java48.ico [icon] (add 8246042UnicodeArgsTest.ico to the resource-dir to customize).
>>     [00:57:18.778] Warning: Windows Defender may prevent jpackage from functioning. If there is an issue, it can be addressed by either disabling realtime monitoring, or adding an exclusion for the directory "f:\projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\tmp\jdk.jpackage8738450931736312275".
>>     [00:57:18.779] Using default package resource WinLauncher.template [Template for creating executable properties file] (add 8246042UnicodeArgsTest.properties to the resource-dir to customize).
>>     [00:57:18.787] Succeeded in building Windows Application Image package
>>     [00:57:18.788] TRACE: exec: Done. Exit code: 0
>>     [00:57:18.789] TRACE: assertEquals(0): Check command tool provider [jpackage --input .\test8246042.b31bae11\input --dest .\test8246042.b31bae11\output --name 8246042UnicodeArgsTest --type app-image --main-jar hello.jar --main-class Hello --win-console --verbose](15) exited with 0 code
>>     [00:57:18.804] TRACE: assertStringListEquals(): Check there is only one file with [.jpackage.xml] name in the package
>>     [00:57:18.804] TRACE: assertStringListEquals(1, .\test8246042.b31bae11\output\8246042UnicodeArgsTest\app.jpackage.xml)
>>     [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] path exists
>>     [00:57:18.805] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\runtime] is a directory
>>     [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] path exists
>>     [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] is a file
>>     [00:57:18.806] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe] file is executable
>>     [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] path exists
>>     [00:57:18.807] TRACE: assertTrue(): Check [.\test8246042.b31bae11\output\8246042UnicodeArgsTest\app\8246042UnicodeArgsTest.cfg] is a file
>>     [00:57:18.808] TRACE: Clearing PATH in environment
>>     [00:57:18.808] TRACE: exec: Execute [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2); inherit I/O; in directory [.\test8246042.b31bae11]...
>>     hello: Environment supports a display
>>     hello: Environment supports a desktop
>>     [0x0065]
>>     jpackage test application
>>     args.length: 1
>>     e
>>     hello: Output file: [appOutput.txt]
>>     [00:57:20.327] TRACE: exec: Done. Exit code: 0
>>     [00:57:20.328] TRACE: assertEquals(0): Check command [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0.\test8246042.b31bae11\output\8246042UnicodeArgsTest\8246042UnicodeArgsTest.exe ?](2) exited with 0 code
>>     [00:57:20.328] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] path exists
>>     [00:57:20.329] TRACE: assertTrue(): Check [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] is a file
>>     [00:57:20.330] TRACE: assertStringListEquals(): Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
>>     [00:57:20.330] TRACE: assertStringListEquals(1, jpackage test application)
>>     [00:57:20.330] TRACE: assertStringListEquals(2, args.length: 1)
>>     [00:57:20.330] ERROR: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
>>     [00:57:20.331] [  FAILED  ] UnicodeArgsTest.test8246042(true); checks=15
>>     [00:57:20.332] [==========] 2 tests ran
>>     [00:57:20.333] [  PASSED  ] 0 tests
>>     [00:57:20.334] [  FAILED  ] 2 tests, listed below
>>     [00:57:20.335] [  FAILED  ] UnicodeArgsTest.test8246042(false); workDir=[.\test8246042.9782d070]
>>     [00:57:20.335] [  FAILED  ] UnicodeArgsTest.test8246042(true); workDir=[.\test8246042.b31bae11]
>>     [00:57:20.336] 2 FAILED TESTS
>>     STDERR:
>>     java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.9782d070\appOutput.txt] file
>>             at jdk.jpackage.test.TKit.error(TKit.java:293)
>>             at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765)
>>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>>             at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>>             at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>>             at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>>             at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
>>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
>>             at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>>             at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
>>             at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759)
>>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225)
>>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204)
>>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405)
>>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417)
>>             at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319)
>>             at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:67)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145)
>>             at jdk.jpackage.test.TestInstance.run(TestInstance.java:230)
>>             at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155)
>>             at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140)
>>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>>             at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>>             at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137)
>>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>>             at jdk.jpackage.test.TKit.runTests(TKit.java:136)
>>             at jdk.jpackage.test.Main.runTests(Main.java:79)
>>             at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
>>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>>             at jdk.jpackage.test.Main.main(Main.java:75)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>>     java.lang.AssertionError: (3) Expected [?]. Actual [e]: Check contents of [F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_tools_jpackage_share_jdk_jpackage_tests_UnicodeArgsTest_java\scratch\0\test8246042.b31bae11\appOutput.txt] file
>>             at jdk.jpackage.test.TKit.error(TKit.java:293)
>>             at jdk.jpackage.test.TKit.lambda$assertStringListEquals$20(TKit.java:765)
>>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
>>             at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
>>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>>             at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
>>             at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
>>             at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
>>             at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
>>             at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
>>             at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
>>             at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:759)
>>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:225)
>>             at jdk.jpackage.test.HelloApp.verifyOutputFile(HelloApp.java:204)
>>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:405)
>>             at jdk.jpackage.test.HelloApp$AppOutputVerifier.executeAndVerifyOutput(HelloApp.java:417)
>>             at jdk.jpackage.test.HelloApp.executeLauncherAndVerifyOutput(HelloApp.java:319)
>>             at jdk.jpackage.tests.UnicodeArgsTest.test8246042(UnicodeArgsTest.java:65)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at jdk.jpackage.test.MethodCall.accept(MethodCall.java:145)
>>             at jdk.jpackage.test.TestInstance.run(TestInstance.java:230)
>>             at jdk.jpackage.test.TKit.lambda$ignoreExceptions$6(TKit.java:155)
>>             at jdk.jpackage.test.TKit.lambda$runTests$4(TKit.java:140)
>>             at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
>>             at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
>>             at jdk.jpackage.test.TKit.lambda$runTests$5(TKit.java:137)
>>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>>             at jdk.jpackage.test.TKit.runTests(TKit.java:136)
>>             at jdk.jpackage.test.Main.runTests(Main.java:79)
>>             at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
>>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>>             at jdk.jpackage.test.Main.main(Main.java:75)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>>     jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
>>             at jdk.jpackage.test.Functional.rethrowUnchecked(Functional.java:161)
>>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:107)
>>             at jdk.jpackage.test.TKit.withExtraLogStream(TKit.java:123)
>>             at jdk.jpackage.test.Main.main(Main.java:75)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>             at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>>             at java.base/java.lang.Thread.run(Thread.java:831)
>>     Caused by: java.lang.RuntimeException: 2 FAILED TESTS
>>             at jdk.jpackage.test.Main.reportSummary(Main.java:130)
>>             at jdk.jpackage.test.Main.runTests(Main.java:90)
>>             at jdk.jpackage.test.Main.lambda$main$2(Main.java:75)
>>             at jdk.jpackage.test.Functional$ThrowingRunnable.lambda$toRunnable$0(Functional.java:105)
>>             ... 8 more
>> 
>>     JavaTest Message: Test threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
>>     JavaTest Message: shutting down test
>> 
>>     STATUS:Failed.`main' threw exception: jdk.jpackage.test.Functional$ExceptionBox: java.lang.RuntimeException: 2 FAILED TESTS
>> 
>> Oh. This one is tricky. Will investigate later.
>
> This fours tests pass without problems, when I run them separately.
> 
> ## sun/security/tools/jarsigner/TimestampCheck.java
> ## sun/security/tools/keytool/DefaultOptions.java
> ## sanity/client/SwingSet/src/ColorChooserDemoTest.java
> ## sanity/client/SwingSet/src/SwingSet2DemoTest.java
> 
>     make test TEST="jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java"
>     
>     Building target 'test' in configuration 'windows-x86_64-server-release'
>     Test selection 'jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java', will run:
>     * jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
>     * jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
>     * jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
>     * jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
> 
>     Running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
>     Passed: sun/security/tools/jarsigner/TimestampCheck.java
>     Test results: passed: 1
>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java\html\report.html
>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java
>     Finished running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java
> 
>     Running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
>     Passed: sun/security/tools/keytool/DefaultOptions.java
>     Test results: passed: 1
>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java\html\report.html
>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java
>     Finished running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java
> 
>     Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
>     Passed: sanity/client/SwingSet/src/SwingSet2DemoTest.java
>     Test results: passed: 1
>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java\html\report.html
>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
>     Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
> 
>     Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
>     Passed: sanity/client/SwingSet/src/ColorChooserDemoTest.java
>     Test results: passed: 1
>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java\html\report.html
>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
>     Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
> 
>     ==============================
>     Test summary
>     ==============================
>        TEST                                              TOTAL  PASS  FAIL ERROR
>        jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
>                                                              1     1     0     0
>        jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
>                                                              1     1     0     0
>        jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
>                                                              1     1     0     0
>        jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
>                                                              1     1     0     0
>     ==============================
>     TEST SUCCESS
> 
>     Finished building target 'test' in configuration 'windows-x86_64-server-release'

## jdk/jshell/ToolBasicTest.java
    
    make test TEST="jtreg:jdk/jshell/ToolBasicTest.java"

    STDOUT:
    [TestNG] Running:
      jdk/jshell/ToolBasicTest.java

    config ReplToolTesting.setUp(): success
    test ToolBasicTest.elideStartUpFromList(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.elideStartUpFromSave(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.test8142447(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testAddExports(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testBadClasspath(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testBadModulePath(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testBadSourceJarClasspath(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testClasspathDirectory(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testClasspathJar(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testClasspathUserHomeExpansion(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testConstrainedUpdates(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testCtrlD(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testEnvInStartUp(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testFeedbackNegative(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testFeedbackNormal(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testFeedbackSilent(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testHistoryReference(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testIndent(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testInterrupt(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testLoadingFromArgs(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testModulePath(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testModulePathUserHomeExpansion(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testOpen(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testOpenFileOverHttp(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testOpenLocalFileUrl(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testOpenResource(): failure
    java.lang.AssertionError: user output: printf("%4.2f", Math.PI).
     expected [3.14] but found [3,14]
            at org.testng.Assert.fail(Assert.java:94)
            at org.testng.Assert.failNotEquals(Assert.java:496)
            at org.testng.Assert.assertEquals(Assert.java:125)
            at org.testng.Assert.assertEquals(Assert.java:178)
            at ReplToolTesting.assertOutput(ReplToolTesting.java:529)
            at ReplToolTesting.assertCommand(ReplToolTesting.java:513)
            at ToolBasicTest.lambda$testOpenResource$118(ToolBasicTest.java:559)
            at ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:824)
            at java.base/java.io.PrintStream.write(PrintStream.java:536)
            at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal.processOutputByte(LineDisciplineTerminal.java:253)
            at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal$FilteringOutputStream.write(LineDisciplineTerminal.java:294)
            at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:242)
            at java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:321)
            at java.base/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:325)
            at java.base/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:159)
            at java.base/java.io.OutputStreamWriter.flush(OutputStreamWriter.java:248)
            at java.base/java.io.PrintWriter.flush(PrintWriter.java:396)
            at jdk.internal.le/jdk.internal.org.jline.terminal.impl.AbstractTerminal.flush(AbstractTerminal.java:174)
            at jdk.internal.le/jdk.internal.org.jline.utils.Display.update(Display.java:336)
            at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3943)
            at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3803)
            at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:626)
            at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:454)
            at jdk.jshell/jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:233)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.getInput(JShellTool.java:1263)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1199)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991)
            at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240)
            at ReplToolTesting.testRawRun(ReplToolTesting.java:313)
            at ReplToolTesting.testRaw(ReplToolTesting.java:296)
            at ReplToolTesting.test(ReplToolTesting.java:249)
            at ReplToolTesting.test(ReplToolTesting.java:233)
            at ReplToolTesting.test(ReplToolTesting.java:229)
            at ReplToolTesting.test(ReplToolTesting.java:225)
            at ToolBasicTest.testOpenResource(ToolBasicTest.java:555)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
            at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
            at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
            at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
            at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
            at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
            at org.testng.TestRunner.privateRun(TestRunner.java:773)
            at org.testng.TestRunner.run(TestRunner.java:623)
            at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
            at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
            at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
            at org.testng.SuiteRunner.run(SuiteRunner.java:259)
            at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
            at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
            at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
            at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
            at org.testng.TestNG.run(TestNG.java:1018)
            at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
            at java.base/java.lang.Thread.run(Thread.java:831)
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testRedeclareVariableNoInit(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testRemoteExit(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testRerun(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testRerunIdRange(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testReset(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testSave(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testStartRetain(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testStartSave(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testStartupFileOption(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testStop(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testVarsWithNotActive(): success
    config ReplToolTesting.setUp(): success
    test ToolBasicTest.testWarningUnchecked(): success

    ===============================================
    jdk/jshell/ToolBasicTest.java
    Total tests run: 38, Failures: 1, Skips: 0
    ===============================================

    STDERR:
    java.io.EOFException
            at java.base/java.io.DataInputStream.readInt(DataInputStream.java:398)
            at java.base/java.io.ObjectInputStream$BlockDataInputStream.readInt(ObjectInputStream.java:3381)
            at java.base/java.io.ObjectInputStream.readInt(ObjectInputStream.java:1113)
            at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.readAndReportExecutionResult(StreamingExecutionControl.java:277)
            at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.invoke(StreamingExecutionControl.java:99)
            at jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.invoke(JdiDefaultExecutionControl.java:160)
            at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:943)
            at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:139)
            at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3609)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1330)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1228)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1201)
            at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991)
            at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240)
            at ReplToolTesting.testRawRun(ReplToolTesting.java:313)
            at ReplToolTesting.testRaw(ReplToolTesting.java:296)
            at ReplToolTesting.test(ReplToolTesting.java:249)
            at ReplToolTesting.test(ReplToolTesting.java:233)
            at ReplToolTesting.test(ReplToolTesting.java:229)
            at ReplToolTesting.test(ReplToolTesting.java:225)
            at ToolBasicTest.testRemoteExit(ToolBasicTest.java:680)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
            at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
            at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
            at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
            at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
            at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
            at org.testng.TestRunner.privateRun(TestRunner.java:773)
            at org.testng.TestRunner.run(TestRunner.java:623)
            at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
            at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
            at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
            at org.testng.SuiteRunner.run(SuiteRunner.java:259)
            at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
            at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
            at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
            at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
            at org.testng.TestNG.run(TestNG.java:1018)
            at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
            at java.base/java.lang.Thread.run(Thread.java:831)
    java.lang.Exception: failures: 1
            at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
            at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.base/java.lang.reflect.Method.invoke(Method.java:566)
            at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
            at java.base/java.lang.Thread.run(Thread.java:831)

    JavaTest Message: Test threw exception: java.lang.Exception
    JavaTest Message: shutting down test


    TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1

https://bugs.openjdk.java.net/browse/JDK-8212234 looks like there is already known bug this test.

-------------

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

From jlahoda at openjdk.java.net  Mon Feb 15 08:16:50 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 15 Feb 2021 08:16:50 GMT
Subject: RFR: 8261606: Surprising behavior of step over in String switch
Message-ID: <0a3sZjMZTAs_4DnM4IfyTTLmLzbzNyfV4lq05hCuWQc=.e1ba29e8-8517-4977-b68f-730e39128716@github.com>

Consider code like:
public class Test {
    public static void main(String... args) {
        new Test().test("a");
    }
    private void test(String s) {
        if (s != null) {
            switch (s) {
                case "a":
                    System.out.println("a"); //breakpoint here, and continue with step-over
                    break;
                default:
                    System.out.println("default"); //the program counter will be shown here eventually
            }
        } else {
            System.out.println("null");
        }
    }
} 

Placing breakpoint at the marked line (with `System.out.println("a");`), running debugger and performing step-over, the execution eventually is shown to stop at the line with `System.out.println("default");`.

The reason for this is (roughly) because the switch-over-string is desugared into a block, but that block does not have an end position set. So the LineNumberTable point for the closing bracket of the block is not generated, and hence the last previous point is used, which is the last line of the last case (branch) of the switch.

The proposal is to set the end position for the synthetic block generated for the switch-over-string.

-------------

Commit messages:
 - 8261606: Surprising behavior of step over in String switch

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

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

From alanb at openjdk.java.net  Mon Feb 15 11:49:38 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 15 Feb 2021 11:49:38 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <emFkGJxXluWeFGg6QcYXtftGN-MGDOgEAcZu-mKF9Lk=.38224ed4-2847-4947-bed4-09d3e437d58b@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
 <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
 <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>
 <hGiSvYyNa6D0BuKfIh-3CkelapBMNrFaQ_prF3xzPQQ=.64336055-18e5-4428-bc5b-40d484ed18ba@github.com>
 <ADR73RPzLPNb5SY61wNVAQNB0JdNFrXgwms
 dteeicVU=.1c5f04db-c639-4028-b472-c56999c4746c@github.com>
 <h1cjvuqNbm9Chz7atbi8daeCmDWgzzAKdFoHdgngjR8=.543211a7-9513-4d5f-8f45-9b0d300cdf00@github.com>
 <emFkGJxXluWeFGg6QcYXtftGN-MGDOgEAcZu-mKF9Lk=.38224ed4-2847-4947-bed4-09d3e437d58b@github.com>
Message-ID: <xi_gLEAFRhno-QJ7-t9yN5roj4z8jgj8bSEqynItmMQ=.8dbd6668-ced8-461e-8bca-fb88db59aa6a@github.com>

On Sat, 13 Feb 2021 10:56:32 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> This fours tests pass without problems, when I run them separately.
>> 
>> ## sun/security/tools/jarsigner/TimestampCheck.java
>> ## sun/security/tools/keytool/DefaultOptions.java
>> ## sanity/client/SwingSet/src/ColorChooserDemoTest.java
>> ## sanity/client/SwingSet/src/SwingSet2DemoTest.java
>> 
>>     make test TEST="jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java"
>>     
>>     Building target 'test' in configuration 'windows-x86_64-server-release'
>>     Test selection 'jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java', will run:
>>     * jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
>>     * jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
>>     * jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
>>     * jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
>> 
>>     Running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
>>     Passed: sun/security/tools/jarsigner/TimestampCheck.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java
>>     Finished running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java
>> 
>>     Running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
>>     Passed: sun/security/tools/keytool/DefaultOptions.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java
>>     Finished running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java
>> 
>>     Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
>>     Passed: sanity/client/SwingSet/src/SwingSet2DemoTest.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
>>     Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
>> 
>>     Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
>>     Passed: sanity/client/SwingSet/src/ColorChooserDemoTest.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
>>     Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
>> 
>>     ==============================
>>     Test summary
>>     ==============================
>>        TEST                                              TOTAL  PASS  FAIL ERROR
>>        jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
>>                                                              1     1     0     0
>>        jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
>>                                                              1     1     0     0
>>        jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
>>                                                              1     1     0     0
>>        jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
>>                                                              1     1     0     0
>>     ==============================
>>     TEST SUCCESS
>> 
>>     Finished building target 'test' in configuration 'windows-x86_64-server-release'
>
> ## jdk/jshell/ToolBasicTest.java
>     
>     make test TEST="jtreg:jdk/jshell/ToolBasicTest.java"
> 
>     STDOUT:
>     [TestNG] Running:
>       jdk/jshell/ToolBasicTest.java
> 
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.elideStartUpFromList(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.elideStartUpFromSave(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.test8142447(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testAddExports(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testBadClasspath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testBadModulePath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testBadSourceJarClasspath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testClasspathDirectory(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testClasspathJar(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testClasspathUserHomeExpansion(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testConstrainedUpdates(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testCtrlD(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testEnvInStartUp(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testFeedbackNegative(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testFeedbackNormal(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testFeedbackSilent(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testHistoryReference(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testIndent(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testInterrupt(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testLoadingFromArgs(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testModulePath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testModulePathUserHomeExpansion(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpen(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpenFileOverHttp(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpenLocalFileUrl(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpenResource(): failure
>     java.lang.AssertionError: user output: printf("%4.2f", Math.PI).
>      expected [3.14] but found [3,14]
>             at org.testng.Assert.fail(Assert.java:94)
>             at org.testng.Assert.failNotEquals(Assert.java:496)
>             at org.testng.Assert.assertEquals(Assert.java:125)
>             at org.testng.Assert.assertEquals(Assert.java:178)
>             at ReplToolTesting.assertOutput(ReplToolTesting.java:529)
>             at ReplToolTesting.assertCommand(ReplToolTesting.java:513)
>             at ToolBasicTest.lambda$testOpenResource$118(ToolBasicTest.java:559)
>             at ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:824)
>             at java.base/java.io.PrintStream.write(PrintStream.java:536)
>             at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal.processOutputByte(LineDisciplineTerminal.java:253)
>             at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal$FilteringOutputStream.write(LineDisciplineTerminal.java:294)
>             at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:242)
>             at java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:321)
>             at java.base/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:325)
>             at java.base/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:159)
>             at java.base/java.io.OutputStreamWriter.flush(OutputStreamWriter.java:248)
>             at java.base/java.io.PrintWriter.flush(PrintWriter.java:396)
>             at jdk.internal.le/jdk.internal.org.jline.terminal.impl.AbstractTerminal.flush(AbstractTerminal.java:174)
>             at jdk.internal.le/jdk.internal.org.jline.utils.Display.update(Display.java:336)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3943)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3803)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:626)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:454)
>             at jdk.jshell/jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:233)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.getInput(JShellTool.java:1263)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1199)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240)
>             at ReplToolTesting.testRawRun(ReplToolTesting.java:313)
>             at ReplToolTesting.testRaw(ReplToolTesting.java:296)
>             at ReplToolTesting.test(ReplToolTesting.java:249)
>             at ReplToolTesting.test(ReplToolTesting.java:233)
>             at ReplToolTesting.test(ReplToolTesting.java:229)
>             at ReplToolTesting.test(ReplToolTesting.java:225)
>             at ToolBasicTest.testOpenResource(ToolBasicTest.java:555)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
>             at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
>             at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
>             at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
>             at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
>             at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
>             at org.testng.TestRunner.privateRun(TestRunner.java:773)
>             at org.testng.TestRunner.run(TestRunner.java:623)
>             at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
>             at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
>             at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
>             at org.testng.SuiteRunner.run(SuiteRunner.java:259)
>             at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
>             at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
>             at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
>             at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
>             at org.testng.TestNG.run(TestNG.java:1018)
>             at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRedeclareVariableNoInit(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRemoteExit(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRerun(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRerunIdRange(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testReset(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testSave(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStartRetain(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStartSave(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStartupFileOption(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStop(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testVarsWithNotActive(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testWarningUnchecked(): success
> 
>     ===============================================
>     jdk/jshell/ToolBasicTest.java
>     Total tests run: 38, Failures: 1, Skips: 0
>     ===============================================
> 
>     STDERR:
>     java.io.EOFException
>             at java.base/java.io.DataInputStream.readInt(DataInputStream.java:398)
>             at java.base/java.io.ObjectInputStream$BlockDataInputStream.readInt(ObjectInputStream.java:3381)
>             at java.base/java.io.ObjectInputStream.readInt(ObjectInputStream.java:1113)
>             at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.readAndReportExecutionResult(StreamingExecutionControl.java:277)
>             at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.invoke(StreamingExecutionControl.java:99)
>             at jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.invoke(JdiDefaultExecutionControl.java:160)
>             at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:943)
>             at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:139)
>             at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3609)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1330)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1228)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1201)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240)
>             at ReplToolTesting.testRawRun(ReplToolTesting.java:313)
>             at ReplToolTesting.testRaw(ReplToolTesting.java:296)
>             at ReplToolTesting.test(ReplToolTesting.java:249)
>             at ReplToolTesting.test(ReplToolTesting.java:233)
>             at ReplToolTesting.test(ReplToolTesting.java:229)
>             at ReplToolTesting.test(ReplToolTesting.java:225)
>             at ToolBasicTest.testRemoteExit(ToolBasicTest.java:680)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
>             at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
>             at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
>             at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
>             at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
>             at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
>             at org.testng.TestRunner.privateRun(TestRunner.java:773)
>             at org.testng.TestRunner.run(TestRunner.java:623)
>             at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
>             at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
>             at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
>             at org.testng.SuiteRunner.run(SuiteRunner.java:259)
>             at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
>             at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
>             at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
>             at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
>             at org.testng.TestNG.run(TestNG.java:1018)
>             at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
>     java.lang.Exception: failures: 1
>             at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
> 
>     JavaTest Message: Test threw exception: java.lang.Exception
>     JavaTest Message: shutting down test
> 
> 
>     TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
> 
> https://bugs.openjdk.java.net/browse/JDK-8212234 looks like there is already known bug this test.

@turbanoff Can you run the tests in the en_US locale? I suspect some of these tests can't run in all locales. Also can you check your environment to ensure the file paths for F: are consistent (I suspect you have a mix of f: and F: in the environment).

-------------

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

From jboes at openjdk.java.net  Mon Feb 15 18:18:39 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Mon, 15 Feb 2021 18:18:39 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v8]
In-Reply-To: <emFkGJxXluWeFGg6QcYXtftGN-MGDOgEAcZu-mKF9Lk=.38224ed4-2847-4947-bed4-09d3e437d58b@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <cONOB0wrdWjjltXXAuaH_SYz_ay7AgllB3SN64c8K_I=.d711bc68-c800-45fd-9de5-5bd1c5621430@github.com>
 <SNPiblXpzCPdmntADzdMMqFCO6eSjKOltzwD5MWnipc=.814578a6-ea9b-40b1-bfd8-199324b7281e@github.com>
 <_uFXfNAzlG3COOLDN_bJBEH4n0xtk52RH4jgW0MYF_w=.358107f1-fa87-4b5a-8ded-08248080678f@github.com>
 <JzpZmZbaq1b-bBgth2Wq1YTVQKpP3DbToT4h8N7ofTE=.4490859d-21a1-4cc9-8e8c-a8d067c82989@github.com>
 <y0ZtJNDhwp3A2Jzsszmio6fg0sGSxvk49eZw2cR_kss=.16bf1d32-b7df-4b5b-a3cc-fd8b2d0bebbe@github.com>
 <9ueMq5ar7LfXsQ5hV2wMnVVethu_2kyzuelDPv_8tfk=.b40c37bb-604e-478f-bc01-428694f0d4c9@github.com>
 <KctKgE0hs5s-qmGmNe_tJwW5C-IrvK5i72mO06GZ3v4=.f48f8a2d-a4a9-4074-9350-7cd443f73373@github.com>
 <hGiSvYyNa6D0BuKfIh-3CkelapBMNrFaQ_prF3xzPQQ=.64336055-18e5-4428-bc5b-40d484ed18ba@github.com>
 <ADR73RPzLPNb5SY61wNVAQNB0JdNFrXgwms
 dteeicVU=.1c5f04db-c639-4028-b472-c56999c4746c@github.com>
 <h1cjvuqNbm9Chz7atbi8daeCmDWgzzAKdFoHdgngjR8=.543211a7-9513-4d5f-8f45-9b0d300cdf00@github.com>
 <emFkGJxXluWeFGg6QcYXtftGN-MGDOgEAcZu-mKF9Lk=.38224ed4-2847-4947-bed4-09d3e437d58b@github.com>
Message-ID: <lR915nPeGioI4oTObfzDIcoVACkXvusnR7rF5R86k10=.739f8477-c380-4012-921e-335b937c2aea@github.com>

On Sat, 13 Feb 2021 10:56:32 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> This fours tests pass without problems, when I run them separately.
>> 
>> ## sun/security/tools/jarsigner/TimestampCheck.java
>> ## sun/security/tools/keytool/DefaultOptions.java
>> ## sanity/client/SwingSet/src/ColorChooserDemoTest.java
>> ## sanity/client/SwingSet/src/SwingSet2DemoTest.java
>> 
>>     make test TEST="jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java"
>>     
>>     Building target 'test' in configuration 'windows-x86_64-server-release'
>>     Test selection 'jtreg:sun/security/tools/jarsigner/TimestampCheck.java sun/security/tools/keytool/DefaultOptions.java sanity/client/SwingSet/src/SwingSet2DemoTest.java sanity/client/SwingSet/src/ColorChooserDemoTest.java', will run:
>>     * jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
>>     * jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
>>     * jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
>>     * jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
>> 
>>     Running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
>>     Passed: sun/security/tools/jarsigner/TimestampCheck.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java
>>     Finished running test 'jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_jarsigner_TimestampCheck_java
>> 
>>     Running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
>>     Passed: sun/security/tools/keytool/DefaultOptions.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java
>>     Finished running test 'jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sun_security_tools_keytool_DefaultOptions_java
>> 
>>     Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
>>     Passed: sanity/client/SwingSet/src/SwingSet2DemoTest.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
>>     Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_SwingSet2DemoTest_java
>> 
>>     Running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
>>     Passed: sanity/client/SwingSet/src/ColorChooserDemoTest.java
>>     Test results: passed: 1
>>     Report written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-results\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java\html\report.html
>>     Results written to F:\Projects\official_openjdk\build\windows-x86_64-server-release\test-support\jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
>>     Finished running test 'jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java'
>>     Test report is stored in build/windows-x86_64-server-release/test-results/jtreg_test_jdk_sanity_client_SwingSet_src_ColorChooserDemoTest_java
>> 
>>     ==============================
>>     Test summary
>>     ==============================
>>        TEST                                              TOTAL  PASS  FAIL ERROR
>>        jtreg:test/jdk/sun/security/tools/jarsigner/TimestampCheck.java
>>                                                              1     1     0     0
>>        jtreg:test/jdk/sun/security/tools/keytool/DefaultOptions.java
>>                                                              1     1     0     0
>>        jtreg:test/jdk/sanity/client/SwingSet/src/SwingSet2DemoTest.java
>>                                                              1     1     0     0
>>        jtreg:test/jdk/sanity/client/SwingSet/src/ColorChooserDemoTest.java
>>                                                              1     1     0     0
>>     ==============================
>>     TEST SUCCESS
>> 
>>     Finished building target 'test' in configuration 'windows-x86_64-server-release'
>
> ## jdk/jshell/ToolBasicTest.java
>     
>     make test TEST="jtreg:jdk/jshell/ToolBasicTest.java"
> 
>     STDOUT:
>     [TestNG] Running:
>       jdk/jshell/ToolBasicTest.java
> 
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.elideStartUpFromList(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.elideStartUpFromSave(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.test8142447(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testAddExports(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testBadClasspath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testBadModulePath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testBadSourceJarClasspath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testClasspathDirectory(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testClasspathJar(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testClasspathUserHomeExpansion(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testConstrainedUpdates(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testCtrlD(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testEnvInStartUp(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testFeedbackNegative(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testFeedbackNormal(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testFeedbackSilent(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testHistoryReference(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testIndent(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testInterrupt(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testLoadingFromArgs(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testModulePath(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testModulePathUserHomeExpansion(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpen(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpenFileOverHttp(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpenLocalFileUrl(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testOpenResource(): failure
>     java.lang.AssertionError: user output: printf("%4.2f", Math.PI).
>      expected [3.14] but found [3,14]
>             at org.testng.Assert.fail(Assert.java:94)
>             at org.testng.Assert.failNotEquals(Assert.java:496)
>             at org.testng.Assert.assertEquals(Assert.java:125)
>             at org.testng.Assert.assertEquals(Assert.java:178)
>             at ReplToolTesting.assertOutput(ReplToolTesting.java:529)
>             at ReplToolTesting.assertCommand(ReplToolTesting.java:513)
>             at ToolBasicTest.lambda$testOpenResource$118(ToolBasicTest.java:559)
>             at ReplToolTesting$PromptedCommandOutputStream.write(ReplToolTesting.java:824)
>             at java.base/java.io.PrintStream.write(PrintStream.java:536)
>             at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal.processOutputByte(LineDisciplineTerminal.java:253)
>             at jdk.internal.le/jdk.internal.org.jline.terminal.impl.LineDisciplineTerminal$FilteringOutputStream.write(LineDisciplineTerminal.java:294)
>             at java.base/sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:242)
>             at java.base/sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:321)
>             at java.base/sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:325)
>             at java.base/sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:159)
>             at java.base/java.io.OutputStreamWriter.flush(OutputStreamWriter.java:248)
>             at java.base/java.io.PrintWriter.flush(PrintWriter.java:396)
>             at jdk.internal.le/jdk.internal.org.jline.terminal.impl.AbstractTerminal.flush(AbstractTerminal.java:174)
>             at jdk.internal.le/jdk.internal.org.jline.utils.Display.update(Display.java:336)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3943)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.redisplay(LineReaderImpl.java:3803)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:626)
>             at jdk.internal.le/jdk.internal.org.jline.reader.impl.LineReaderImpl.readLine(LineReaderImpl.java:454)
>             at jdk.jshell/jdk.internal.jshell.tool.ConsoleIOContext.readLine(ConsoleIOContext.java:233)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.getInput(JShellTool.java:1263)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1199)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240)
>             at ReplToolTesting.testRawRun(ReplToolTesting.java:313)
>             at ReplToolTesting.testRaw(ReplToolTesting.java:296)
>             at ReplToolTesting.test(ReplToolTesting.java:249)
>             at ReplToolTesting.test(ReplToolTesting.java:233)
>             at ReplToolTesting.test(ReplToolTesting.java:229)
>             at ReplToolTesting.test(ReplToolTesting.java:225)
>             at ToolBasicTest.testOpenResource(ToolBasicTest.java:555)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
>             at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
>             at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
>             at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
>             at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
>             at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
>             at org.testng.TestRunner.privateRun(TestRunner.java:773)
>             at org.testng.TestRunner.run(TestRunner.java:623)
>             at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
>             at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
>             at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
>             at org.testng.SuiteRunner.run(SuiteRunner.java:259)
>             at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
>             at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
>             at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
>             at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
>             at org.testng.TestNG.run(TestNG.java:1018)
>             at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRedeclareVariableNoInit(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRemoteExit(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRerun(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testRerunIdRange(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testReset(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testSave(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStartRetain(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStartSave(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStartupFileOption(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testStop(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testVarsWithNotActive(): success
>     config ReplToolTesting.setUp(): success
>     test ToolBasicTest.testWarningUnchecked(): success
> 
>     ===============================================
>     jdk/jshell/ToolBasicTest.java
>     Total tests run: 38, Failures: 1, Skips: 0
>     ===============================================
> 
>     STDERR:
>     java.io.EOFException
>             at java.base/java.io.DataInputStream.readInt(DataInputStream.java:398)
>             at java.base/java.io.ObjectInputStream$BlockDataInputStream.readInt(ObjectInputStream.java:3381)
>             at java.base/java.io.ObjectInputStream.readInt(ObjectInputStream.java:1113)
>             at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.readAndReportExecutionResult(StreamingExecutionControl.java:277)
>             at jdk.jshell/jdk.jshell.execution.StreamingExecutionControl.invoke(StreamingExecutionControl.java:99)
>             at jdk.jshell/jdk.jshell.execution.JdiDefaultExecutionControl.invoke(JdiDefaultExecutionControl.java:160)
>             at jdk.jshell/jdk.jshell.Eval.declare(Eval.java:943)
>             at jdk.jshell/jdk.jshell.Eval.eval(Eval.java:139)
>             at jdk.jshell/jdk.jshell.JShell.eval(JShell.java:493)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSource(JShellTool.java:3609)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processSourceCatchingReset(JShellTool.java:1330)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.processInput(JShellTool.java:1228)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.run(JShellTool.java:1201)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellTool.start(JShellTool.java:991)
>             at jdk.jshell/jdk.internal.jshell.tool.JShellToolBuilder.run(JShellToolBuilder.java:240)
>             at ReplToolTesting.testRawRun(ReplToolTesting.java:313)
>             at ReplToolTesting.testRaw(ReplToolTesting.java:296)
>             at ReplToolTesting.test(ReplToolTesting.java:249)
>             at ReplToolTesting.test(ReplToolTesting.java:233)
>             at ReplToolTesting.test(ReplToolTesting.java:229)
>             at ReplToolTesting.test(ReplToolTesting.java:225)
>             at ToolBasicTest.testRemoteExit(ToolBasicTest.java:680)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
>             at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
>             at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
>             at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
>             at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
>             at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
>             at org.testng.TestRunner.privateRun(TestRunner.java:773)
>             at org.testng.TestRunner.run(TestRunner.java:623)
>             at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
>             at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
>             at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
>             at org.testng.SuiteRunner.run(SuiteRunner.java:259)
>             at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
>             at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
>             at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
>             at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
>             at org.testng.TestNG.run(TestNG.java:1018)
>             at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
>     java.lang.Exception: failures: 1
>             at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>             at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>             at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>             at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>             at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:312)
>             at java.base/java.lang.Thread.run(Thread.java:831)
> 
>     JavaTest Message: Test threw exception: java.lang.Exception
>     JavaTest Message: shutting down test
> 
> 
>     TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 1
> 
> https://bugs.openjdk.java.net/browse/JDK-8212234 looks like there is already known bug this test.

Hi @turbanoff, I ran tier 1-3 in our build and test system and can't reproduce the errors, they seem to be specific to the environment, as Alan hinted at. I also ran the jdk_jfr tests, which came back all clear. 
On another note, let's drop the change in sun.net.www.MimeLauncher, it's a jdk-internal class that is no longer used and can likely be removed. I opened a separate issue for that: https://bugs.openjdk.java.net/browse/JDK-8261750.

-------------

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Feb 15 18:33:00 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 15 Feb 2021 18:33:00 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v10]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com>

> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  revert changes from MimeLauncher

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/6a8a3ae6..6614a10f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=08-09

  Stats: 19 lines in 1 file changed: 11 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

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

From mcimadamore at openjdk.java.net  Mon Feb 15 18:53:42 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 15 Feb 2021 18:53:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v10]
In-Reply-To: <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com>
Message-ID: <bGxQrdluW173rFjTwG5zYUl1cZwn8lvGizAGigtKVjY=.b3ddba92-d8f0-48d3-a99e-4a102c447832@github.com>

On Mon, 15 Feb 2021 18:33:00 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   revert changes from MimeLauncher

The changes to sjavac changes look good

-------------

Marked as reviewed by mcimadamore (Reviewer).

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

From alanb at openjdk.java.net  Mon Feb 15 19:25:42 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 15 Feb 2021 19:25:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v10]
In-Reply-To: <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com>
Message-ID: <bE94jmbj13PX9IS1rm73TwDkw1DghCm5yNNNuWkX4wY=.b182fc1e-076e-4951-adae-16834df72cfc@github.com>

On Mon, 15 Feb 2021 18:33:00 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   revert changes from MimeLauncher

src/java.management/share/classes/javax/management/loading/MLet.java line 1149:

> 1147:                      file.deleteOnExit();
> 1148:                      Files.copy(is, file.toPath(), StandardCopyOption.REPLACE_EXISTING);
> 1149:                      if (file.exists()) {

You might have missed the comment from a previous iteration. The files.exists() check goes away when Files.copy succeeds.

-------------

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Feb 15 19:47:00 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 15 Feb 2021 19:47:00 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v11]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@github.com>

> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  remove unnecessary file.exists() check

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/6614a10f..6e71e961

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=09-10

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Feb 15 19:47:01 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 15 Feb 2021 19:47:01 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v10]
In-Reply-To: <bE94jmbj13PX9IS1rm73TwDkw1DghCm5yNNNuWkX4wY=.b182fc1e-076e-4951-adae-16834df72cfc@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <9lTugXVNgsP2Iodc0ZjSw_22QYFfEULBQjWJpsAO538=.cfa40743-69f7-4880-8cae-712fb7343b0b@github.com>
 <bE94jmbj13PX9IS1rm73TwDkw1DghCm5yNNNuWkX4wY=.b182fc1e-076e-4951-adae-16834df72cfc@github.com>
Message-ID: <7bSIORe_urCOaP-rcSwcaRkhFU0rymCRLOk5s3t3PF4=.c340769a-e407-44c1-8704-fc7ea5eb7411@github.com>

On Mon, 15 Feb 2021 19:23:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   revert changes from MimeLauncher
>
> src/java.management/share/classes/javax/management/loading/MLet.java line 1149:
> 
>> 1147:                      file.deleteOnExit();
>> 1148:                      Files.copy(is, file.toPath(), StandardCopyOption.REPLACE_EXISTING);
>> 1149:                      if (file.exists()) {
> 
> You might have missed the comment from a previous iteration. The files.exists() check goes away when Files.copy succeeds.

You are right. Fixed.

-------------

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

From alanb at openjdk.java.net  Tue Feb 16 07:42:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 16 Feb 2021 07:42:40 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v11]
In-Reply-To: <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@github.com>
Message-ID: <VUKHVu4XUJspWcev-cgNUDbKQWjIJZlg3pHgbn8u808=.e291d039-2af1-4d6e-ba17-bc38f8daee54@github.com>

On Mon, 15 Feb 2021 19:47:00 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   remove unnecessary file.exists() check

Thanks for perceiving with this one. I think you've addressed all issues in the latest revision.

-------------

Marked as reviewed by alanb (Reviewer).

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

From jboes at openjdk.java.net  Tue Feb 16 17:23:42 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Tue, 16 Feb 2021 17:23:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com>

On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy

Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed?
https://github.com/openjdk/jdk/pull/1853#discussion_r572815422
https://github.com/openjdk/jdk/pull/1853#discussion_r572380746

-------------

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Feb 16 18:44:42 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 16 Feb 2021 18:44:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v9]
In-Reply-To: <WtXQ3xGo_psAegHONwjHWSSdAGsvsW9yN6eXAGL8Sbc=.c5c0ef89-24c9-428d-a86d-71db7437d6d3@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <oyAwqFESfH7q3wJicuQNF0Hds0Sp69dN5bzxYAIBaOQ=.df45bf24-3f70-457d-9df9-8a5b3022f1e1@github.com>
 <WtXQ3xGo_psAegHONwjHWSSdAGsvsW9yN6eXAGL8Sbc=.c5c0ef89-24c9-428d-a86d-71db7437d6d3@github.com>
Message-ID: <04LMLK3YO1cEPtchQl39EhAgeSN2mvEdQONQg_UzLKc=.7d1ce34f-04b6-4248-ba32-efec0c24b915@github.com>

On Mon, 8 Feb 2021 21:18:44 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   fix review comments
>
> src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 230:
> 
>> 228:                 // Copy the entire input stream into an InputStream that does
>> 229:                 // support mark
>> 230:                 is = new ByteArrayInputStream(is.readAllBytes());
> 
> I don't understand why the check for #markSupported is done there. The InputStream constructor of PKCS7 creates a DataInputStream on the InputStream only to then call #readFully. I can't find a place where a call to #mark happens. Since the InputStream constructor reads all bytes anyway I wonder whether we could remove this if and unconditionally do:
> 
> PKCS7 pkcs7 = new PKCS7(is.readAllBytes());

Good idea. Will improve.
By the way, code in `sun.security.pkcs.PKCS7#PKCS7(java.io.InputStream)`  looks suspicious: it reads only `InputStream.available()` bytes, which doesn't make much sense to me.

-------------

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Feb 16 18:47:42 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 16 Feb 2021 18:47:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v9]
In-Reply-To: <4-2EVrWdbxsKykSlYd3bAuxS7iuzZbxKPEhrE-y_fMk=.986e5094-e940-4a89-a70e-5aad77dde26d@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <oyAwqFESfH7q3wJicuQNF0Hds0Sp69dN5bzxYAIBaOQ=.df45bf24-3f70-457d-9df9-8a5b3022f1e1@github.com>
 <4-2EVrWdbxsKykSlYd3bAuxS7iuzZbxKPEhrE-y_fMk=.986e5094-e940-4a89-a70e-5aad77dde26d@github.com>
Message-ID: <NsXuEr-MY1rbBYudsF_FG2EIDaJY-_QpzqgR4myHQ_g=.ee29d6c1-4eb8-414a-a722-67bb950c3894@github.com>

On Tue, 9 Feb 2021 11:40:09 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   fix review comments
>
> src/java.base/share/classes/java/util/jar/JarInputStream.java line 93:
> 
>> 91:         if (e != null && JarFile.MANIFEST_NAME.equalsIgnoreCase(e.getName())) {
>> 92:             man = new Manifest();
>> 93:             byte[] bytes = new BufferedInputStream(this).readAllBytes();
> 
> I wonder if it makes sense to avoid reading the entire manifest into a byte[] when we don't need to verify the JAR. This may help avoiding some intermediate allocation and copying. This make be noticeable for some of the larger manifests (Java EE, OSGi, ...). A possible implementation may look like this https://github.com/marschall/jdk/commit/c50880ffb18607077c4da3456b27957d1df8edb7.
> 
> In either case since we're calling #readAllBytes I don't see why we are wrapping in a BufferedInputStream rather than calling #readAllBytes directly.

Usage of `BufferedInputStream` removed

-------------

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

From github.com+741251+turbanoff at openjdk.java.net  Tue Feb 16 18:58:57 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 16 Feb 2021 18:58:57 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v12]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <ZbjR8LxLcrLYtzwOCUh2PO9NtNI25iXTQwbpRJb3YKU=.bafdce7c-94ca-41b0-87df-5ab52f03e9c5@github.com>

> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  cleanup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/6e71e961..1b30471d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=10-11

  Stats: 7 lines in 2 files changed: 0 ins; 5 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

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

From jjg at openjdk.java.net  Tue Feb 16 19:52:50 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 16 Feb 2021 19:52:50 GMT
Subject: RFR: JDK-8257925 enable more support for nested inline tags [v3]
In-Reply-To: <8ywNfJMqNdrdBT2BZb52mnwOVO1sHm2gbpYPGVCH6Ss=.a21bd47b-c78f-466e-b936-2518c3d0a54c@github.com>
References: <8ywNfJMqNdrdBT2BZb52mnwOVO1sHm2gbpYPGVCH6Ss=.a21bd47b-c78f-466e-b936-2518c3d0a54c@github.com>
Message-ID: <3C4amaDqXpnMumaAOw87xOv3yQkaheYtkEWpY_PLqb0=.ebc5d158-5034-4501-b48f-4345cd11d3be@github.com>

> Please review an update to improve the support, where appropriate, for nested inline tags. 
> 
> It has always been the case that certain inline tags allow text and HTML to appear within them. With tags like `{@return}` and `{@summary}` it becomes desirable to also generally allow nested inline tags to appear in those places as well. The work for this was started with the support for `{@return}` [JDK-8075778](https://bugs.openjdk.java.net/browse/JDK-8075778), but applying the work more generally was out of scope at the time. This change completes the work that was started then.
> 
> The work can be grouped into 4 parts, in 3 commits.
> 
> ## Commit 1
> 
> * Update `DocCommentParser` to syntactically allow nested inline tags in situations that permit text and HTML
> * Update the downstream code to semantically limit nestg where it does not make sense, and provide new tests to verify the behavior.
> 
> A family of new tests are added, each testing the ability to put an inline tag within another of the same kind, with and without doclint being enabled. In addition, test cases are added placing a simple instance `{@value}` in an enclosing tag: this is a useful case just because the expansion is plain text and therefore valid in all situations.  Additional tests and test cases can be added as needed.
> 
> This commit left the `{@index}` tag generating "bad" code when it was nested. The error was "reference to an undeclared ID". The (temporary) solution was to disable the automatic link checking for this specific subtest.
> 
> ## Commit 2
> 
> * `HtmlDocletWriter` and `TagletWriterImpl ` pass around a pair of booleans `isFirstSentence` and `inSummary` to help determine the output to be generated. Conceptually, a third value is added to that group: a set containing the set of nested tag kinds, so that it is possible to determine the enclosing tags for a tag.  But, rather than add a third parameter to be passed around, the 3 are grouped into a new class `TagletWriterImpl.Context` which encapsulates the two booleans and the new set.  The new class is added in a way to minimize code churn.  No tests are affected by this change: all continue to pass.
> 
> ## Commit 3
> 
> * The new `Context#inTags` field is used to help improve the behavior of nested `{@index}` tags even when used incorrectly, with warnings disabled.  As a result, the temporary change in the first commit to disable automatic link checking in one of the test cases is reverted.
> 
> <hr>
> 
> The introduction of the new Context class is arguably more general than we need at this time, but it clears up some erratic and inconsistent use of the `isFirstSentence` and `inSummary` booleans. The new class also provides a better framework for any complex new inline tags we may add in future. We might want to change the `Set<DocTree.Kind>` to some other collection at some point, if needs be (a stack, for example.) We might also want to move more information into the `Context`, such as the related `Element` that is otherwise ubiquitously passed around.
> 
> The overall cleanup also revealed some latent bugs in the code, that were hidden in some of the tests. Most notable was that there were still some cases were `<` and `>` were not being correctly escaped as `&lt;` and `&gt;` leading to output in some tests of the form `List<String>` !  This triggered a minor cleanup/rewrite of the beginning of `HtmlDocletWriter.seeTagsToContent` which was previously a bit too liberal with the use of `new RawHtml`!  The other minor cleanup was more consistent handling of whitespace at the end of the first sentence, as will be seen in a couple of places in one of the tests that was updated.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge with upstream/master
 - improve handling of nested links
 - fix trailing whitespace
 - neaten alignment in test description
 - use TagletWriterImpl.Context#inTags to modify behavior on a nested {@index} tag
 - initial introduction of TagletWriterImpl.Context
 - JDK-8257925: enable more support for nested inline tags

-------------

Changes: https://git.openjdk.java.net/jdk/pull/2369/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2369&range=02
  Stats: 723 lines in 15 files changed: 637 ins; 21 del; 65 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2369.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2369/head:pull/2369

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

From duke at openjdk.java.net  Tue Feb 16 21:42:40 2021
From: duke at openjdk.java.net (duke)
Date: Tue, 16 Feb 2021 21:42:40 GMT
Subject: Withdrawn: 8066694: Strange code in JavacParser.java
In-Reply-To: <sJOs1F9eRA5wwzx488HkuQcEVdaqlRctC4aH5Eninrk=.6705cef5-c630-441f-8f46-8fd2acb0403f@github.com>
References: <sJOs1F9eRA5wwzx488HkuQcEVdaqlRctC4aH5Eninrk=.6705cef5-c630-441f-8f46-8fd2acb0403f@github.com>
Message-ID: <9ufVjMwcPl1FkzE3v4lXIprGxz86nplitUHRG9sscPI=.a2350ed8-4e74-46e0-a697-d4345562159e@github.com>

On Sun, 20 Dec 2020 13:13:43 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> This code was introduced in main repository under https://bugs.openjdk.java.net/browse/JDK-8006775
> I checked original commit in `type-annotations/langtools` repository: https://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/71f35e4b93a5
> Looks like it's not a merge problem.

This pull request has been closed without being integrated.

-------------

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

From vromero at openjdk.java.net  Wed Feb 17 03:05:42 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 17 Feb 2021 03:05:42 GMT
Subject: RFR: 8261606: Surprising behavior of step over in String switch
In-Reply-To: <0a3sZjMZTAs_4DnM4IfyTTLmLzbzNyfV4lq05hCuWQc=.e1ba29e8-8517-4977-b68f-730e39128716@github.com>
References: <0a3sZjMZTAs_4DnM4IfyTTLmLzbzNyfV4lq05hCuWQc=.e1ba29e8-8517-4977-b68f-730e39128716@github.com>
Message-ID: <WpeHXbwcFV0_kTKu-oUWItO5_m5keLqHsqQzIu4yH64=.ba0cb051-9438-4f05-9553-0b4cf66828ac@github.com>

On Mon, 15 Feb 2021 08:12:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> public class Test {
>     public static void main(String... args) {
>         new Test().test("a");
>     }
>     private void test(String s) {
>         if (s != null) {
>             switch (s) {
>                 case "a":
>                     System.out.println("a"); //breakpoint here, and continue with step-over
>                     break;
>                 default:
>                     System.out.println("default"); //the program counter will be shown here eventually
>             }
>         } else {
>             System.out.println("null");
>         }
>     }
> } 
> 
> Placing breakpoint at the marked line (with `System.out.println("a");`), running debugger and performing step-over, the execution eventually is shown to stop at the line with `System.out.println("default");`.
> 
> The reason for this is (roughly) because the switch-over-string is desugared into a block, but that block does not have an end position set. So the LineNumberTable point for the closing bracket of the block is not generated, and hence the last previous point is used, which is the last line of the last case (branch) of the switch.
> 
> The proposal is to set the end position for the synthetic block generated for the switch-over-string.

looks sensible

-------------

Marked as reviewed by vromero (Reviewer).

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

From duke at openjdk.java.net  Wed Feb 17 07:55:51 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 17 Feb 2021 07:55:51 GMT
Subject: Withdrawn: 8230623: Extract command-line help for -Xlint sub-options
 to new --help-lint
In-Reply-To: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
References: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
Message-ID: <-7YaNt5PcznT7MPtiihkuJ8d0iZJNBGVyMmmnOslWus=.9e754731-d5ed-44f7-8565-24cfb2d52bf9@github.com>

On Sun, 13 Dec 2020 14:20:45 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> This patch splits out the concrete keys of -Xlint into a new option, --help-lint, 
> so that the output of --help-extra is kept clean and concise.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

This pull request has been closed without being integrated.

-------------

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

From duke at openjdk.java.net  Wed Feb 17 19:00:39 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 17 Feb 2021 19:00:39 GMT
Subject: Withdrawn: 8239596: PARAMETER annotation on receiver type does not
 cause error
In-Reply-To: <HIPFxHVe1NJS2dldCZjPosdBxw-cZgpUE-PXc4WZroE=.2f69a16b-017b-44a0-89cd-a0686223c270@github.com>
References: <HIPFxHVe1NJS2dldCZjPosdBxw-cZgpUE-PXc4WZroE=.2f69a16b-017b-44a0-89cd-a0686223c270@github.com>
Message-ID: <rj5TZ-ktP1h-hzN0lqn0Ug045fu_EoSEfuhzAKztbmk=.614e63ae-dbcd-4f11-a35a-abdc46a7d6d0@github.com>

On Wed, 23 Dec 2020 17:05:51 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> `TypeAnnotationsValidator::visitMethodDef`  uses `checkForDeclarationAnnotations` incorrectly so that the check could not work as expected and some related errors are not reported. This patch fixes it and adds a corresponding test case.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

This pull request has been closed without being integrated.

-------------

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

From github.com+741251+turbanoff at openjdk.java.net  Thu Feb 18 07:15:40 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Thu, 18 Feb 2021 07:15:40 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy
In-Reply-To: <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com>
Message-ID: <klPrlAvPsVYcAtWjox3cWGgbEIjbHXoaFtYu7iBPCxc=.22a22c0a-7d04-4abf-b9ff-0e2a423a6b18@github.com>

On Tue, 16 Feb 2021 17:20:37 GMT, Julia Boes <jboes at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy
>
> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed?
> https://github.com/openjdk/jdk/pull/1853#discussion_r572815422
> https://github.com/openjdk/jdk/pull/1853#discussion_r572380746

@FrauBoes fixed in the last commit. Is there any way to de-_integrate_ PR (to include last commit)?

-------------

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

From jboes at openjdk.java.net  Thu Feb 18 10:38:41 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Thu, 18 Feb 2021 10:38:41 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy
In-Reply-To: <klPrlAvPsVYcAtWjox3cWGgbEIjbHXoaFtYu7iBPCxc=.22a22c0a-7d04-4abf-b9ff-0e2a423a6b18@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com>
 <klPrlAvPsVYcAtWjox3cWGgbEIjbHXoaFtYu7iBPCxc=.22a22c0a-7d04-4abf-b9ff-0e2a423a6b18@github.com>
Message-ID: <8pRy5JBdXXoJzu35O6aFHAUALWZ__OBbdganHZKu1FE=.f5fcf42b-eab5-49a6-9450-4942c933f39d@github.com>

On Thu, 18 Feb 2021 07:12:34 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed?
>> https://github.com/openjdk/jdk/pull/1853#discussion_r572815422
>> https://github.com/openjdk/jdk/pull/1853#discussion_r572380746
>
> @FrauBoes fixed in the last commit. Is there any way to de-_integrate_ PR (to include last commit)?

To re-integrate, just run the /integrate command again. 

Before doing that, could someone from security libs acknowledge the changes in their area?

-------------

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

From jjg at openjdk.java.net  Thu Feb 18 18:49:40 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 18 Feb 2021 18:49:40 GMT
Subject: RFR: JDK-8257925 enable more support for nested inline tags [v2]
In-Reply-To: <k5VE_VlKxPvcsjhn6aNqf73F_0iKTzt6SU2AWT-FDkc=.6c2ab4f1-290b-4550-9d7d-af6bb3645411@github.com>
References: <8ywNfJMqNdrdBT2BZb52mnwOVO1sHm2gbpYPGVCH6Ss=.a21bd47b-c78f-466e-b936-2518c3d0a54c@github.com>
 <K6eWyz_Yv4KOTYXkhhYrxFly4avZ9vummGvKPcrplI4=.22c9896d-b887-4a35-a3e4-cb9aa23c1cb3@github.com>
 <k5VE_VlKxPvcsjhn6aNqf73F_0iKTzt6SU2AWT-FDkc=.6c2ab4f1-290b-4550-9d7d-af6bb3645411@github.com>
Message-ID: <ETf3uHZrEprLr0gt8CmOLZQlQey_EbKrl7p_T9IxiNM=.4dbb255d-0392-4b7a-8f96-6404b7a43508@github.com>

On Fri, 12 Feb 2021 13:31:47 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improve handling of nested links
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1082:
> 
>> 1080:                     default -> {
>> 1081:                         assert false;
>> 1082:                         return HtmlTree.EMPTY;
> 
> What is the reason to `assert false` here and in other places instead of, say, always throw a RuntimeException?

This is the general discussion about the use of `assert`, and whether it is better to throw an exception in production code, or "carry on regardless". I wish Java had a should-not-happen statement or at least a ShoudNotHappen exception.

-------------

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

From jjg at openjdk.java.net  Thu Feb 18 18:53:42 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 18 Feb 2021 18:53:42 GMT
Subject: RFR: JDK-8257925 enable more support for nested inline tags [v2]
In-Reply-To: <k5VE_VlKxPvcsjhn6aNqf73F_0iKTzt6SU2AWT-FDkc=.6c2ab4f1-290b-4550-9d7d-af6bb3645411@github.com>
References: <8ywNfJMqNdrdBT2BZb52mnwOVO1sHm2gbpYPGVCH6Ss=.a21bd47b-c78f-466e-b936-2518c3d0a54c@github.com>
 <K6eWyz_Yv4KOTYXkhhYrxFly4avZ9vummGvKPcrplI4=.22c9896d-b887-4a35-a3e4-cb9aa23c1cb3@github.com>
 <k5VE_VlKxPvcsjhn6aNqf73F_0iKTzt6SU2AWT-FDkc=.6c2ab4f1-290b-4550-9d7d-af6bb3645411@github.com>
Message-ID: <PcWjNuKM5W76CI0Bw82E47s2k3Rl7R9IiDfoPxTzCgc=.fbcff31e-75d7-41a2-978b-a96c8b874ffe@github.com>

On Fri, 12 Feb 2021 14:14:42 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improve handling of nested links
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1637:
> 
>> 1635:                 public Boolean visitSee(SeeTree node, Content c) {
>> 1636:                     // we need to pass the DocTreeImpl here, so ignore node
>> 1637:                     result.add(seeTagToContent(element, tag, context));
> 
> Is above comment still correct? Aren't `tag` and `node` the same object?

Yes, updated

-------------

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

From jjg at openjdk.java.net  Thu Feb 18 18:53:41 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 18 Feb 2021 18:53:41 GMT
Subject: RFR: JDK-8257925 enable more support for nested inline tags [v2]
In-Reply-To: <ETf3uHZrEprLr0gt8CmOLZQlQey_EbKrl7p_T9IxiNM=.4dbb255d-0392-4b7a-8f96-6404b7a43508@github.com>
References: <8ywNfJMqNdrdBT2BZb52mnwOVO1sHm2gbpYPGVCH6Ss=.a21bd47b-c78f-466e-b936-2518c3d0a54c@github.com>
 <K6eWyz_Yv4KOTYXkhhYrxFly4avZ9vummGvKPcrplI4=.22c9896d-b887-4a35-a3e4-cb9aa23c1cb3@github.com>
 <k5VE_VlKxPvcsjhn6aNqf73F_0iKTzt6SU2AWT-FDkc=.6c2ab4f1-290b-4550-9d7d-af6bb3645411@github.com>
 <ETf3uHZrEprLr0gt8CmOLZQlQey_EbKrl7p_T9IxiNM=.4dbb255d-0392-4b7a-8f96-6404b7a43508@github.com>
Message-ID: <oSrJySKMDa9V_5DOc2jRxxOKefjT40CYsHFkrFsWRxg=.d06d8f46-5682-4129-b12c-0da1a7dba0e4@github.com>

On Thu, 18 Feb 2021 18:47:16 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java line 1082:
>> 
>>> 1080:                     default -> {
>>> 1081:                         assert false;
>>> 1082:                         return HtmlTree.EMPTY;
>> 
>> What is the reason to `assert false` here and in other places instead of, say, always throw a RuntimeException?
>
> This is the general discussion about the use of `assert`, and whether it is better to throw an exception in production code, or "carry on regardless". I wish Java had a should-not-happen statement or at least a ShoudNotHappen exception.

In this case, `IllegalStateException` is a reasonable alternative

-------------

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

From jjg at openjdk.java.net  Thu Feb 18 18:58:44 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 18 Feb 2021 18:58:44 GMT
Subject: RFR: JDK-8257925 enable more support for nested inline tags [v2]
In-Reply-To: <k5VE_VlKxPvcsjhn6aNqf73F_0iKTzt6SU2AWT-FDkc=.6c2ab4f1-290b-4550-9d7d-af6bb3645411@github.com>
References: <8ywNfJMqNdrdBT2BZb52mnwOVO1sHm2gbpYPGVCH6Ss=.a21bd47b-c78f-466e-b936-2518c3d0a54c@github.com>
 <K6eWyz_Yv4KOTYXkhhYrxFly4avZ9vummGvKPcrplI4=.22c9896d-b887-4a35-a3e4-cb9aa23c1cb3@github.com>
 <k5VE_VlKxPvcsjhn6aNqf73F_0iKTzt6SU2AWT-FDkc=.6c2ab4f1-290b-4550-9d7d-af6bb3645411@github.com>
Message-ID: <ggZCUP9A_Nrm8shmnu9YuZKQdJhWeNcAj-24M4WmMu4=.dc80ba18-a241-492f-9e7f-292e29a6bad9@github.com>

On Fri, 12 Feb 2021 14:25:23 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improve handling of nested links
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java line 165:
> 
>> 163:      */
>> 164:     public TagletWriterImpl(HtmlDocletWriter htmlWriter, boolean isFirstSentence, boolean inSummary) {
>> 165:         super(isFirstSentence);
> 
> To avoid almost identical constructors this one could be implemented as 
> 
>     this(htmlWriter, new Context(isFirstSentence, inSummary));

Good catch

-------------

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

From mullan at openjdk.java.net  Thu Feb 18 19:24:43 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Thu, 18 Feb 2021 19:24:43 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v11]
In-Reply-To: <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@github.com>
Message-ID: <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com>

On Mon, 15 Feb 2021 19:47:00 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   remove unnecessary file.exists() check

src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 228:

> 226:         try {
> 227:             if (is.markSupported() == false) {
> 228:                 // Copy the entire input stream into an InputStream that does

I don't think you should remove lines 228-232. These methods are called by methods of CertificateFactory that take InputStream (which may contain a stream of security data) and they are designed such that they try to read one Certificate, CRL, or CertPath from the InputStream and leave the InputStream ready to parse the next structure instead of consuming all of the bytes. Thus they check if the InputStream supports mark in order to try to preserve that behavior. If mark is not supported, then it's ok to use InputStream.readAllBytes, otherwise, leave the stream as-is.

-------------

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

From jjg at openjdk.java.net  Thu Feb 18 19:44:00 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 18 Feb 2021 19:44:00 GMT
Subject: RFR: JDK-8257925 enable more support for nested inline tags [v4]
In-Reply-To: <8ywNfJMqNdrdBT2BZb52mnwOVO1sHm2gbpYPGVCH6Ss=.a21bd47b-c78f-466e-b936-2518c3d0a54c@github.com>
References: <8ywNfJMqNdrdBT2BZb52mnwOVO1sHm2gbpYPGVCH6Ss=.a21bd47b-c78f-466e-b936-2518c3d0a54c@github.com>
Message-ID: <itOvaJVRumLwOV-LWkGOUdYE32WNXWOBnEts_sO4XK0=.5f859de0-73fd-4368-87c5-81b516132d37@github.com>

> Please review an update to improve the support, where appropriate, for nested inline tags. 
> 
> It has always been the case that certain inline tags allow text and HTML to appear within them. With tags like `{@return}` and `{@summary}` it becomes desirable to also generally allow nested inline tags to appear in those places as well. The work for this was started with the support for `{@return}` [JDK-8075778](https://bugs.openjdk.java.net/browse/JDK-8075778), but applying the work more generally was out of scope at the time. This change completes the work that was started then.
> 
> The work can be grouped into 4 parts, in 3 commits.
> 
> ## Commit 1
> 
> * Update `DocCommentParser` to syntactically allow nested inline tags in situations that permit text and HTML
> * Update the downstream code to semantically limit nestg where it does not make sense, and provide new tests to verify the behavior.
> 
> A family of new tests are added, each testing the ability to put an inline tag within another of the same kind, with and without doclint being enabled. In addition, test cases are added placing a simple instance `{@value}` in an enclosing tag: this is a useful case just because the expansion is plain text and therefore valid in all situations.  Additional tests and test cases can be added as needed.
> 
> This commit left the `{@index}` tag generating "bad" code when it was nested. The error was "reference to an undeclared ID". The (temporary) solution was to disable the automatic link checking for this specific subtest.
> 
> ## Commit 2
> 
> * `HtmlDocletWriter` and `TagletWriterImpl ` pass around a pair of booleans `isFirstSentence` and `inSummary` to help determine the output to be generated. Conceptually, a third value is added to that group: a set containing the set of nested tag kinds, so that it is possible to determine the enclosing tags for a tag.  But, rather than add a third parameter to be passed around, the 3 are grouped into a new class `TagletWriterImpl.Context` which encapsulates the two booleans and the new set.  The new class is added in a way to minimize code churn.  No tests are affected by this change: all continue to pass.
> 
> ## Commit 3
> 
> * The new `Context#inTags` field is used to help improve the behavior of nested `{@index}` tags even when used incorrectly, with warnings disabled.  As a result, the temporary change in the first commit to disable automatic link checking in one of the test cases is reverted.
> 
> <hr>
> 
> The introduction of the new Context class is arguably more general than we need at this time, but it clears up some erratic and inconsistent use of the `isFirstSentence` and `inSummary` booleans. The new class also provides a better framework for any complex new inline tags we may add in future. We might want to change the `Set<DocTree.Kind>` to some other collection at some point, if needs be (a stack, for example.) We might also want to move more information into the `Context`, such as the related `Element` that is otherwise ubiquitously passed around.
> 
> The overall cleanup also revealed some latent bugs in the code, that were hidden in some of the tests. Most notable was that there were still some cases were `<` and `>` were not being correctly escaped as `&lt;` and `&gt;` leading to output in some tests of the form `List<String>` !  This triggered a minor cleanup/rewrite of the beginning of `HtmlDocletWriter.seeTagsToContent` which was previously a bit too liberal with the use of `new RawHtml`!  The other minor cleanup was more consistent handling of whitespace at the end of the first sentence, as will be seen in a couple of places in one of the tests that was updated.

Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2369/files
  - new: https://git.openjdk.java.net/jdk/pull/2369/files/a6f3eb32..bbb98e6b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2369&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2369&range=02-03

  Stats: 39 lines in 5 files changed: 15 ins; 13 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2369.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2369/head:pull/2369

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

From hannesw at openjdk.java.net  Fri Feb 19 07:54:40 2021
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Fri, 19 Feb 2021 07:54:40 GMT
Subject: RFR: JDK-8257925 enable more support for nested inline tags [v4]
In-Reply-To: <itOvaJVRumLwOV-LWkGOUdYE32WNXWOBnEts_sO4XK0=.5f859de0-73fd-4368-87c5-81b516132d37@github.com>
References: <8ywNfJMqNdrdBT2BZb52mnwOVO1sHm2gbpYPGVCH6Ss=.a21bd47b-c78f-466e-b936-2518c3d0a54c@github.com>
 <itOvaJVRumLwOV-LWkGOUdYE32WNXWOBnEts_sO4XK0=.5f859de0-73fd-4368-87c5-81b516132d37@github.com>
Message-ID: <YtOSXf0HGhNysVspGMt5mSz0hyWr4Q8pIu_rZXAqV5o=.b0648eaa-c70d-4a88-b6e0-4aad07a7cc86@github.com>

On Thu, 18 Feb 2021 19:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review an update to improve the support, where appropriate, for nested inline tags. 
>> 
>> It has always been the case that certain inline tags allow text and HTML to appear within them. With tags like `{@return}` and `{@summary}` it becomes desirable to also generally allow nested inline tags to appear in those places as well. The work for this was started with the support for `{@return}` [JDK-8075778](https://bugs.openjdk.java.net/browse/JDK-8075778), but applying the work more generally was out of scope at the time. This change completes the work that was started then.
>> 
>> The work can be grouped into 4 parts, in 3 commits.
>> 
>> ## Commit 1
>> 
>> * Update `DocCommentParser` to syntactically allow nested inline tags in situations that permit text and HTML
>> * Update the downstream code to semantically limit nestg where it does not make sense, and provide new tests to verify the behavior.
>> 
>> A family of new tests are added, each testing the ability to put an inline tag within another of the same kind, with and without doclint being enabled. In addition, test cases are added placing a simple instance `{@value}` in an enclosing tag: this is a useful case just because the expansion is plain text and therefore valid in all situations.  Additional tests and test cases can be added as needed.
>> 
>> This commit left the `{@index}` tag generating "bad" code when it was nested. The error was "reference to an undeclared ID". The (temporary) solution was to disable the automatic link checking for this specific subtest.
>> 
>> ## Commit 2
>> 
>> * `HtmlDocletWriter` and `TagletWriterImpl ` pass around a pair of booleans `isFirstSentence` and `inSummary` to help determine the output to be generated. Conceptually, a third value is added to that group: a set containing the set of nested tag kinds, so that it is possible to determine the enclosing tags for a tag.  But, rather than add a third parameter to be passed around, the 3 are grouped into a new class `TagletWriterImpl.Context` which encapsulates the two booleans and the new set.  The new class is added in a way to minimize code churn.  No tests are affected by this change: all continue to pass.
>> 
>> ## Commit 3
>> 
>> * The new `Context#inTags` field is used to help improve the behavior of nested `{@index}` tags even when used incorrectly, with warnings disabled.  As a result, the temporary change in the first commit to disable automatic link checking in one of the test cases is reverted.
>> 
>> <hr>
>> 
>> The introduction of the new Context class is arguably more general than we need at this time, but it clears up some erratic and inconsistent use of the `isFirstSentence` and `inSummary` booleans. The new class also provides a better framework for any complex new inline tags we may add in future. We might want to change the `Set<DocTree.Kind>` to some other collection at some point, if needs be (a stack, for example.) We might also want to move more information into the `Context`, such as the related `Element` that is otherwise ubiquitously passed around.
>> 
>> The overall cleanup also revealed some latent bugs in the code, that were hidden in some of the tests. Most notable was that there were still some cases were `<` and `>` were not being correctly escaped as `&lt;` and `&gt;` leading to output in some tests of the form `List<String>` !  This triggered a minor cleanup/rewrite of the beginning of `HtmlDocletWriter.seeTagsToContent` which was previously a bit too liberal with the use of `new RawHtml`!  The other minor cleanup was more consistent handling of whitespace at the end of the first sentence, as will be seen in a couple of places in one of the tests that was updated.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Looks good!

-------------

Marked as reviewed by hannesw (Reviewer).

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

From github.com+741251+turbanoff at openjdk.java.net  Fri Feb 19 08:07:42 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Fri, 19 Feb 2021 08:07:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v11]
In-Reply-To: <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@github.com>
 <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com>
Message-ID: <KKuuOtcyAwZLESU78ZnNaF5LmeoQeWzxj-yO-xCj5ZM=.ea9ff05f-ffea-477f-b7eb-b94df1f186f3@github.com>

On Thu, 18 Feb 2021 19:21:45 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   remove unnecessary file.exists() check
>
> src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 228:
> 
>> 226:         try {
>> 227:             if (is.markSupported() == false) {
>> 228:                 // Copy the entire input stream into an InputStream that does
> 
> I don't think you should remove lines 228-232. These methods are called by methods of CertificateFactory that take InputStream (which may contain a stream of security data) and they are designed such that they try to read one Certificate, CRL, or CertPath from the InputStream and leave the InputStream ready to parse the next structure instead of consuming all of the bytes. Thus they check if the InputStream supports mark in order to try to preserve that behavior. If mark is not supported, then it's ok to use InputStream.readAllBytes, otherwise, leave the stream as-is.

As I can see only ByteArrayInputStream is actually passed in `InputStream` in current JDK code:

    PKCS7 pkcs7 = new PKCS7(is.readAllBytes());
        private static List<X509Certificate> parsePKCS7(InputStream is)
            certs = parsePKCS7(is);
                public X509CertPath(InputStream is, String encoding)
                    return new X509CertPath(new ByteArrayInputStream(data), encoding);

    PKCS7 pkcs7 = new PKCS7(is.readAllBytes());
        private static List<X509Certificate> parsePKCS7(InputStream is)
            certs = parsePKCS7(is);
                public X509CertPath(InputStream is, String encoding)
                    this(is, PKIPATH_ENCODING);
                        public X509CertPath(InputStream is) throws CertificateException {
                            return new X509CertPath(new ByteArrayInputStream(encoding));

![???????????](https://user-images.githubusercontent.com/741251/108475587-f4f61080-72a1-11eb-91e0-ac2b98c7c490.png)

Perhaps original marking approach was lost during refactoring?

-------------

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

From duke at openjdk.java.net  Fri Feb 19 12:12:40 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 19 Feb 2021 12:12:40 GMT
Subject: Withdrawn: 8226216: parameter modifiers are not visible to javac
 plugins across compilation boundaries
In-Reply-To: <LMhW8s79WUigTic7qfv9KTCI09Hmkvyn5KVvVgN2_T0=.066483bf-d0a4-40ea-a13e-fb9c7680197f@github.com>
References: <LMhW8s79WUigTic7qfv9KTCI09Hmkvyn5KVvVgN2_T0=.066483bf-d0a4-40ea-a13e-fb9c7680197f@github.com>
Message-ID: <-JWnjkx9n1NnyG9hMlYb-8FDZJXMtRtu1p0YFi-IayA=.b7fc95ee-6ed4-47c5-b3c4-f0c964d3b900@github.com>

On Thu, 24 Dec 2020 16:02:19 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> javac fails to read modifiers from the MethodParameters attribute in class files, which prevents plugins from accessing those modifiers across compilation boundaries. Because `com.sun.tools.javac.jvm.ClassReader` doesn't read and store the access flags(modifiers) from MethodParameters attribute.
> 
> This patch fixes it and adds a corresponding test case. All the existing tests of javac passed locally.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

This pull request has been closed without being integrated.

-------------

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

From duke at openjdk.java.net  Fri Feb 19 12:14:39 2021
From: duke at openjdk.java.net (duke)
Date: Fri, 19 Feb 2021 12:14:39 GMT
Subject: Withdrawn: 8225003: NPE in Attr.attribIdentAsEnumType
In-Reply-To: <PHN_VIHKRaTUTixtxee-2V0k__M7bC5ssjqUNupGPps=.b638e98b-1da4-4490-b033-d8874feed79a@github.com>
References: <PHN_VIHKRaTUTixtxee-2V0k__M7bC5ssjqUNupGPps=.b638e98b-1da4-4490-b033-d8874feed79a@github.com>
Message-ID: <rnB6L1Nbpcy7hQSI_8Mow57rSAUqhUqRWB21On6ipPs=.4710277a-f6c2-4b75-a917-13e96d7af577@github.com>

On Tue, 22 Dec 2020 15:25:08 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> `Attr.attribIdentAsEnumType` uses `enclClass` which would return null if some error types and/or error symbols exist.
> 
> And if we use annotation processor, some errors would be reported to `deferredDiagnosticHandler` and not immediately reported to the users. At this time, the `NullPointerException`(NPE) occurs and all the other work, including that the `deferredDiagnosticHandler` report the errors to users, would not be done. So the user would see the NPE and see that the compiler crashes.
> 
> In other words, the NPE also occurs without the annotation processor. But because the `deferredDiagnosticHandler` is not set without the annotation processor, some other errors would be shown immediately to users and the NPE is not shown when using [these catch code](https://github.com/openjdk/jdk/blob/0849117d5c3a9ae12231262fc0d3366a6e8a458d/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Main.java#L349).
> 
> This patch fixes the NPE and reports the deferred diagnostics to users at the end of the compilation task. Maybe you can consider that this patch solves two bugs:
> 
> 1. [JDK-8225003 NPE in Attr.attribIdentAsEnumType](https://bugs.openjdk.java.net/browse/JDK-8225003)
> 2. Some deferred diagnostics would be not reported to user when the compiler crashes.
> 
> The test case needs to fix these two bugs to pass, so I put them together.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

This pull request has been closed without being integrated.

-------------

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

From mullan at openjdk.java.net  Fri Feb 19 15:05:42 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 19 Feb 2021 15:05:42 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v11]
In-Reply-To: <KKuuOtcyAwZLESU78ZnNaF5LmeoQeWzxj-yO-xCj5ZM=.ea9ff05f-ffea-477f-b7eb-b94df1f186f3@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@github.com>
 <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com>
 <KKuuOtcyAwZLESU78ZnNaF5LmeoQeWzxj-yO-xCj5ZM=.ea9ff05f-ffea-477f-b7eb-b94df1f186f3@github.com>
Message-ID: <fPIf2TG2r9A2gJKfY2q8ifG4fHP7Ed1lHJ1KyExwI-U=.59c5f061-4e65-4db1-8a86-64a97a323b24@github.com>

On Fri, 19 Feb 2021 08:05:06 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/provider/certpath/X509CertPath.java line 228:
>> 
>>> 226:         try {
>>> 227:             if (is.markSupported() == false) {
>>> 228:                 // Copy the entire input stream into an InputStream that does
>> 
>> I don't think you should remove lines 228-232. These methods are called by methods of CertificateFactory that take InputStream (which may contain a stream of security data) and they are designed such that they try to read one Certificate, CRL, or CertPath from the InputStream and leave the InputStream ready to parse the next structure instead of consuming all of the bytes. Thus they check if the InputStream supports mark in order to try to preserve that behavior. If mark is not supported, then it's ok to use InputStream.readAllBytes, otherwise, leave the stream as-is.
>
> As I can see only ByteArrayInputStream is actually passed in `InputStream` in current JDK code:
> 
>     PKCS7 pkcs7 = new PKCS7(is.readAllBytes());
>         private static List<X509Certificate> parsePKCS7(InputStream is)
>             certs = parsePKCS7(is);
>                 public X509CertPath(InputStream is, String encoding)
>                     return new X509CertPath(new ByteArrayInputStream(data), encoding);
> 
>     PKCS7 pkcs7 = new PKCS7(is.readAllBytes());
>         private static List<X509Certificate> parsePKCS7(InputStream is)
>             certs = parsePKCS7(is);
>                 public X509CertPath(InputStream is, String encoding)
>                     this(is, PKIPATH_ENCODING);
>                         public X509CertPath(InputStream is) throws CertificateException {
>                             return new X509CertPath(new ByteArrayInputStream(encoding));
> 
> ![???????????](https://user-images.githubusercontent.com/741251/108475587-f4f61080-72a1-11eb-91e0-ac2b98c7c490.png)
> 
> Perhaps original marking approach was lost during refactoring?

You are right, the code was refactored (way back in 2010) [1] to read one block at a time, so this check on mark can be removed. So, in this case, I think it is probably safe to just pass the InputStream as-is to PKCS7(InputStream), but maybe you can add a comment that says this should always be a ByteArrayInputStream. We can look at refactoring this code and clean it up a bit more later.

[1] https://hg.openjdk.java.net/jdk/jdk/rev/337ae296b6d6

-------------

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

From jjg at openjdk.java.net  Fri Feb 19 16:01:39 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 19 Feb 2021 16:01:39 GMT
Subject: Integrated: JDK-8257925 enable more support for nested inline tags
In-Reply-To: <8ywNfJMqNdrdBT2BZb52mnwOVO1sHm2gbpYPGVCH6Ss=.a21bd47b-c78f-466e-b936-2518c3d0a54c@github.com>
References: <8ywNfJMqNdrdBT2BZb52mnwOVO1sHm2gbpYPGVCH6Ss=.a21bd47b-c78f-466e-b936-2518c3d0a54c@github.com>
Message-ID: <Fzj8S2cA1NixRTN8HThFi1dvZGdRhh4SGzlznxekpgQ=.34a44158-143d-4077-b89c-378498da808b@github.com>

On Wed, 3 Feb 2021 04:28:21 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review an update to improve the support, where appropriate, for nested inline tags. 
> 
> It has always been the case that certain inline tags allow text and HTML to appear within them. With tags like `{@return}` and `{@summary}` it becomes desirable to also generally allow nested inline tags to appear in those places as well. The work for this was started with the support for `{@return}` [JDK-8075778](https://bugs.openjdk.java.net/browse/JDK-8075778), but applying the work more generally was out of scope at the time. This change completes the work that was started then.
> 
> The work can be grouped into 4 parts, in 3 commits.
> 
> ## Commit 1
> 
> * Update `DocCommentParser` to syntactically allow nested inline tags in situations that permit text and HTML
> * Update the downstream code to semantically limit nestg where it does not make sense, and provide new tests to verify the behavior.
> 
> A family of new tests are added, each testing the ability to put an inline tag within another of the same kind, with and without doclint being enabled. In addition, test cases are added placing a simple instance `{@value}` in an enclosing tag: this is a useful case just because the expansion is plain text and therefore valid in all situations.  Additional tests and test cases can be added as needed.
> 
> This commit left the `{@index}` tag generating "bad" code when it was nested. The error was "reference to an undeclared ID". The (temporary) solution was to disable the automatic link checking for this specific subtest.
> 
> ## Commit 2
> 
> * `HtmlDocletWriter` and `TagletWriterImpl ` pass around a pair of booleans `isFirstSentence` and `inSummary` to help determine the output to be generated. Conceptually, a third value is added to that group: a set containing the set of nested tag kinds, so that it is possible to determine the enclosing tags for a tag.  But, rather than add a third parameter to be passed around, the 3 are grouped into a new class `TagletWriterImpl.Context` which encapsulates the two booleans and the new set.  The new class is added in a way to minimize code churn.  No tests are affected by this change: all continue to pass.
> 
> ## Commit 3
> 
> * The new `Context#inTags` field is used to help improve the behavior of nested `{@index}` tags even when used incorrectly, with warnings disabled.  As a result, the temporary change in the first commit to disable automatic link checking in one of the test cases is reverted.
> 
> <hr>
> 
> The introduction of the new Context class is arguably more general than we need at this time, but it clears up some erratic and inconsistent use of the `isFirstSentence` and `inSummary` booleans. The new class also provides a better framework for any complex new inline tags we may add in future. We might want to change the `Set<DocTree.Kind>` to some other collection at some point, if needs be (a stack, for example.) We might also want to move more information into the `Context`, such as the related `Element` that is otherwise ubiquitously passed around.
> 
> The overall cleanup also revealed some latent bugs in the code, that were hidden in some of the tests. Most notable was that there were still some cases were `<` and `>` were not being correctly escaped as `&lt;` and `&gt;` leading to output in some tests of the form `List<String>` !  This triggered a minor cleanup/rewrite of the beginning of `HtmlDocletWriter.seeTagsToContent` which was previously a bit too liberal with the use of `new RawHtml`!  The other minor cleanup was more consistent handling of whitespace at the end of the first sentence, as will be seen in a couple of places in one of the tests that was updated.

This pull request has now been integrated.

Changeset: c4f17a3e
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c4f17a3e
Stats:     733 lines in 15 files changed: 641 ins; 23 del; 69 mod

8257925: enable more support for nested inline tags

Reviewed-by: prappo, hannesw

-------------

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

From duke at openjdk.java.net  Sun Feb 21 17:33:41 2021
From: duke at openjdk.java.net (duke)
Date: Sun, 21 Feb 2021 17:33:41 GMT
Subject: Withdrawn: 8057543: Replace javac's Filter with Predicate (and
 lambdas)
In-Reply-To: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
Message-ID: <v76WCFblOwkuHyh01gN8Nuj9fx0-I022YKBzDqHspro=.ad99d6c7-706e-4275-8838-0fbdd41bd82d@github.com>

On Sun, 27 Dec 2020 14:54:16 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> This patch replaces javac's `Filter` with `Predicate` and sets `Filter` as `Deprecated`.
> Two existing tests failed and I fixed it.
> Currently, all the tests in `test/langtools` passed locally by using the following command.
> 
> make test CONF=linux-x86_64-server-release JOBS=4 TEST=test/langtools/
> 
> Thank you for taking the time to review.
> 
> Best Regards.

This pull request has been closed without being integrated.

-------------

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

From sirinath1978m at gmail.com  Mon Feb 22 09:17:52 2021
From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena)
Date: Mon, 22 Feb 2021 14:47:52 +0530
Subject: JEP draft: Frozen Arrays (Preview)
Message-ID: <CAAfFNYE3G8=PfR8BGgBaCUX1ZP6WhRc8ffayue9PMCgX6m1k+A@mail.gmail.com>

> Since the type system (of both language and VM) gives no way to
distinguish between variables which always refer to mutable arrays, always
refer to frozen arrays, or may refer to a mix of arrays, there will in
general be a dynamic check (for "frozen-ness") as part of any store to an
array (as a[i]=x, or bytecodes like iastore or aastore). This check is
similar to the existing checks for null references (potentially raising
NullPointerException) or reference array subtypes (potentially raising
ArrayStoreException).

I am wondering if the array can have a marker interface `UnFrozenArray` &
`ForzenArray` which can be used to track if the array is frozen or not.
Also perhaps this can be used to eliminate the dynamic check. The array API
can use these maerker interfaces.

Also have a user facing method to create a frozen by birth array. Say `A[]
a = {...}.frozen;`.

Also it would be great if an array related API can migrate away from using
`Object` to a marker say `Array` so that arbitrary objects cannot be passed
to these methods. This change will only break incorrect code where an non
array is passed to an array specific method.

S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210222/060b2dd9/attachment.htm>

From sirinath1978m at gmail.com  Mon Feb 22 09:21:10 2021
From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena)
Date: Mon, 22 Feb 2021 14:51:10 +0530
Subject: JEP draft: Frozen Arrays (Preview)
In-Reply-To: <CAAfFNYE3G8=PfR8BGgBaCUX1ZP6WhRc8ffayue9PMCgX6m1k+A@mail.gmail.com>
References: <CAAfFNYE3G8=PfR8BGgBaCUX1ZP6WhRc8ffayue9PMCgX6m1k+A@mail.gmail.com>
Message-ID: <CAAfFNYEjnUmV2VzXE_3ct_iA2_BmB5kZnFjx+0WXx_iGKHkvKQ@mail.gmail.com>

Minor corrections below:

> Since the type system (of both language and VM) gives no way to
distinguish between variables which always refer to mutable arrays, always
refer to frozen arrays, or may refer to a mix of arrays, there will in
general be a dynamic check (for "frozen-ness") as part of any store to an
array (as a[i]=x, or bytecodes like iastore or aastore). This check is
similar to the existing checks for null references (potentially raising
NullPointerException) or reference array subtypes (potentially raising
ArrayStoreException).

I am wondering if the array can have a marker interface `UnFrozenArray` &
`ForzenArray` which can be used to track if the array is frozen or not.
Also perhaps this can be used to eliminate the dynamic check. The array API
can use these maerker interfaces.

Also have a user facing method to create a frozen by birth array. Say `A[]
a = {...}.frozen;`.

Also it would be great if an array related API can migrate away from using
`Object` to a marker say `Array<T>` or `PrimitiveArray` so that
arbitrary objects cannot be passed to these methods. This change will only
break incorrect code where an non array is passed to an array specific
method.

S

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210222/1221c1db/attachment.htm>

From dcubed at openjdk.java.net  Tue Feb 23 21:45:48 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 23 Feb 2021 21:45:48 GMT
Subject: RFR: 8262265: ProblemList
 jdk/javadoc/doclet/testGeneratedClasses/TestGeneratedClasses.java on Windows
Message-ID: <5ZvLk9WA8HefzdUXyYQAjDk3kmljrtrb_Phane7xgHQ=.1fbe566c-c551-41a2-b24e-5cd0559434f5@github.com>

A trivial fix to ProblemList jdk/javadoc/doclet/testGeneratedClasses/TestGeneratedClasses.java on Windows.

-------------

Commit messages:
 - 8262265: ProblemList jdk/javadoc/doclet/testGeneratedClasses/TestGeneratedClasses.java on Windows

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

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

From rriggs at openjdk.java.net  Tue Feb 23 21:45:48 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 23 Feb 2021 21:45:48 GMT
Subject: RFR: 8262265: ProblemList
 jdk/javadoc/doclet/testGeneratedClasses/TestGeneratedClasses.java on Windows
In-Reply-To: <5ZvLk9WA8HefzdUXyYQAjDk3kmljrtrb_Phane7xgHQ=.1fbe566c-c551-41a2-b24e-5cd0559434f5@github.com>
References: <5ZvLk9WA8HefzdUXyYQAjDk3kmljrtrb_Phane7xgHQ=.1fbe566c-c551-41a2-b24e-5cd0559434f5@github.com>
Message-ID: <CBB0jSwHWRFHB9JMOwRjJodlYs-ecoeUZuZmVLXWzkU=.6e7537f0-a807-46ba-9335-9816ecf175bf@github.com>

On Tue, 23 Feb 2021 21:37:39 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/javadoc/doclet/testGeneratedClasses/TestGeneratedClasses.java on Windows.

Marked as reviewed by rriggs (Reviewer).

-------------

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

From bpb at openjdk.java.net  Tue Feb 23 21:45:48 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 23 Feb 2021 21:45:48 GMT
Subject: RFR: 8262265: ProblemList
 jdk/javadoc/doclet/testGeneratedClasses/TestGeneratedClasses.java on Windows
In-Reply-To: <5ZvLk9WA8HefzdUXyYQAjDk3kmljrtrb_Phane7xgHQ=.1fbe566c-c551-41a2-b24e-5cd0559434f5@github.com>
References: <5ZvLk9WA8HefzdUXyYQAjDk3kmljrtrb_Phane7xgHQ=.1fbe566c-c551-41a2-b24e-5cd0559434f5@github.com>
Message-ID: <hchtLhUKc2HQ_WK6WtniXHbHNOgm8Cvv4jUj0s4ex7k=.6e104618-df66-4c04-99f7-50bb8113541b@github.com>

On Tue, 23 Feb 2021 21:37:39 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/javadoc/doclet/testGeneratedClasses/TestGeneratedClasses.java on Windows.

Marked as reviewed by bpb (Reviewer).

-------------

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

From dcubed at openjdk.java.net  Tue Feb 23 21:45:49 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 23 Feb 2021 21:45:49 GMT
Subject: RFR: 8262265: ProblemList
 jdk/javadoc/doclet/testGeneratedClasses/TestGeneratedClasses.java on Windows
In-Reply-To: <5ZvLk9WA8HefzdUXyYQAjDk3kmljrtrb_Phane7xgHQ=.1fbe566c-c551-41a2-b24e-5cd0559434f5@github.com>
References: <5ZvLk9WA8HefzdUXyYQAjDk3kmljrtrb_Phane7xgHQ=.1fbe566c-c551-41a2-b24e-5cd0559434f5@github.com>
Message-ID: <b2DAlLE59B2jHZyVRkhjBhiIhRRGKFQc6fenmOGc-NA=.8ce24607-a7ed-43ab-971c-9977bf1c1bac@github.com>

On Tue, 23 Feb 2021 21:37:39 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/javadoc/doclet/testGeneratedClasses/TestGeneratedClasses.java on Windows.

@jonathan-gibbons - Please take a look at this ProblemListing when you get the chance.

-------------

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

From dcubed at openjdk.java.net  Tue Feb 23 21:51:41 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 23 Feb 2021 21:51:41 GMT
Subject: Integrated: 8262265: ProblemList
 jdk/javadoc/doclet/testGeneratedClasses/TestGeneratedClasses.java on Windows
In-Reply-To: <5ZvLk9WA8HefzdUXyYQAjDk3kmljrtrb_Phane7xgHQ=.1fbe566c-c551-41a2-b24e-5cd0559434f5@github.com>
References: <5ZvLk9WA8HefzdUXyYQAjDk3kmljrtrb_Phane7xgHQ=.1fbe566c-c551-41a2-b24e-5cd0559434f5@github.com>
Message-ID: <3akW-DSuPPmYfR0OQUaInyBgiE3O2B5ffawDAx6NUd8=.f89593da-2957-4999-8034-a584b62321bc@github.com>

On Tue, 23 Feb 2021 21:37:39 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList jdk/javadoc/doclet/testGeneratedClasses/TestGeneratedClasses.java on Windows.

This pull request has now been integrated.

Changeset: 03e781b4
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/03e781b4
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8262265: ProblemList jdk/javadoc/doclet/testGeneratedClasses/TestGeneratedClasses.java on Windows

Reviewed-by: rriggs, bpb

-------------

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

From dcubed at openjdk.java.net  Tue Feb 23 21:51:39 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Tue, 23 Feb 2021 21:51:39 GMT
Subject: RFR: 8262265: ProblemList
 jdk/javadoc/doclet/testGeneratedClasses/TestGeneratedClasses.java on Windows
In-Reply-To: <CBB0jSwHWRFHB9JMOwRjJodlYs-ecoeUZuZmVLXWzkU=.6e7537f0-a807-46ba-9335-9816ecf175bf@github.com>
References: <5ZvLk9WA8HefzdUXyYQAjDk3kmljrtrb_Phane7xgHQ=.1fbe566c-c551-41a2-b24e-5cd0559434f5@github.com>
 <CBB0jSwHWRFHB9JMOwRjJodlYs-ecoeUZuZmVLXWzkU=.6e7537f0-a807-46ba-9335-9816ecf175bf@github.com>
Message-ID: <IzI3m_nnBvgEN6sgo4gJV7bcsGS7zeNEKH7lcUdtYKE=.6ae3ec45-136b-4d97-9974-0ba6d37a09fe@github.com>

On Tue, 23 Feb 2021 21:41:09 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> A trivial fix to ProblemList jdk/javadoc/doclet/testGeneratedClasses/TestGeneratedClasses.java on Windows.
>
> Marked as reviewed by rriggs (Reviewer).

@RogerRiggs and @bplb - Thanks for the fast reviews!

-------------

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

From jjg at openjdk.java.net  Wed Feb 24 02:13:52 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 24 Feb 2021 02:13:52 GMT
Subject: RFR: JDK-8262269: javadoc test TestGeneratedClasses.java fails on
 Windows
Message-ID: <S_q-b6GoUmZYFoFWQp0GtPnhydW9VA_1Vbv4VoHo5SE=.accd0a64-80c9-4a00-b8cf-41c801582a0c@github.com>

Fix test to work on Windows.

-------------

Commit messages:
 - JDK-8262269: javadoc test TestGeneratedClasses.java fails on Windows

Changes: https://git.openjdk.java.net/jdk/pull/2702/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2702&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262269
  Stats: 4 lines in 2 files changed: 1 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2702.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2702/head:pull/2702

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

From darcy at openjdk.java.net  Wed Feb 24 02:57:39 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 24 Feb 2021 02:57:39 GMT
Subject: RFR: JDK-8262269: javadoc test TestGeneratedClasses.java fails on
 Windows
In-Reply-To: <S_q-b6GoUmZYFoFWQp0GtPnhydW9VA_1Vbv4VoHo5SE=.accd0a64-80c9-4a00-b8cf-41c801582a0c@github.com>
References: <S_q-b6GoUmZYFoFWQp0GtPnhydW9VA_1Vbv4VoHo5SE=.accd0a64-80c9-4a00-b8cf-41c801582a0c@github.com>
Message-ID: <AjA-WDDs64eDDIEVbjxPaaHdvEAXD9GZZvt7S_3e15o=.08c0dcd9-dc25-4893-b238-e8cb2fc81d6d@github.com>

On Wed, 24 Feb 2021 02:09:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Fix test to work on Windows.

Marked as reviewed by darcy (Reviewer).

-------------

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

From jjg at openjdk.java.net  Wed Feb 24 03:53:40 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 24 Feb 2021 03:53:40 GMT
Subject: Integrated: JDK-8262269: javadoc test TestGeneratedClasses.java fails
 on Windows
In-Reply-To: <S_q-b6GoUmZYFoFWQp0GtPnhydW9VA_1Vbv4VoHo5SE=.accd0a64-80c9-4a00-b8cf-41c801582a0c@github.com>
References: <S_q-b6GoUmZYFoFWQp0GtPnhydW9VA_1Vbv4VoHo5SE=.accd0a64-80c9-4a00-b8cf-41c801582a0c@github.com>
Message-ID: <tBUnCI01hu4vpQhbLEw8hxwuOWlqWzMFi-rVYfws2Qk=.c7fc73ae-a4e6-43e0-80aa-6b60c3f47ff5@github.com>

On Wed, 24 Feb 2021 02:09:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Fix test to work on Windows.

This pull request has now been integrated.

Changeset: fac37bf5
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fac37bf5
Stats:     4 lines in 2 files changed: 1 ins; 2 del; 1 mod

8262269: javadoc test TestGeneratedClasses.java fails on Windows

Reviewed-by: darcy

-------------

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

From asotona at openjdk.java.net  Thu Feb 25 11:04:21 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Thu, 25 Feb 2021 11:04:21 GMT
Subject: RFR: 8261457: test/langtools/tools/javac/T8187978 can fail if
 ArrayList class is modified
Message-ID: <9Gypb7MI5OvnofJpPlkPrSeSn4RlVegYVPSbu4RbAdQ=.99a30420-b7ea-4b76-87e6-82c53962b8bf@github.com>

Please review this simple test fix that removes coupling between this test and "live" library code by testing on provided nested classes as suggested in the bug comment.

Thank you,
Adam

-------------

Commit messages:
 - 8261457: test/langtools/tools/javac/T8187978 can fail if ArrayList class is modified

Changes: https://git.openjdk.java.net/jdk/pull/2723/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2723&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261457
  Stats: 45 lines in 2 files changed: 41 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2723.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2723/head:pull/2723

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

From asotona at openjdk.java.net  Thu Feb 25 13:06:04 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Thu, 25 Feb 2021 13:06:04 GMT
Subject: RFR: 8260403: javap should be more robust in the face of invalid
 class files
Message-ID: <JzvQqctn2ewDjd6gW2bfeFZa_6MAqWfC0yGE2kqi1Ew=.02a13b15-3403-404a-b737-b18dedaff34c@github.com>

Please review javap fix to handle java.lang.IllegalStateException for classes with invalid Signature attribute.
New test (T8260403) parsing class with invalid Signature attribute (as described in the bug) is included.
Fix wraps java.lang.IllegalStateException, reports "Error: Invalid value for Signature attribute: <signature debug info>" and continues.

Thanks,
Adam

-------------

Commit messages:
 - 8260403: javap should be more robust in the face of invalid class files

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

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

From vromero at openjdk.java.net  Thu Feb 25 14:22:41 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 25 Feb 2021 14:22:41 GMT
Subject: RFR: 8261457: test/langtools/tools/javac/T8187978 can fail if
 ArrayList class is modified
In-Reply-To: <9Gypb7MI5OvnofJpPlkPrSeSn4RlVegYVPSbu4RbAdQ=.99a30420-b7ea-4b76-87e6-82c53962b8bf@github.com>
References: <9Gypb7MI5OvnofJpPlkPrSeSn4RlVegYVPSbu4RbAdQ=.99a30420-b7ea-4b76-87e6-82c53962b8bf@github.com>
Message-ID: <HuWRznrf_5kJyExlwUCLDmZrO5Zhdy4jDkA96VlqOY0=.19aa7411-de92-4fa5-bd8f-80951a975308@github.com>

On Thu, 25 Feb 2021 10:40:30 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Please review this simple test fix that removes coupling between this test and "live" library code by testing on provided nested classes as suggested in the bug comment.
> 
> Thank you,
> Adam

looks good

-------------

Marked as reviewed by vromero (Reviewer).

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

From adam.sotona at oracle.com  Thu Feb 25 14:44:54 2021
From: adam.sotona at oracle.com (Adam Sotona)
Date: Thu, 25 Feb 2021 14:44:54 +0000
Subject: 8261457: test/langtools/tools/javac/T8187978 can fail if
 ArrayList class is modified
Message-ID: <2F9F4781-6B1F-42F0-AA5D-CAA4F100B3EF@oracle.com>

Hi Vicente,
thanks for the review.

May I ask you also to /sponsor the PR?

Thanks,
Adam

?On 25/02/2021, 15:22, "compiler-dev on behalf of Vicente Romero" <compiler-dev-retn at openjdk.java.net on behalf of vromero at openjdk.java.net> wrote:

    On Thu, 25 Feb 2021 10:40:30 GMT, Adam Sotona <asotona at openjdk.org> wrote:

    > Please review this simple test fix that removes coupling between this test and "live" library code by testing on provided nested classes as suggested in the bug comment.
    > 
    > Thank you,
    > Adam

    looks good

    -------------

    Marked as reviewed by vromero (Reviewer).

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


From asotona at openjdk.java.net  Thu Feb 25 15:02:41 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Thu, 25 Feb 2021 15:02:41 GMT
Subject: Integrated: 8261457: test/langtools/tools/javac/T8187978 can fail if
 ArrayList class is modified
In-Reply-To: <9Gypb7MI5OvnofJpPlkPrSeSn4RlVegYVPSbu4RbAdQ=.99a30420-b7ea-4b76-87e6-82c53962b8bf@github.com>
References: <9Gypb7MI5OvnofJpPlkPrSeSn4RlVegYVPSbu4RbAdQ=.99a30420-b7ea-4b76-87e6-82c53962b8bf@github.com>
Message-ID: <q3j39jQysUVgrTMljgNaGEkGqtJegN1h-eWdLwtvvl0=.94090a9b-01dc-4a2f-9365-1dc5560686ec@github.com>

On Thu, 25 Feb 2021 10:40:30 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Please review this simple test fix that removes coupling between this test and "live" library code by testing on provided nested classes as suggested in the bug comment.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: 2eca17d1
Author:    Adam Sotona <asotona at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2eca17d1
Stats:     45 lines in 2 files changed: 41 ins; 2 del; 2 mod

8261457: test/langtools/tools/javac/T8187978 can fail if ArrayList class is modified

Reviewed-by: vromero

-------------

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

From vromero at openjdk.java.net  Thu Feb 25 15:38:46 2021
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 25 Feb 2021 15:38:46 GMT
Subject: RFR: 8260403: javap should be more robust in the face of invalid
 class files
In-Reply-To: <JzvQqctn2ewDjd6gW2bfeFZa_6MAqWfC0yGE2kqi1Ew=.02a13b15-3403-404a-b737-b18dedaff34c@github.com>
References: <JzvQqctn2ewDjd6gW2bfeFZa_6MAqWfC0yGE2kqi1Ew=.02a13b15-3403-404a-b737-b18dedaff34c@github.com>
Message-ID: <vzSJX22JyCnxY8J2E7Lom97jILFLvIAIMlFjRbGRup8=.912196d8-f4c2-4719-91bb-4a13aed6920a@github.com>

On Thu, 25 Feb 2021 13:01:30 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Please review javap fix to handle java.lang.IllegalStateException for classes with invalid Signature attribute.
> New test (T8260403) parsing class with invalid Signature attribute (as described in the bug) is included.
> Fix wraps java.lang.IllegalStateException, reports "Error: Invalid value for Signature attribute: <signature debug info>" and continues.
> 
> Thanks,
> Adam

lgtm!

-------------

Marked as reviewed by vromero (Reviewer).

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

From adam.sotona at oracle.com  Thu Feb 25 15:58:47 2021
From: adam.sotona at oracle.com (Adam Sotona)
Date: Thu, 25 Feb 2021 15:58:47 +0000
Subject: 8260403: javap should be more robust in the face of invalid class
 files
Message-ID: <537EE7B0-8993-4F51-B595-2D533D6B2261@oracle.com>

Hi Vicente,
thanks for the review.

May I ask you also to /sponsor this PR?

Thanks again,
Adam


?On 25/02/2021, 16:39, "core-libs-dev on behalf of Vicente Romero" <core-libs-dev-retn at openjdk.java.net on behalf of vromero at openjdk.java.net> wrote:

    On Thu, 25 Feb 2021 13:01:30 GMT, Adam Sotona <asotona at openjdk.org> wrote:

    > Please review javap fix to handle java.lang.IllegalStateException for classes with invalid Signature attribute.
    > New test (T8260403) parsing class with invalid Signature attribute (as described in the bug) is included.
    > Fix wraps java.lang.IllegalStateException, reports "Error: Invalid value for Signature attribute: <signature debug info>" and continues.
    > 
    > Thanks,
    > Adam

    lgtm!

    -------------

    Marked as reviewed by vromero (Reviewer).

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


From asotona at openjdk.java.net  Thu Feb 25 16:05:44 2021
From: asotona at openjdk.java.net (Adam Sotona)
Date: Thu, 25 Feb 2021 16:05:44 GMT
Subject: Integrated: 8260403: javap should be more robust in the face of
 invalid class files
In-Reply-To: <JzvQqctn2ewDjd6gW2bfeFZa_6MAqWfC0yGE2kqi1Ew=.02a13b15-3403-404a-b737-b18dedaff34c@github.com>
References: <JzvQqctn2ewDjd6gW2bfeFZa_6MAqWfC0yGE2kqi1Ew=.02a13b15-3403-404a-b737-b18dedaff34c@github.com>
Message-ID: <_1YneenbAHwp4WWtFeBT9CzGi1POxFNQD1bti_Mblvc=.31bc4194-bf92-4756-ae70-20bab423875b@github.com>

On Thu, 25 Feb 2021 13:01:30 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Please review javap fix to handle java.lang.IllegalStateException for classes with invalid Signature attribute.
> New test (T8260403) parsing class with invalid Signature attribute (as described in the bug) is included.
> Fix wraps java.lang.IllegalStateException, reports "Error: Invalid value for Signature attribute: <signature debug info>" and continues.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 7d4f60b1
Author:    Adam Sotona <asotona at openjdk.org>
Committer: Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7d4f60b1
Stats:     165 lines in 3 files changed: 164 ins; 0 del; 1 mod

8260403: javap should be more robust in the face of invalid class files

Reviewed-by: vromero

-------------

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

From jjg at openjdk.java.net  Thu Feb 25 21:40:56 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 25 Feb 2021 21:40:56 GMT
Subject: RFR: JDK-8262421: doclint warnings in jdk.compiler module
Message-ID: <BaD9CVWikRLRmSk4INzpBxxm1MvOgQr-P4ogoCBGgck=.076b5ec1-7636-4607-9842-b9080451b6c9@github.com>

Please review this doc fix to provide a couple of missing `@param` tags

-------------

Commit messages:
 - JDK-8262421: doclint warnings in jdk.compiler module

Changes: https://git.openjdk.java.net/jdk/pull/2731/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2731&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262421
  Stats: 10 lines in 2 files changed: 6 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2731.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2731/head:pull/2731

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

From iris at openjdk.java.net  Thu Feb 25 21:48:39 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 25 Feb 2021 21:48:39 GMT
Subject: RFR: JDK-8262421: doclint warnings in jdk.compiler module
In-Reply-To: <BaD9CVWikRLRmSk4INzpBxxm1MvOgQr-P4ogoCBGgck=.076b5ec1-7636-4607-9842-b9080451b6c9@github.com>
References: <BaD9CVWikRLRmSk4INzpBxxm1MvOgQr-P4ogoCBGgck=.076b5ec1-7636-4607-9842-b9080451b6c9@github.com>
Message-ID: <gppLVvDd3zc8WIAFAKOmDHoBXJXyUYzVq8OJ1fEFIaE=.2ad26a26-7229-4636-9e52-e2c9436296f7@github.com>

On Thu, 25 Feb 2021 21:37:01 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review this doc fix to provide a couple of missing `@param` tags

Marked as reviewed by iris (Reviewer).

-------------

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

From darcy at openjdk.java.net  Thu Feb 25 22:08:39 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 25 Feb 2021 22:08:39 GMT
Subject: RFR: JDK-8262421: doclint warnings in jdk.compiler module
In-Reply-To: <BaD9CVWikRLRmSk4INzpBxxm1MvOgQr-P4ogoCBGgck=.076b5ec1-7636-4607-9842-b9080451b6c9@github.com>
References: <BaD9CVWikRLRmSk4INzpBxxm1MvOgQr-P4ogoCBGgck=.076b5ec1-7636-4607-9842-b9080451b6c9@github.com>
Message-ID: <toWtui7AHI6vG2PMzYQ7rUwIkkYOJ-wq08NUTgBU4Ss=.324a15cc-2b65-499e-bf5c-b2082f9ccc07@github.com>

On Thu, 25 Feb 2021 21:37:01 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review this doc fix to provide a couple of missing `@param` tags

Marked as reviewed by darcy (Reviewer).

-------------

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

From jjg at openjdk.java.net  Thu Feb 25 22:31:41 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 25 Feb 2021 22:31:41 GMT
Subject: Integrated: JDK-8262421: doclint warnings in jdk.compiler module
In-Reply-To: <BaD9CVWikRLRmSk4INzpBxxm1MvOgQr-P4ogoCBGgck=.076b5ec1-7636-4607-9842-b9080451b6c9@github.com>
References: <BaD9CVWikRLRmSk4INzpBxxm1MvOgQr-P4ogoCBGgck=.076b5ec1-7636-4607-9842-b9080451b6c9@github.com>
Message-ID: <De1NL58YGHpPLU5bGSp4pT1dUoD277jzRa_PHzhV5-4=.0ee136a7-68bc-49f8-8176-ceebb525912c@github.com>

On Thu, 25 Feb 2021 21:37:01 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review this doc fix to provide a couple of missing `@param` tags

This pull request has now been integrated.

Changeset: 82565170
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/82565170
Stats:     10 lines in 2 files changed: 6 ins; 1 del; 3 mod

8262421: doclint warnings in jdk.compiler module

Reviewed-by: iris, darcy

-------------

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

From bsrbnd at gmail.com  Fri Feb 26 13:07:14 2021
From: bsrbnd at gmail.com (B. Blaser)
Date: Fri, 26 Feb 2021 14:07:14 +0100
Subject: [Ask for sponsoring] Fix another NPE in
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:571)
In-Reply-To: <4ef2c9d0-cf0c-bec9-f0e0-76a439005163@oracle.com>
References: <CAM1U-w_DyumchOqfy5Hn4FwWtW-e7p=o399neaHXcS_ZAL9H4Q@mail.gmail.com>
 <CAEgw74DWC5zK5vsKnm-ajWChachDZ2xNc4Yv7en3mWOMUFX79w@mail.gmail.com>
 <CAM1U-w99wL6JLhLSMs9ymY4PYX4cNx+rW-zhjFgjbNv0BiREPA@mail.gmail.com>
 <CAEgw74BUQSvn+gFCZ91ciT2qcTOrmTpT=iyi=mSgN8GRJLv8sQ@mail.gmail.com>
 <4ef2c9d0-cf0c-bec9-f0e0-76a439005163@oracle.com>
Message-ID: <CAEgw74CRVGeyB0_-H1RaohKpMqpekGAYQB_BZ9Kvu3gWOtPiNQ@mail.gmail.com>

Hi,

It seems the following fix is still not integrated although the pull
request has been reviewed and looks ready for integration:

https://git.openjdk.java.net/jdk/pull/1479

Is any sponsor available?

Thanks,
Bernard

On Wed, 23 Dec 2020 at 20:39, Jonathan Gibbons
<jonathan.gibbons at oracle.com> wrote:
>
> Bernard, Jia,
>
> You need an expert in this part of the code to do the review, and the likely
> experts are on vacation through the end of the year and may not be able
> to respond before the first week of next year.
>
> As a matter of policy, if folk (you+reviewers) think this should go in 16,
> you need to file the PR against the jdk16 repo. From there, it will
> eventually
> and automatically be forward-ported to the main jdk rep.
>
> Note there will only be a limited window in the new year to fix bugs in 16.
> See the schedule for JDK 16 here:
> https://openjdk.java.net/projects/jdk/16/
>
> -- Jon
>
> On 12/23/20 7:32 AM, B. Blaser wrote:
> > Hi Jia,
> >
> > On Wed, 23 Dec 2020 at 05:49, JiaYanwei <jiaywe at gmail.com> wrote:
> >> Great! I think it's the best solution and can also be directly backported to 16, 11 & 8.
> >>
> >> Should I close (i.e. stop/cancel) the Github PR, or may I commit this code with you(B. Blaser) as the author - just like what Jan Lahoda did in Github PR 1221?
> > Thanks for your feedback, I filed
> > https://bugs.openjdk.java.net/browse/JDK-8258897 and assigned it to
> > Jan (I hope he won't mind). So, I'll let him or maybe Jon advise on
> > what to do with the pull request.
> >
> > Regards,
> > Bernard

From jan.lahoda at oracle.com  Fri Feb 26 13:09:24 2021
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 26 Feb 2021 14:09:24 +0100
Subject: [External] : Re: [Ask for sponsoring] Fix another NPE in
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:571)
In-Reply-To: <CAEgw74CRVGeyB0_-H1RaohKpMqpekGAYQB_BZ9Kvu3gWOtPiNQ@mail.gmail.com>
References: <CAM1U-w_DyumchOqfy5Hn4FwWtW-e7p=o399neaHXcS_ZAL9H4Q@mail.gmail.com>
 <CAEgw74DWC5zK5vsKnm-ajWChachDZ2xNc4Yv7en3mWOMUFX79w@mail.gmail.com>
 <CAM1U-w99wL6JLhLSMs9ymY4PYX4cNx+rW-zhjFgjbNv0BiREPA@mail.gmail.com>
 <CAEgw74BUQSvn+gFCZ91ciT2qcTOrmTpT=iyi=mSgN8GRJLv8sQ@mail.gmail.com>
 <4ef2c9d0-cf0c-bec9-f0e0-76a439005163@oracle.com>
 <CAEgw74CRVGeyB0_-H1RaohKpMqpekGAYQB_BZ9Kvu3gWOtPiNQ@mail.gmail.com>
Message-ID: <18d6c0b9-cca2-17e2-83dc-f8d890390efc@oracle.com>

Done. Sorry I missed it.


Jan


On 26. 02. 21 14:07, B. Blaser wrote:
> Hi,
>
> It seems the following fix is still not integrated although the pull
> request has been reviewed and looks ready for integration:
>
> https://git.openjdk.java.net/jdk/pull/1479
>
> Is any sponsor available?
>
> Thanks,
> Bernard
>
> On Wed, 23 Dec 2020 at 20:39, Jonathan Gibbons
> <jonathan.gibbons at oracle.com> wrote:
>> Bernard, Jia,
>>
>> You need an expert in this part of the code to do the review, and the likely
>> experts are on vacation through the end of the year and may not be able
>> to respond before the first week of next year.
>>
>> As a matter of policy, if folk (you+reviewers) think this should go in 16,
>> you need to file the PR against the jdk16 repo. From there, it will
>> eventually
>> and automatically be forward-ported to the main jdk rep.
>>
>> Note there will only be a limited window in the new year to fix bugs in 16.
>> See the schedule for JDK 16 here:
>> https://openjdk.java.net/projects/jdk/16/
>>
>> -- Jon
>>
>> On 12/23/20 7:32 AM, B. Blaser wrote:
>>> Hi Jia,
>>>
>>> On Wed, 23 Dec 2020 at 05:49, JiaYanwei <jiaywe at gmail.com> wrote:
>>>> Great! I think it's the best solution and can also be directly backported to 16, 11 & 8.
>>>>
>>>> Should I close (i.e. stop/cancel) the Github PR, or may I commit this code with you(B. Blaser) as the author - just like what Jan Lahoda did in Github PR 1221?
>>> Thanks for your feedback, I filed
>>> https://bugs.openjdk.java.net/browse/JDK-8258897 and assigned it to
>>> Jan (I hope he won't mind). So, I'll let him or maybe Jon advise on
>>> what to do with the pull request.
>>>
>>> Regards,
>>> Bernard

From github.com+3896345+hltj at openjdk.java.net  Fri Feb 26 13:12:45 2021
From: github.com+3896345+hltj at openjdk.java.net (Jia Yanwei)
Date: Fri, 26 Feb 2021 13:12:45 GMT
Subject: Integrated: 8258897: wrong translation of capturing local classes
 inside nested lambdas
In-Reply-To: <kqt3eLtYBwA_b8d-7Rqa166hJ-j1h1RIhVmSPBmkDCw=.70768c3c-9070-4993-9627-88dd9959189b@github.com>
References: <kqt3eLtYBwA_b8d-7Rqa166hJ-j1h1RIhVmSPBmkDCw=.70768c3c-9070-4993-9627-88dd9959189b@github.com>
Message-ID: <FIU2TG_JJ5klgMqxNSmyCDiSH9vCnnymSyLap29wfqU=.39f723d6-0ca3-4e78-8e07-de3ec2e0e77a@github.com>

On Fri, 27 Nov 2020 12:32:21 GMT, Jia Yanwei <github.com+3896345+hltj at openjdk.org> wrote:

> **Issue:**
> `javac` crashes with a NPE when compiling such code:
> - a local class captured a reference type local variable of a enclosed lambda (which contains multiple local variables with different types)
> - instance the local class in a nested lambda
> 
> Affects all versions from Java 8 to 16-ea, here is a example output with OpenJDK 15.0.1:
> 
> An exception has occurred in the compiler (15.0.1). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.NullPointerException: Cannot read field "sym" because "this.lvar[1]" is null
>     at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:571)
>     at jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.load(Items.java:399)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:889)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:1942)
>     at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1800)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:864)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1723)
>     at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1532)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:618)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:669)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1084)
>     at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1047)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:954)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:917)
>     at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:893)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2395)
>     at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:756)
>     at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1644)
>     at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1612)
>     at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973)
>     at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317)
>     at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
>     at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:59)
>     at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:45)
> printing javac parameters to: /tmp/javac.20201126_141249.args
> 
> The minimal reproducing code is:
> 
>  java
> class Main {
>     static Runnable runnable = () -> {
>         boolean b0 = false;
>         String s0 = "hello";
> 
>         class Local {
>             int i = s0.length();
>         }
> 
>         Runnable dummy = () -> new Local();
>     };
> }
> 
> If the captured variable is a primitive type, the code will compile but cause a runtime crash at startup. e.g.:
> 
>  java
> public class CaptureInt {
>     static Runnable runnable = () -> {
>         boolean b0 = false;
>         int i0 = 5;
> 
>         class Local {
>             int i = i0 + 2;
>         }
> 
>         Runnable dummy = () -> new Local();
>     };
> 
>     public static void main(String args[]) {
>     }
> }
> 
> **Reason & Experimental solution:**
> 
> During compilation, the captured variable was correctly synthetized as a synthetic argument in the synthetic methods for the nested lambda after `desugar()`. 
> But the synthetic argument was not used when loading free variables, and it always use the original symbol for the original variable as if not in a nested lambda.
> My experimental solution is substituting the symbols in free variables that were captured as synthetic arguments in nested lambda.
> I'm not sure whether the code style as well as the solution itself are appropriate. Welcome any advice and better solution.

This pull request has now been integrated.

Changeset: de3f519d
Author:    hltj <jiaywe at gmail.com>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/de3f519d
Stats:     192 lines in 4 files changed: 190 ins; 0 del; 2 mod

8258897: wrong translation of capturing local classes inside nested lambdas

Co-authored-by: Bernard Blaser <bsrbnd at openjdk.org>
Reviewed-by: jlahoda

-------------

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

From jpai at openjdk.java.net  Fri Feb 26 17:08:58 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 26 Feb 2021 17:08:58 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
Message-ID: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>

Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?

The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.

As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.

The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).

The commit also includes a jtreg testcase which verifies the usage of this new option.

-------------

Commit messages:
 - 8173970: jar tool should have a way to extract to a directory

Changes: https://git.openjdk.java.net/jdk/pull/2752/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2752&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8173970
  Stats: 268 lines in 4 files changed: 262 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2752.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2752/head:pull/2752

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

From lance.andersen at oracle.com  Fri Feb 26 19:47:32 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 26 Feb 2021 19:47:32 +0000
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>

Hi Jaikiran,

Thank you for  the proposed patch.

Assuming there is consensus to add support for this enhancement, I think we need to discuss what is the correct option.

The jar tool borrows -C from tar for creating/updating a jar and the -C option is also a valid option when extracting files from a tar file.

Perhaps keeping symmetry with tar and extend support for -C when extracting a jar file would be a better way forward.   Let?s give time for additional input.

I believe this would also warrant a CSR to be created as well as updates to the jar man page.

Best
Lance

p.s. I think it would be useful in the future to start the discussion on core-libs-dev prior to creating a PR (or leave it as a draft PR) for a feature request.

On Feb 26, 2021, at 12:08 PM, Jaikiran Pai <jpai at openjdk.java.net<mailto:jpai at openjdk.java.net>> wrote:

Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?

The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.

As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.

The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).

The commit also includes a jtreg testcase which verifies the usage of this new option.

-------------

Commit messages:
- 8173970: jar tool should have a way to extract to a directory

Changes: https://git.openjdk.java.net/jdk/pull/2752/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2752&range=00
 Issue: https://bugs.openjdk.java.net/browse/JDK-8173970
 Stats: 268 lines in 4 files changed: 262 ins; 0 del; 6 mod
 Patch: https://git.openjdk.java.net/jdk/pull/2752.diff
 Fetch: git fetch https://git.openjdk.java.net/jdk pull/2752/head:pull/2752

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

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



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210226/b62c547e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: oracle_sig_logo.gif
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210226/b62c547e/oracle_sig_logo.gif>

From jai.forums2013 at gmail.com  Sat Feb 27 01:59:14 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sat, 27 Feb 2021 07:29:14 +0530
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
Message-ID: <6fe7241d-8594-07ce-80ec-0006062c268e@gmail.com>

Hello Lance,

On 27/02/21 1:17 am, Lance Andersen wrote:
>
>
> p.s. I think it would be useful in the future to start the discussion 
> on core-libs-dev prior to creating a PR (or leave it as a draft PR) 
> for a feature request.

Thank you for that input, I'll keep that in mind for any similar work in 
future.


-Jaikiran


From jai.forums2013 at gmail.com  Sat Feb 27 02:03:43 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sat, 27 Feb 2021 07:33:43 +0530
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
Message-ID: <29880f03-1d47-67b4-6460-2cad6f6952d5@gmail.com>


On 27/02/21 1:17 am, Lance Andersen wrote:
>
> I believe this would also warrant a CSR to be created as well as 
> updates to the jar man page.


I haven't created a CSR before, so I will need some guidance on that 
part. Is it usually created after all the implementation details have 
been decided upon or should it be created now?

-Jaikiran


From Alan.Bateman at oracle.com  Sat Feb 27 08:53:23 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 27 Feb 2021 08:53:23 +0000
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
Message-ID: <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>

On 26/02/2021 19:47, Lance Andersen wrote:
> Hi Jaikiran,
>
> Thank you for  the proposed patch.
>
> Assuming there is consensus to add support for this enhancement, I think we need to discuss what is the correct option.
>
> The jar tool borrows -C from tar for creating/updating a jar and the -C option is also a valid option when extracting files from a tar file.
>
> Perhaps keeping symmetry with tar and extend support for -C when extracting a jar file would be a better way forward.   Let?s give time for additional input.
>
> I believe this would also warrant a CSR to be created as well as updates to the jar man page.
>
> Best
> Lance
>
> p.s. I think it would be useful in the future to start the discussion on core-libs-dev prior to creating a PR (or leave it as a draft PR) for a feature request.
I created JDK-8173970 a few years ago so happy it it getting some attention.

Yes, the option name will need to be agreed. It would be useful to 
enumerate the options that the other tools are using to specify the 
location where to extract. If you see JBS issues mentioning tar -C not 
supporting chdir when extracting then it might be Solaris tar, which 
isn't the same as GNU tar which has different options. It might be 
better to look at more main stream tools, like unzip although jar -d is 
already taken. It would be nice if there were some consistency with 
other tools in the JDK that doing extracting (The jmod and jimage 
extract commands use use --dir for example).

There are other discussion points around the behavior when the target 
directory exists or does not exist, to ensure there is some consistency 
with main stream tools.

Yes, a CSR will be needed.

-Alan





From lance.andersen at oracle.com  Sat Feb 27 12:08:54 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sat, 27 Feb 2021 12:08:54 +0000
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <29880f03-1d47-67b4-6460-2cad6f6952d5@gmail.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <29880f03-1d47-67b4-6460-2cad6f6952d5@gmail.com>
Message-ID: <52B68EB8-7904-45FF-817C-CAB8589D6818@oracle.com>

HI Jaikiran,

I am more than happy to work with you through the CSR process

Lets get the discussion going regarding possible option names on core-libs-dev and then we can move forward :-)

Have a great weekend

On Feb 26, 2021, at 9:03 PM, Jaikiran Pai <jai.forums2013 at gmail.com<mailto:jai.forums2013 at gmail.com>> wrote:


On 27/02/21 1:17 am, Lance Andersen wrote:

I believe this would also warrant a CSR to be created as well as updates to the jar man page.


I haven't created a CSR before, so I will need some guidance on that part. Is it usually created after all the implementation details have been decided upon or should it be created now?

-Jaikiran


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



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210227/4d92f052/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: oracle_sig_logo.gif
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210227/4d92f052/oracle_sig_logo.gif>

From jai.forums2013 at gmail.com  Sun Feb 28 04:19:37 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sun, 28 Feb 2021 09:49:37 +0530
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
Message-ID: <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>

Hello Alan,

On 27/02/21 2:23 pm, Alan Bateman wrote:
>
> Yes, the option name will need to be agreed. It would be useful to 
> enumerate the options that the other tools are using to specify the 
> location where to extract. If you see JBS issues mentioning tar -C not 
> supporting chdir when extracting then it might be Solaris tar, which 
> isn't the same as GNU tar which has different options. It might be 
> better to look at more main stream tools, like unzip although jar -d 
> is already taken. It would be nice if there were some consistency with 
> other tools in the JDK that doing extracting (The jmod and jimage 
> extract commands use use --dir for example).

I had a look at both tar and unzip commands on MacOS and Linux (CentOS) 
setup that I had access to.

--------------
tar on MacOS:
--------------

tar --version
bsdtar 3.3.2 - libarchive 3.3.2 zlib/1.2.11 liblzma/5.0.5 bz2lib/1.0.6

The version of this tool has:

-C directory, --cd directory, --directory directory
 ???????????? In c and r mode, this changes the directory before adding 
the following files.
 ???????????? In x mode, change directories after opening the archive 
but before extracting
 ???????????? entries from the archive.

A command like "tar -xzf foo.tar.gz -C /tmp/bar/" works fine and 
extracts the foo.tar.gz from current directory to a target directory 
/tmp/bar/

--------------
tar on CentOS:
--------------

tar --version
tar (GNU tar) 1.26

This version of the tool has:

Common options:
 ?????? -C, --directory=DIR
 ????????????? change to directory DIR

Although the wording isn't clear that, when used with -x, it extracts to 
the directory specified in -C, it does indeed behave that way.

Specifically, a command like "tar -xzf foo.tar.gz -C /tmp/bar/" works 
fine and extracts the foo.tar.gz from current directory to a target 
directory /tmp/bar/

-------------------------------
unzip on both MacOS and CentOS:
-------------------------------

unzip -v
UnZip 6.00 of 20 April 2009, by Info-ZIP.? Maintained by C. Spieler.

This version of the tool has:

[-d exdir]
 ????????????? An optional directory to which to extract files.? By 
default, all files and sub-
 ????????????? directories are recreated in the current directory; the 
-d option allows extrac-
 ????????????? tion in an arbitrary directory (always assuming one has 
permission to? write? to
 ????????????? the? directory).? This option need not appear at the end 
of the command line; it
 ????????????? is also accepted before the zipfile specification (with? 
the? normal? options),
 ????????????? immediately? after? the zipfile specification, or between 
the file(s) and the -x
 ????????????? option.? The option and directory may be concatenated 
without? any? white? space
 ????????????? between? them,? but? note? that? this may cause normal 
shell behavior to be sup-
 ????????????? pressed.? In particular, ``-d ~'' (tilde) is expanded by 
Unix C shells into? the
 ????????????? name of the user's home directory, but ``-d~'' is treated 
as a literal subdirec-
 ????????????? tory ``~'' of the current directory.

unzip foo.zip -d /tmp/bar/ works fine and extracts the foo.zip from 
current directory to /tmp/bar/

---------------
jimage and jmod
---------------

The jimage and jmod as you note use the --dir option for extracting to 
that specified directory.


Those were the tools I looked at. I think using the -d option with -x 
for the jar command is ruled out since it already is used for a 
different purpose, although for a different "main" operation of the jar 
command.

As for using --dir for this new feature, I don't think it alone will be 
enough. Specifically, I couldn't find a "short form" option for the 
--dir option in the jimage or jmod commands. For the jar extract feature 
that we are discussing here, I think having a short form option (in 
addition to the longer form) is necessary to have it match the usage 
expectations of similar other options that the jar command exposes. So 
even if we do choose --dir as the long form option, we would still need 
a short form for it and since -d is already taken for something else, we 
would still need to come up with a different one. The short form of this 
option could be -C (see below).


I think reusing the -C option, for this new feature, perhaps is a good 
thing. The -C is currently used by the update and create "main" 
operation of the jar command and the man page for this option states:

-C dir
 ????????????? When creating (c) or updating (u) a JAR file, this option 
temporarily changes
 ????????????? the directory while processing files specified by the 
file operands. Its
 ????????????? operation is intended to be similar to the -C option of 
the UNIX tar utility.For
 ????????????? example, the following command changes to the classes 
directory and adds the
 ????????????? Bar.class file from that directory to my.jar:

 ????????????? jar uf my.jar -C classes Bar.class
....

Using the -C option would indeed align it with the tar command. For the 
"long form" of this option, the tar command (both on MacOS and CentOS) 
uses --directory. For this jar extract feature though, we could perhaps 
just use --dir to have it align with the jimage and the jmod tools.

So I think the combination of -C (short form) and --dir (long form) 
would perhaps be suitable for this feature.


>
> There are other discussion points around the behavior when the target 
> directory exists or does not exist, to ensure there is some 
> consistency with main stream tools.

I'm guessing you mean the behaviour of creating a directory (or a 
hierarchy of directories) if the target directory is not present? My 
testing with the tar tool (both on MacOS and CentOS) shows that if the 
specified target directory doesn't exist, then the extract fails. The 
tar extract command doesn't create the target directory during extract. 
On the other hand, the unzip tool, does create the directory if it 
doesn't exist. However, interestingly, the unzip tool creates only one 
level of that directory if it doesn't exist. Specifically, if you specify:

unzip foo.zip -d /tmp/blah/

and if "blah/" isn't a directory inside /tmp/ directory, then it creates 
the "blah/" directory inside /tmp/ and then extracts the contents of the 
zip into it.

However,

unzip foo.zip -d /tmp/blah/hello/

and if "blah/" isn't a directory inside /tmp/ directory, then this 
command fails with an error and it doesn't create the hierarchy of the 
target directories.

Coming to the jimage and the jmod commands, both these commands create 
the entire directory hierarchy if the target directory specified during 
extract, using --dir, doesn't exist. So a command like:

jimage extract --dir /tmp/blah/foo/bar/ jdkmodules

will create the blah/foo/bar/ directory hierarchy if blah doesn't exist 
in /tmp/, while extracting the "jdkmodules" image.

 From the user point of view, I think this behaviour of creating the 
directories if the target directory doesn't exist, is probably the most 
intuitive and useful and if we did decide to use this approach for this 
new option for jar extract command, then it would align with what we 
already do in jimage and jmod commands.

One another minor detail, while we are at this, is that, IMO we should 
let the jar extract command to continue to behave the way it currently 
does when it comes to overwriting existing files. If the jar being 
extracted contains a file by the same name, in the target directory 
(hierarchy) then it should continue to overwrite that file. In other 
words, I don't think we should change the way the jar extract command 
currently behaves where it overwrites existing files when extracting.


-Jaikiran



From lance.andersen at oracle.com  Sun Feb 28 12:08:16 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sun, 28 Feb 2021 12:08:16 +0000
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
Message-ID: <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>

Hi Jaikiran,

Thank you for this.  I went through this myself yesterday in addition to what you have below here are a few more:

7zip:       -o
Info-zip:  -d  (MacOS version of zip)
Bandzip: -o:{dir}
jpackage: -d ?dest
jlink ?output


Thinking about this some more, I might suggest supporting

-C
?dir
?directory

Best
Lance

On Feb 27, 2021, at 11:19 PM, Jaikiran Pai <jai.forums2013 at gmail.com<mailto:jai.forums2013 at gmail.com>> wrote:

Hello Alan,

On 27/02/21 2:23 pm, Alan Bateman wrote:

Yes, the option name will need to be agreed. It would be useful to enumerate the options that the other tools are using to specify the location where to extract. If you see JBS issues mentioning tar -C not supporting chdir when extracting then it might be Solaris tar, which isn't the same as GNU tar which has different options. It might be better to look at more main stream tools, like unzip although jar -d is already taken. It would be nice if there were some consistency with other tools in the JDK that doing extracting (The jmod and jimage extract commands use use --dir for example).

I had a look at both tar and unzip commands on MacOS and Linux (CentOS) setup that I had access to.

--------------
tar on MacOS:
--------------

tar --version
bsdtar 3.3.2 - libarchive 3.3.2 zlib/1.2.11 liblzma/5.0.5 bz2lib/1.0.6

The version of this tool has:

-C directory, --cd directory, --directory directory
             In c and r mode, this changes the directory before adding the following files.
             In x mode, change directories after opening the archive but before extracting
             entries from the archive.

A command like "tar -xzf foo.tar.gz -C /tmp/bar/" works fine and extracts the foo.tar.gz from current directory to a target directory /tmp/bar/

--------------
tar on CentOS:
--------------

tar --version
tar (GNU tar) 1.26

This version of the tool has:

Common options:
       -C, --directory=DIR
              change to directory DIR

Although the wording isn't clear that, when used with -x, it extracts to the directory specified in -C, it does indeed behave that way.

Specifically, a command like "tar -xzf foo.tar.gz -C /tmp/bar/" works fine and extracts the foo.tar.gz from current directory to a target directory /tmp/bar/

-------------------------------
unzip on both MacOS and CentOS:
-------------------------------

unzip -v
UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.

This version of the tool has:

[-d exdir]
              An optional directory to which to extract files.  By default, all files and sub-
              directories are recreated in the current directory; the -d option allows extrac-
              tion in an arbitrary directory (always assuming one has permission to  write  to
              the  directory).  This option need not appear at the end of the command line; it
              is also accepted before the zipfile specification (with  the  normal  options),
              immediately  after  the zipfile specification, or between the file(s) and the -x
              option.  The option and directory may be concatenated without  any  white  space
              between  them,  but  note  that  this may cause normal shell behavior to be sup-
              pressed.  In particular, ``-d ~'' (tilde) is expanded by Unix C shells into  the
              name of the user's home directory, but ``-d~'' is treated as a literal subdirec-
              tory ``~'' of the current directory.

unzip foo.zip -d /tmp/bar/ works fine and extracts the foo.zip from current directory to /tmp/bar/

---------------
jimage and jmod
---------------

The jimage and jmod as you note use the --dir option for extracting to that specified directory.


Those were the tools I looked at. I think using the -d option with -x for the jar command is ruled out since it already is used for a different purpose, although for a different "main" operation of the jar command.

As for using --dir for this new feature, I don't think it alone will be enough. Specifically, I couldn't find a "short form" option for the --dir option in the jimage or jmod commands. For the jar extract feature that we are discussing here, I think having a short form option (in addition to the longer form) is necessary to have it match the usage expectations of similar other options that the jar command exposes. So even if we do choose --dir as the long form option, we would still need a short form for it and since -d is already taken for something else, we would still need to come up with a different one. The short form of this option could be -C (see below).


I think reusing the -C option, for this new feature, perhaps is a good thing. The -C is currently used by the update and create "main" operation of the jar command and the man page for this option states:

-C dir
              When creating (c) or updating (u) a JAR file, this option temporarily changes
              the directory while processing files specified by the file operands. Its
              operation is intended to be similar to the -C option of the UNIX tar utility.For
              example, the following command changes to the classes directory and adds the
              Bar.class file from that directory to my.jar:

              jar uf my.jar -C classes Bar.class
....

Using the -C option would indeed align it with the tar command. For the "long form" of this option, the tar command (both on MacOS and CentOS) uses --directory. For this jar extract feature though, we could perhaps just use --dir to have it align with the jimage and the jmod tools.

So I think the combination of -C (short form) and --dir (long form) would perhaps be suitable for this feature.



There are other discussion points around the behavior when the target directory exists or does not exist, to ensure there is some consistency with main stream tools.

I'm guessing you mean the behaviour of creating a directory (or a hierarchy of directories) if the target directory is not present? My testing with the tar tool (both on MacOS and CentOS) shows that if the specified target directory doesn't exist, then the extract fails. The tar extract command doesn't create the target directory during extract. On the other hand, the unzip tool, does create the directory if it doesn't exist. However, interestingly, the unzip tool creates only one level of that directory if it doesn't exist. Specifically, if you specify:

unzip foo.zip -d /tmp/blah/

and if "blah/" isn't a directory inside /tmp/ directory, then it creates the "blah/" directory inside /tmp/ and then extracts the contents of the zip into it.

However,

unzip foo.zip -d /tmp/blah/hello/

and if "blah/" isn't a directory inside /tmp/ directory, then this command fails with an error and it doesn't create the hierarchy of the target directories.

Coming to the jimage and the jmod commands, both these commands create the entire directory hierarchy if the target directory specified during extract, using --dir, doesn't exist. So a command like:

jimage extract --dir /tmp/blah/foo/bar/ jdkmodules

will create the blah/foo/bar/ directory hierarchy if blah doesn't exist in /tmp/, while extracting the "jdkmodules" image.

From the user point of view, I think this behaviour of creating the directories if the target directory doesn't exist, is probably the most intuitive and useful and if we did decide to use this approach for this new option for jar extract command, then it would align with what we already do in jimage and jmod commands.

One another minor detail, while we are at this, is that, IMO we should let the jar extract command to continue to behave the way it currently does when it comes to overwriting existing files. If the jar being extracted contains a file by the same name, in the target directory (hierarchy) then it should continue to overwrite that file. In other words, I don't think we should change the way the jar extract command currently behaves where it overwrites existing files when extracting.


-Jaikiran



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



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210228/e4694d74/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: oracle_sig_logo.gif
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20210228/e4694d74/oracle_sig_logo-0001.gif>