From prappo at openjdk.java.net  Tue Feb  1 16:31:38 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 1 Feb 2022 16:31:38 GMT
Subject: RFR: 8281057: Fix doc references to overriding in JLS
Message-ID: <eTfoamYgcWCfM1yA45i3JtSQmJsUpmUE1EAnMEhe1C4=.027df332-9792-4622-9ea6-4ea8244d731c@github.com>

While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**.

Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections.

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

Commit messages:
 - Initial commit

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

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

From darcy at openjdk.java.net  Tue Feb  1 17:34:10 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 1 Feb 2022 17:34:10 GMT
Subject: RFR: 8281057: Fix doc references to overriding in JLS
In-Reply-To: <eTfoamYgcWCfM1yA45i3JtSQmJsUpmUE1EAnMEhe1C4=.027df332-9792-4622-9ea6-4ea8244d731c@github.com>
References: <eTfoamYgcWCfM1yA45i3JtSQmJsUpmUE1EAnMEhe1C4=.027df332-9792-4622-9ea6-4ea8244d731c@github.com>
Message-ID: <64qmLKz3G6wYRdnA0Y65Fho7oUZqint8EKD-a1GXkJY=.4536f347-7bcd-4d74-b6e3-01441cf41f2c@github.com>

On Tue, 1 Feb 2022 16:19:01 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**.
> 
> Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections.

Marked as reviewed by darcy (Reviewer).

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

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

From iris at openjdk.java.net  Tue Feb  1 17:45:12 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 1 Feb 2022 17:45:12 GMT
Subject: RFR: 8281057: Fix doc references to overriding in JLS
In-Reply-To: <eTfoamYgcWCfM1yA45i3JtSQmJsUpmUE1EAnMEhe1C4=.027df332-9792-4622-9ea6-4ea8244d731c@github.com>
References: <eTfoamYgcWCfM1yA45i3JtSQmJsUpmUE1EAnMEhe1C4=.027df332-9792-4622-9ea6-4ea8244d731c@github.com>
Message-ID: <jQn3zjSvZz1CMHBdaI8JiAqhNgbsM03NXzcYhMdVfUk=.358c2a31-4030-4935-83c8-5b337a0796e6@github.com>

On Tue, 1 Feb 2022 16:19:01 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**.
> 
> Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections.

Marked as reviewed by iris (Reviewer).

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

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

From ethan at mccue.dev  Wed Feb  2 05:04:41 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Wed, 2 Feb 2022 00:04:41 -0500
Subject: RFE: Comment in javax.lang.model.Source version implies non-sealed
 should be a keyword
Message-ID: <CA+NR86j7hQFzqZKL=+UwqnyTN1h3Z1L28J=HoRaBM8s84mh8AA@mail.gmail.com>

New here, so apologies If I am doing the procedure wrong.

https://github.com/openjdk/jdk/blob/master/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java#L465

This comment implies that once sealed classes would be made a non-preview
feature that `non-sealed` should be added to this predicate. I think the
current behavior is correct since it's a contextual keyword, but the
comment should probably go.

If I am right and that is the case, my understanding is that I need a
sponsor in order to make a PR to delete those lines. Is that correct?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20220202/d58a1c12/attachment.htm>

From prappo at openjdk.java.net  Wed Feb  2 10:01:06 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 2 Feb 2022 10:01:06 GMT
Subject: RFR: 8281057: Fix doc references to overriding in JLS
In-Reply-To: <eTfoamYgcWCfM1yA45i3JtSQmJsUpmUE1EAnMEhe1C4=.027df332-9792-4622-9ea6-4ea8244d731c@github.com>
References: <eTfoamYgcWCfM1yA45i3JtSQmJsUpmUE1EAnMEhe1C4=.027df332-9792-4622-9ea6-4ea8244d731c@github.com>
Message-ID: <1V1_jhMx07iBPq8rzhWP2pwNkb8lBNpeqP3jzA06lf0=.79432eb1-3bf4-4d28-acb7-f5c07bf1f0c4@github.com>

On Tue, 1 Feb 2022 16:19:01 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**.
> 
> Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections.

I would appreciate it if serviceability and hotspot could review this PR too.

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

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

From dholmes at openjdk.java.net  Wed Feb  2 12:08:06 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 2 Feb 2022 12:08:06 GMT
Subject: RFR: 8281057: Fix doc references to overriding in JLS
In-Reply-To: <eTfoamYgcWCfM1yA45i3JtSQmJsUpmUE1EAnMEhe1C4=.027df332-9792-4622-9ea6-4ea8244d731c@github.com>
References: <eTfoamYgcWCfM1yA45i3JtSQmJsUpmUE1EAnMEhe1C4=.027df332-9792-4622-9ea6-4ea8244d731c@github.com>
Message-ID: <WImLWgTq8Bu-7ukhDMgsUiOAomHBV1AwNDjmNgoEENM=.f54a96c0-6f3f-4e90-a9f4-ad90ea27f629@github.com>

On Tue, 1 Feb 2022 16:19:01 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**.
> 
> Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 670:

> 668:      *  modifier is ignored for this test.
> 669:      *
> 670:      *  See JLS 8.4.8.1 (without transitivity) and 8.4.8.4

Any idea what the "(without transitivity)" is referring to here and elsewhere?

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

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

From dholmes at openjdk.java.net  Wed Feb  2 12:14:04 2022
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 2 Feb 2022 12:14:04 GMT
Subject: RFR: 8281057: Fix doc references to overriding in JLS
In-Reply-To: <eTfoamYgcWCfM1yA45i3JtSQmJsUpmUE1EAnMEhe1C4=.027df332-9792-4622-9ea6-4ea8244d731c@github.com>
References: <eTfoamYgcWCfM1yA45i3JtSQmJsUpmUE1EAnMEhe1C4=.027df332-9792-4622-9ea6-4ea8244d731c@github.com>
Message-ID: <WMhTzudyyKkS8ntlOY_BMQs4vT-0BpxV5DbDw5hO1vM=.2a690c7b-6778-4716-92ad-2189121c5291@github.com>

On Tue, 1 Feb 2022 16:19:01 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**.
> 
> Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections.

Hi Pavel,

All the section number changes look good and accurate. I have one query above, and also spotted one existing comment that is not correct.

Thanks,
David

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 1793:

> 1791:         }
> 1792: 
> 1793:         // Error if static method overrides instance method (JLS 8.4.8.2).

"overrides" should be "hides"

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

Marked as reviewed by dholmes (Reviewer).

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

From prappo at openjdk.java.net  Wed Feb  2 12:34:05 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 2 Feb 2022 12:34:05 GMT
Subject: RFR: 8281057: Fix doc references to overriding in JLS
In-Reply-To: <WImLWgTq8Bu-7ukhDMgsUiOAomHBV1AwNDjmNgoEENM=.f54a96c0-6f3f-4e90-a9f4-ad90ea27f629@github.com>
References: <eTfoamYgcWCfM1yA45i3JtSQmJsUpmUE1EAnMEhe1C4=.027df332-9792-4622-9ea6-4ea8244d731c@github.com>
 <WImLWgTq8Bu-7ukhDMgsUiOAomHBV1AwNDjmNgoEENM=.f54a96c0-6f3f-4e90-a9f4-ad90ea27f629@github.com>
Message-ID: <UN-kOvJYC1Yl2zzhgYtR8pCtGYWxxAfAxbYvCc63BmM=.886726eb-b75a-4ef3-8e1f-da7f025f219a@github.com>

On Wed, 2 Feb 2022 12:04:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**.
>> 
>> Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 670:
> 
>> 668:      *  modifier is ignored for this test.
>> 669:      *
>> 670:      *  See JLS 8.4.8.1 (without transitivity) and 8.4.8.4
> 
> Any idea what the "(without transitivity)" is referring to here and elsewhere?

My guess is that "transitivity" here refers to the subclass relationship being the transitive closure of the direct subclass relationship. Could it also be that the "quirk" paragraph starting at com/sun/tools/javac/code/Symbol.java:2057 is relevant here? @mcimadamore?

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

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

From prappo at openjdk.java.net  Wed Feb  2 12:46:05 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 2 Feb 2022 12:46:05 GMT
Subject: RFR: 8281057: Fix doc references to overriding in JLS
In-Reply-To: <WMhTzudyyKkS8ntlOY_BMQs4vT-0BpxV5DbDw5hO1vM=.2a690c7b-6778-4716-92ad-2189121c5291@github.com>
References: <eTfoamYgcWCfM1yA45i3JtSQmJsUpmUE1EAnMEhe1C4=.027df332-9792-4622-9ea6-4ea8244d731c@github.com>
 <WMhTzudyyKkS8ntlOY_BMQs4vT-0BpxV5DbDw5hO1vM=.2a690c7b-6778-4716-92ad-2189121c5291@github.com>
Message-ID: <v6UK9yUd-VyBTrKZRmlSUOllRI2fwhjV5VAzBu7yQcM=.fea1c545-df0a-478a-850d-d5e16d088b2b@github.com>

On Wed, 2 Feb 2022 12:06:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**.
>> 
>> Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 1793:
> 
>> 1791:         }
>> 1792: 
>> 1793:         // Error if static method overrides instance method (JLS 8.4.8.2).
> 
> "overrides" should be "hides"

Although you seem to be correct, the error messages and the code around operate using the term "override":

        // Error if static method overrides instance method (JLS 8.4.8.2).
        if ((m.flags() & STATIC) != 0 &&
                   (other.flags() & STATIC) == 0) {
            log.error(TreeInfo.diagnosticPositionFor(m, tree),
                      Errors.OverrideStatic(cannotOverride(m, other)));
            m.flags_field |= BAD_OVERRIDE;
            return;
        }

        // Error if instance method overrides static or final
        // method (JLS 8.4.8.1).
        if ((other.flags() & FINAL) != 0 ||
                 (m.flags() & STATIC) == 0 &&
                 (other.flags() & STATIC) != 0) {
            log.error(TreeInfo.diagnosticPositionFor(m, tree),
                      Errors.OverrideMeth(cannotOverride(m, other),
                                          asFlagSet(other.flags() & (FINAL | STATIC))));
            m.flags_field |= BAD_OVERRIDE;
            return;
        }


        /**
         * compiler.err.override.static=\
         *    {0}\n\
         *    overriding method is static
         */
        public static Error OverrideStatic(Fragment arg0) {
            return new Error("compiler", "override.static", arg0);
        }

Compiler folk, what do you think?

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

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

From david.holmes at oracle.com  Wed Feb  2 13:39:38 2022
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 2 Feb 2022 23:39:38 +1000
Subject: RFR: 8281057: Fix doc references to overriding in JLS
In-Reply-To: <v6UK9yUd-VyBTrKZRmlSUOllRI2fwhjV5VAzBu7yQcM=.fea1c545-df0a-478a-850d-d5e16d088b2b@github.com>
References: <eTfoamYgcWCfM1yA45i3JtSQmJsUpmUE1EAnMEhe1C4=.027df332-9792-4622-9ea6-4ea8244d731c@github.com>
 <WMhTzudyyKkS8ntlOY_BMQs4vT-0BpxV5DbDw5hO1vM=.2a690c7b-6778-4716-92ad-2189121c5291@github.com>
 <v6UK9yUd-VyBTrKZRmlSUOllRI2fwhjV5VAzBu7yQcM=.fea1c545-df0a-478a-850d-d5e16d088b2b@github.com>
Message-ID: <a3300b0a-369a-69bc-afc5-b866cbb20122@oracle.com>

On 2/02/2022 10:46 pm, Pavel Rappo wrote:
> On Wed, 2 Feb 2022 12:06:39 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**.
>>>
>>> Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections.
>>
>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 1793:
>>
>>> 1791:         }
>>> 1792:
>>> 1793:         // Error if static method overrides instance method (JLS 8.4.8.2).
>>
>> "overrides" should be "hides"
> 
> Although you seem to be correct, the error messages and the code around operate using the term "override":

Ah yes, I can see now that "overrides" is (incorrectly) used all through 
this code and even in the error messages. It is a subtle distinction.

Cheers,
David
-----

>          // Error if static method overrides instance method (JLS 8.4.8.2).
>          if ((m.flags() & STATIC) != 0 &&
>                     (other.flags() & STATIC) == 0) {
>              log.error(TreeInfo.diagnosticPositionFor(m, tree),
>                        Errors.OverrideStatic(cannotOverride(m, other)));
>              m.flags_field |= BAD_OVERRIDE;
>              return;
>          }
> 
>          // Error if instance method overrides static or final
>          // method (JLS 8.4.8.1).
>          if ((other.flags() & FINAL) != 0 ||
>                   (m.flags() & STATIC) == 0 &&
>                   (other.flags() & STATIC) != 0) {
>              log.error(TreeInfo.diagnosticPositionFor(m, tree),
>                        Errors.OverrideMeth(cannotOverride(m, other),
>                                            asFlagSet(other.flags() & (FINAL | STATIC))));
>              m.flags_field |= BAD_OVERRIDE;
>              return;
>          }
> 
> 
>          /**
>           * compiler.err.override.static=\
>           *    {0}\n\
>           *    overriding method is static
>           */
>          public static Error OverrideStatic(Fragment arg0) {
>              return new Error("compiler", "override.static", arg0);
>          }
> 
> Compiler folk, what do you think?
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/7311

From mcimadamore at openjdk.java.net  Wed Feb  2 14:41:11 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 2 Feb 2022 14:41:11 GMT
Subject: RFR: 8281057: Fix doc references to overriding in JLS
In-Reply-To: <UN-kOvJYC1Yl2zzhgYtR8pCtGYWxxAfAxbYvCc63BmM=.886726eb-b75a-4ef3-8e1f-da7f025f219a@github.com>
References: <eTfoamYgcWCfM1yA45i3JtSQmJsUpmUE1EAnMEhe1C4=.027df332-9792-4622-9ea6-4ea8244d731c@github.com>
 <WImLWgTq8Bu-7ukhDMgsUiOAomHBV1AwNDjmNgoEENM=.f54a96c0-6f3f-4e90-a9f4-ad90ea27f629@github.com>
 <UN-kOvJYC1Yl2zzhgYtR8pCtGYWxxAfAxbYvCc63BmM=.886726eb-b75a-4ef3-8e1f-da7f025f219a@github.com>
Message-ID: <aJ00U1l0eLSxbcwgCGbBPIHQR1sLBEspPokv8YGfv5A=.809830d0-87b4-4b19-8887-a2e64d9eb94e@github.com>

On Wed, 2 Feb 2022 12:31:04 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 670:
>> 
>>> 668:      *  modifier is ignored for this test.
>>> 669:      *
>>> 670:      *  See JLS 8.4.8.1 (without transitivity) and 8.4.8.4
>> 
>> Any idea what the "(without transitivity)" is referring to here and elsewhere?
>
> My guess is that "transitivity" here refers to the subclass relationship being the transitive closure of the direct subclass relationship. Could it also be that the "quirk" paragraph starting at com/sun/tools/javac/code/Symbol.java:2057 is relevant here? @mcimadamore?

First, this class contains many references to 8.4.6.x - which should really be 8.4.8.x - not just this one.

I'm not 100% sure about the "without transitivity" comment, but if I had to guess I'd say that it refers to the fact that the checks described in 8.4.8.3 are missing from this routine. More specifically, this section:


It is a compile-time error if a class or interface C has a member method m1 and there exists a method m2 declared in C or a superclass or superinterface of C, A, such that all of the following are true:
* m1 and m2 have the same name.
* m2 is accessible (?6.6) from C.
* The signature of m1 is not a subsignature (?8.4.2) of the signature of m2 as a member of the supertype of C that names A.
* The declared signature of m1 or some method m1 overrides (directly or indirectly) has the same erasure as the declared signature of m2 or some method m2 overrides (directly or indirectly). <----------

As you can see, the last bullet introduces some sort of global requirement across the inheritance chain; this constraint was necessary after Java 5, as generics require the introduction of bridge methods, and it is possible, in some extreme cases, for a subclass to override (accidentally) a bridge method. The JLS doesn't say the word "bridge method" anywhere, but this is what this check morally does.

Now, in an early version of the Java compiler (5 and 6, IIRC), we used to check for clashes with bridge methods at code generation time. So, the checks in the compiler frontend, such as Symbol::overrides did not really have to concerb with that expensive side of the override check.

But, as the implementation matured, it became clearer that (a) the code-generation clash check was not enough to detect all problematic cases and (b) detecting clashes at code generation time was *too late*, especially for clients of the compiler API which might only run the "analyze" step. For these reasons, staring from Java 7, the frontend also has a more expensive check which supports 8.4.8.3 in full (Check::checkOverrideClashes).

Of course, not being the author of that comment, this is only my best guess as to what that could mean :-)

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

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

From prappo at openjdk.java.net  Wed Feb  2 15:44:11 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 2 Feb 2022 15:44:11 GMT
Subject: RFR: 8281057: Fix doc references to overriding in JLS
In-Reply-To: <aJ00U1l0eLSxbcwgCGbBPIHQR1sLBEspPokv8YGfv5A=.809830d0-87b4-4b19-8887-a2e64d9eb94e@github.com>
References: <eTfoamYgcWCfM1yA45i3JtSQmJsUpmUE1EAnMEhe1C4=.027df332-9792-4622-9ea6-4ea8244d731c@github.com>
 <WImLWgTq8Bu-7ukhDMgsUiOAomHBV1AwNDjmNgoEENM=.f54a96c0-6f3f-4e90-a9f4-ad90ea27f629@github.com>
 <UN-kOvJYC1Yl2zzhgYtR8pCtGYWxxAfAxbYvCc63BmM=.886726eb-b75a-4ef3-8e1f-da7f025f219a@github.com>
 <aJ00U1l0eLSxbcwgCGbBPIHQR1sLBEspPokv8YGfv5A=.809830d0-87b4-4b19-8887-a2e64d9eb94e@github.com>
Message-ID: <UUu5q8Dn5IYiFIbNbHPHnsxYPQzYeH9k7uTDs0AXHQI=.68cbd3f7-c69a-4561-949b-f2b478f228d0@github.com>

On Wed, 2 Feb 2022 14:37:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> My guess is that "transitivity" here refers to the subclass relationship being the transitive closure of the direct subclass relationship. Could it also be that the "quirk" paragraph starting at com/sun/tools/javac/code/Symbol.java:2057 is relevant here? @mcimadamore?
>
> First, this class contains many references to 8.4.6.x - which should really be 8.4.8.x - not just this one.
> 
> I'm not 100% sure about the "without transitivity" comment, but if I had to guess I'd say that it refers to the fact that the checks described in 8.4.8.3 are missing from this routine. More specifically, this section:
> 
> 
> It is a compile-time error if a class or interface C has a member method m1 and there exists a method m2 declared in C or a superclass or superinterface of C, A, such that all of the following are true:
> * m1 and m2 have the same name.
> * m2 is accessible (?6.6) from C.
> * The signature of m1 is not a subsignature (?8.4.2) of the signature of m2 as a member of the supertype of C that names A.
> * The declared signature of m1 or some method m1 overrides (directly or indirectly) has the same erasure as the declared signature of m2 or some method m2 overrides (directly or indirectly). <----------
> 
> As you can see, the last bullet introduces some sort of global requirement across the inheritance chain; this constraint was necessary after Java 5, as generics require the introduction of bridge methods, and it is possible, in some extreme cases, for a subclass to override (accidentally) a bridge method. The JLS doesn't say the word "bridge method" anywhere, but this is what this check morally does.
> 
> Now, in an early version of the Java compiler (5 and 6, IIRC), we used to check for clashes with bridge methods at code generation time. So, the checks in the compiler frontend, such as Symbol::overrides did not really have to concerb with that expensive side of the override check.
> 
> But, as the implementation matured, it became clearer that (a) the code-generation clash check was not enough to detect all problematic cases and (b) detecting clashes at code generation time was *too late*, especially for clients of the compiler API which might only run the "analyze" step. For these reasons, staring from Java 7, the frontend also has a more expensive check which supports 8.4.8.3 in full (Check::checkOverrideClashes).
> 
> Of course, not being the author of that comment, this is only my best guess as to what that could mean :-)

FWIW, I found a related bug: https://bugs.openjdk.java.net/browse/JDK-4362349. It might be responsible for that "(without transitivity)" caveat.

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

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

From vicente.romero at oracle.com  Wed Feb  2 16:41:18 2022
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 2 Feb 2022 11:41:18 -0500
Subject: RFE: Comment in javax.lang.model.Source version implies
 non-sealed should be a keyword
In-Reply-To: <CA+NR86j7hQFzqZKL=+UwqnyTN1h3Z1L28J=HoRaBM8s84mh8AA@mail.gmail.com>
References: <CA+NR86j7hQFzqZKL=+UwqnyTN1h3Z1L28J=HoRaBM8s84mh8AA@mail.gmail.com>
Message-ID: <8ec69c77-0178-0a3d-04eb-6613a6f53f47@oracle.com>

hi,

yep I think those lines could be removed,

Thanks,
Vicente

On 2/2/22 00:04, Ethan McCue wrote:
> New here, so apologies If I am doing the procedure wrong.
>
> https://github.com/openjdk/jdk/blob/master/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java#L465
>
> This comment implies that once sealed classes would be made a 
> non-preview feature that `non-sealed` should be added to this 
> predicate. I think the current behavior is correct since it's a 
> contextual keyword, but the comment should probably go.
>
> If I am right and that is the case, my understanding is that I need a 
> sponsor in order to make a PR to delete those lines. Is that?correct?


From cjplummer at openjdk.java.net  Wed Feb  2 22:48:12 2022
From: cjplummer at openjdk.java.net (Chris Plummer)
Date: Wed, 2 Feb 2022 22:48:12 GMT
Subject: RFR: 8281057: Fix doc references to overriding in JLS
In-Reply-To: <eTfoamYgcWCfM1yA45i3JtSQmJsUpmUE1EAnMEhe1C4=.027df332-9792-4622-9ea6-4ea8244d731c@github.com>
References: <eTfoamYgcWCfM1yA45i3JtSQmJsUpmUE1EAnMEhe1C4=.027df332-9792-4622-9ea6-4ea8244d731c@github.com>
Message-ID: <vD7wBS8OeTqUV4QtcgDRwINKV4IltyDdzqeF4Zfgd9o=.4066e2c1-8d5b-4b71-88ea-e58da9b6c8d3@github.com>

On Tue, 1 Feb 2022 16:19:01 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**.
> 
> Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections.

`com/sun/jdi/ReferenceType.java` changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

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

From Alan.Bateman at oracle.com  Thu Feb  3 13:37:06 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 3 Feb 2022 13:37:06 +0000
Subject: Source file launch with security manager enabled fails
In-Reply-To: <0c8d4988-cee1-0c75-f39f-f24c51e19100@oracle.com>
References: <b26e2754-5849-3d2b-3a06-f3df665c7ebb@gmail.com>
 <0c8d4988-cee1-0c75-f39f-f24c51e19100@oracle.com>
Message-ID: <1a7b61fc-4c31-862a-25be-4bb407633e84@oracle.com>


I think it would be useful to hear from Jon Gibbons or someone else 
working on javac first. It would be a bit unusual to run the compiler 
with a security manager and I thought it was deliberate to not grant 
permissions to jdk.compiler in the default policy. Also the source code 
launcher is aimed at the early stages of learning Java where there 
shouldn't be advanced options or exotic execution modes.

-Alan


On 03/02/2022 13:25, Sean Mullan wrote:
> I only took a quick look, but it looks like a bug. The jdk.compiler 
> module needs to be granted that permission in the default.policy file.
>
> Please file a bug, or if you like I can file one on your behalf.
>
> Thanks,
> Sean
>
> On 2/3/22 8:01 AM, Jaikiran Pai wrote:
>> I'm unsure if core-libs is the right place for this or compiler-dev,
>> sending this to core-libs for now.
>>
>> Please consider this trivial Java source file:
>>
>> public class HelloWorld {
>> ? ?? ?public static void main(final String[] args) throws Exception {
>> ? ?? ???? System.out.println("Hello World");
>> ? ?? ?}
>> }
>>
>> Running this in source file launcher mode as follows:
>>
>> java HelloWorld.java
>>
>> returns the expected result. However when running in source file
>> launcher mode *and* with security manager enabled, it throws the
>> following exception:
>>
>> java -Djava.security.manager=default HelloWorld.java
>>
>> WARNING: A command line option has enabled the Security Manager
>> WARNING: The Security Manager is deprecated and will be removed in a
>> future release
>> Exception in thread "main" java.security.AccessControlException: access
>> denied ("java.lang.RuntimePermission"
>> "accessClassInPackage.jdk.internal.misc")
>> ? ?? ?at
>> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:485) 
>>
>> ? ?? ?at
>> java.base/java.security.AccessController.checkPermission(AccessController.java:1068) 
>>
>> ? ?? ?at
>> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:416) 
>>
>> ? ?? ?at
>> java.base/java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1332) 
>>
>> ? ?? ?at
>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:184) 
>>
>> ? ?? ?at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
>> ? ?? ?at 
>> jdk.compiler/com.sun.tools.javac.launcher.Main.main(Main.java:132)
>>
>>
>> This happens in Java 17 as well as latest master branch. I haven't
>> checked older releases but I guess it's reproducible there too.
>>
>> Are users expected to use an explicit policy file to add this permission
>> in source file launch mode or is this missing an internal doPrivileged
>> call in the JDK?
>>
>> As an additional input, compiling this file first using javac and then
>> launching it in traditional mode with security manager enabled works 
>> fine:
>>
>> javac HelloWorld.java
>>
>> java -Djava.security.manager=default HelloWorld
>> WARNING: A command line option has enabled the Security Manager
>> WARNING: The Security Manager is deprecated and will be removed in a
>> future release
>> Hello World
>>
>>
>> -Jaikiran
>>
>>
>>


From jai.forums2013 at gmail.com  Thu Feb  3 13:43:28 2022
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 3 Feb 2022 19:13:28 +0530
Subject: Source file launch with security manager enabled fails
In-Reply-To: <1a7b61fc-4c31-862a-25be-4bb407633e84@oracle.com>
References: <b26e2754-5849-3d2b-3a06-f3df665c7ebb@gmail.com>
 <0c8d4988-cee1-0c75-f39f-f24c51e19100@oracle.com>
 <1a7b61fc-4c31-862a-25be-4bb407633e84@oracle.com>
Message-ID: <67da05c0-2578-2231-3ba0-e9db95b649a1@gmail.com>


On 03/02/22 7:07 pm, Alan Bateman wrote:
>
> I think it would be useful to hear from Jon Gibbons or someone else 
> working on javac first. It would be a bit unusual to run the compiler 
> with a security manager and I thought it was deliberate to not grant 
> permissions to jdk.compiler in the default policy. Also the source 
> code launcher is aimed at the early stages of learning Java where 
> there shouldn't be advanced options or exotic execution modes.

To add some context on where I ran into this - I was experimenting with 
security manager itself to see how the SocketChannel.bind() API behaves 
when security manager was enabled. Something like this trivial code:


import java.nio.channels.*;
import java.net.*;

public class SecManager {
 ?? ?public static void main(final String[] args) throws Exception {
 ?? ???? SocketChannel sc = SocketChannel.open();
 ?? ???? System.out.println("Opened socket channel " + sc);
 ?? ???? sc.bind(new InetSocketAddress("127.0.0.1", 23452));
 ?? ???? System.out.println("Bound socket channel " + sc);
 ?? ???? sc.close();
 ?? ???? System.out.println("Closed socket channel " + sc);
 ?? ?}
}


I decided to use source launcher mode here and since I was experimenting 
with security manager itself, I had to enable security manager.

I had a look at the JEP-330 https://openjdk.java.net/jeps/330 where this 
feature was introduced but couldn't see a mention of whether 
using/enabling security manager with this feature was allowed/supported.

-Jaikiran


From prappo at openjdk.java.net  Thu Feb  3 14:58:12 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 3 Feb 2022 14:58:12 GMT
Subject: Integrated: 8281057: Fix doc references to overriding in JLS
In-Reply-To: <eTfoamYgcWCfM1yA45i3JtSQmJsUpmUE1EAnMEhe1C4=.027df332-9792-4622-9ea6-4ea8244d731c@github.com>
References: <eTfoamYgcWCfM1yA45i3JtSQmJsUpmUE1EAnMEhe1C4=.027df332-9792-4622-9ea6-4ea8244d731c@github.com>
Message-ID: <pu7_A1KlRaS_vbJFVDHmA-IoeVwGvkO3wd3jKVvmcpg=.3d192c8d-7e17-4da1-8f87-8ebcbc4f6e0a@github.com>

On Tue, 1 Feb 2022 16:19:01 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> While looking into guts of javadoc comment inheritance, I noticed that a number of places in JDK seem to confuse JLS 8.4.6.** with JLS 8.4.8.**.
> 
> Granted, "8.4.6 Method Throws" tangentially addresses overriding. However, I believe that the real target should be "8.4.8. Inheritance, Overriding, and Hiding" and its subsections.

This pull request has now been integrated.

Changeset: 1f926609
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1f926609372c9b80dde831a014310a3729768c92
Stats:     18 lines in 5 files changed: 0 ins; 0 del; 18 mod

8281057: Fix doc references to overriding in JLS

Reviewed-by: darcy, iris, dholmes, cjplummer

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

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

From cstein at openjdk.java.net  Thu Feb  3 16:27:36 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Thu, 3 Feb 2022 16:27:36 GMT
Subject: RFR: 8281104: jar --create should create missing parent directories
Message-ID: <BoX4psPENqzTaGF7LS8ztXbQmcmRdhcnUvAZBGD_L7E=.45e1d2bf-1123-41ec-a5e8-d842db1f8731@github.com>

Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing parent directories (here `a/b`) on the default file system before storing the JAR file (here `foo.jar`) in the destination directory.

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

Commit messages:
 - Expect at least jar file's name in error message
 - Use provided error writer
 - Use LF as line separator
 - 8281104: Add happy-path and expected-to-fail tests
 - 8281104: jar --create should create missing parent directories

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

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

From weijun at openjdk.java.net  Thu Feb  3 17:21:32 2022
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 3 Feb 2022 17:21:32 GMT
Subject: RFR: 8281175: Add a -providerPath option to jarsigner
Message-ID: <Cfs1z9-TClvyoTuEDmacD_AY4D_5KRErLw1ytWL1SnA=.6e1520e8-b266-49b3-9b62-e94ff2b99a0d@github.com>

Add the `-providerPath` option to jarsigner to be consistent with keytool.

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

Commit messages:
 - 8281175: Add a -providerPath option to jarsigner

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

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

From lancea at openjdk.java.net  Thu Feb  3 18:14:13 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 3 Feb 2022 18:14:13 GMT
Subject: RFR: 8281104: jar --create should create missing parent
 directories
In-Reply-To: <BoX4psPENqzTaGF7LS8ztXbQmcmRdhcnUvAZBGD_L7E=.45e1d2bf-1123-41ec-a5e8-d842db1f8731@github.com>
References: <BoX4psPENqzTaGF7LS8ztXbQmcmRdhcnUvAZBGD_L7E=.45e1d2bf-1123-41ec-a5e8-d842db1f8731@github.com>
Message-ID: <TrN0CRscD5sLZhJjfETIYgo2g5mwt_NGVake7dnh0kg=.f3be4fde-602c-4492-9c3d-c7fb96c7e632@github.com>

On Wed, 2 Feb 2022 20:21:54 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing parent directories (here `a/b`) on the default file system before storing the JAR file (here `foo.jar`) in the destination directory.

Thank you for taking this on.  Overall looks good.

A few comments below.

Also, we should update jar.properties to indicate that the directory path will be created as needed in the help section for jar.

Best,
Lance

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 468:

> 466:                     if (parent != null) {
> 467:                         Files.createDirectories(parent);
> 468:                     }

Would be good to move the creation after validating the arguments as this would fail after creating the temp zip file.  Be good to do via another PR

test/jdk/tools/jar/CreateMissingParentDirectories.java line 38:

> 36: import java.util.stream.Stream;
> 37: 
> 38: public class CreateMissingParentDirectories {

Understand why you used went this route for the test given some of the older tests use this framework.  I might have gone the route of using TestNG as the newer tests (such as in MultiRelease) use it.

test/jdk/tools/jar/CreateMissingParentDirectories.java line 78:

> 76: 
> 77:     private static void doHappyPathTest(Path jar, Path entry) throws Throwable {
> 78:         String[] jarArgs = new String[]{"cf", jar.toString(), entry.toString()};

I might consider also using --create --file in addition to "cf" in a run for an extra sanity check

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

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

From cstein at openjdk.java.net  Thu Feb  3 19:45:12 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Thu, 3 Feb 2022 19:45:12 GMT
Subject: RFR: 8281104: jar --create should create missing parent
 directories
In-Reply-To: <BoX4psPENqzTaGF7LS8ztXbQmcmRdhcnUvAZBGD_L7E=.45e1d2bf-1123-41ec-a5e8-d842db1f8731@github.com>
References: <BoX4psPENqzTaGF7LS8ztXbQmcmRdhcnUvAZBGD_L7E=.45e1d2bf-1123-41ec-a5e8-d842db1f8731@github.com>
Message-ID: <oqrbqNByddWXXCE_RZnfNeh0ue9daPaRbZq90mjyh54=.d583835b-3488-4d3d-a004-b70f7b1b9945@github.com>

On Wed, 2 Feb 2022 20:21:54 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing parent directories (here `a/b`) on the default file system before storing the JAR file (here `foo.jar`) in the destination directory.

Thanks for the review, Lance.

I didn't change order of creation, validation, and movement of the temporary JAR file in order to keep existing behaviour consistent.

A reason to use the main-based testing approach was also the ability to run the test via JEP 330:
`java CreateMissingParentDirectories.java`

> Also, we should update jar.properties to indicate that the directory path will be created as needed in the help section for jar.

That's a good point. Where would we put that information?
- [ ] Extend the descriptions of option `c`/`--create` and/or option `f`/`--file`?
- [ ] As a post scriptum note below the options?
  https://github.com/openjdk/jdk/blob/master/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties#L309-L317

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

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

From lancea at openjdk.java.net  Thu Feb  3 21:46:09 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 3 Feb 2022 21:46:09 GMT
Subject: RFR: 8281104: jar --create should create missing parent
 directories
In-Reply-To: <oqrbqNByddWXXCE_RZnfNeh0ue9daPaRbZq90mjyh54=.d583835b-3488-4d3d-a004-b70f7b1b9945@github.com>
References: <BoX4psPENqzTaGF7LS8ztXbQmcmRdhcnUvAZBGD_L7E=.45e1d2bf-1123-41ec-a5e8-d842db1f8731@github.com>
 <oqrbqNByddWXXCE_RZnfNeh0ue9daPaRbZq90mjyh54=.d583835b-3488-4d3d-a004-b70f7b1b9945@github.com>
Message-ID: <0aVktv5u2S4HJeVzXxJkr2O4jE5SlOv2J73sFwEJf2A=.3af0f5f4-28b0-474f-b1a7-4502b41bd983@github.com>

On Thu, 3 Feb 2022 19:42:25 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Thanks for the review, Lance.
> 
> I didn't change order of creation, validation, and movement of the temporary JAR file in order to keep existing behaviour consistent.

I do think we are better served with the validation check earlier on.  In the case of a failure, we do not make the tmp file name known so it could be easy to miss. 

I think it makes sense to report the issue before erring out after creating the jar..  If the behavior stays as is, it would be best to document that the tmp file would still be there.

Let's see what others think.  Either way we can accomplish the additional change if we reach consensus via a separate PR.
> 
> A reason to use the main-based testing approach was also the ability to run the test via JEP 330: `java CreateMissingParentDirectories.java`

For me personally,  I would not use that means to run the tests as typically  would from an IDE.  Plus there is a benefit of leveraging the test framework in TestNG.    I totally understand everyone has a personal preference.  A discussion for another day I guess ;-).
> 
> > Also, we should update jar.properties to indicate that the directory path will be created as needed in the help section for jar.
> 
> That's a good point. Where would we put that information?
> 
> * [ ]  Extend the descriptions of option `c`/`--create` and/or option `f`/`--file`?

I think this would be the appropriate place for documenting the behavior.

> * [ ]  As a post scriptum note below the options?
>   https://github.com/openjdk/jdk/blob/master/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties#L309-L317


Also we will need to update the MD file which represents the jar man page via a separate PR.

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

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

From aturbanov at openjdk.java.net  Fri Feb  4 07:10:18 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Fri, 4 Feb 2022 07:10:18 GMT
Subject: RFR: 8274425: Remove unused Modules.extraLimitMods [v2]
In-Reply-To: <_VSeie5GC-sPX0apREmPYJCW__5cwX-EdClVUMJMlls=.84b4e3eb-7f53-438a-b180-588e67d9f3df@github.com>
References: <3XU4OpaQ6kW3DXLru4uScWtbIQBiYgHyoUPBdkkoo-g=.bd1ac042-fb54-4b37-9433-d4c0c5990e6f@github.com>
 <_VSeie5GC-sPX0apREmPYJCW__5cwX-EdClVUMJMlls=.84b4e3eb-7f53-438a-b180-588e67d9f3df@github.com>
Message-ID: <F0FPgi6NBqUMH7xEdd3-EM5USrR8eYrzY-hJTr2DdH8=.2dd0ab5b-3bbe-4024-a2b3-2286b06782fc@github.com>

On Mon, 10 Jan 2022 11:08:52 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> HashSet `com.sun.tools.javac.comp.Modules.extraLimitMods` is always empty. Code only check its content, but no content added.
>> There was a method `addExtraLimitModules`, but it was removed under [JDK-8175191](https://bugs.openjdk.java.net/browse/JDK-8175191) 253fdcd0b26
>> Method `addExtraLimitModules` itself was added in ec9ca2997f4, but was never actually used .
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8274425: Remove unused Modules.extraLimitMods
>   
>   update copyright year

Can I get the review, please?

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

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

From cstein at openjdk.java.net  Fri Feb  4 21:36:07 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Fri, 4 Feb 2022 21:36:07 GMT
Subject: RFR: 8281104: jar --create should create missing parent
 directories
In-Reply-To: <0aVktv5u2S4HJeVzXxJkr2O4jE5SlOv2J73sFwEJf2A=.3af0f5f4-28b0-474f-b1a7-4502b41bd983@github.com>
References: <BoX4psPENqzTaGF7LS8ztXbQmcmRdhcnUvAZBGD_L7E=.45e1d2bf-1123-41ec-a5e8-d842db1f8731@github.com>
 <oqrbqNByddWXXCE_RZnfNeh0ue9daPaRbZq90mjyh54=.d583835b-3488-4d3d-a004-b70f7b1b9945@github.com>
 <0aVktv5u2S4HJeVzXxJkr2O4jE5SlOv2J73sFwEJf2A=.3af0f5f4-28b0-474f-b1a7-4502b41bd983@github.com>
Message-ID: <zWhnw__FahGP-bezjW4Tw8jABLnmJWxkt7y1WA_mgKQ=.a6ae9220-da14-4ac4-834e-e60a6e16239e@github.com>

On Thu, 3 Feb 2022 21:43:30 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I think this would be the appropriate place for documenting the behavior.

Like this? 


-c, --create               Create the archive. When the path specified by -f, --file
                           contains a path, missing parent directories will also be created
...
-f, --file=FILE            The archive file name. When omitted, either stdin or
                           stdout is used based on the operation. Missing parent
                           directories of the file name path will be created


Perhaps, only adding it to `-c, --create` suffices. Having it also on `-f, --file` may confuse users, as this option is used all operation modes.

> Also we will need to update the MD file which represents the jar man page via a separate PR.

Yes. Will create PR for this.

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

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

From lancea at openjdk.java.net  Fri Feb  4 21:40:06 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 4 Feb 2022 21:40:06 GMT
Subject: RFR: 8281104: jar --create should create missing parent
 directories
In-Reply-To: <BoX4psPENqzTaGF7LS8ztXbQmcmRdhcnUvAZBGD_L7E=.45e1d2bf-1123-41ec-a5e8-d842db1f8731@github.com>
References: <BoX4psPENqzTaGF7LS8ztXbQmcmRdhcnUvAZBGD_L7E=.45e1d2bf-1123-41ec-a5e8-d842db1f8731@github.com>
Message-ID: <cAmEZuFZbV41LOrsJDEESZ9HujSfUBCmx-0XOXttRC4=.3dd17ae6-f9f6-4e8f-b0b7-9549ed377bc1@github.com>

On Wed, 2 Feb 2022 20:21:54 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing parent directories (here `a/b`) on the default file system before storing the JAR file (here `foo.jar`) in the destination directory.

> > I think this would be the appropriate place for documenting the behavior.
> 
> Like this?
> 
> ```
> -c, --create               Create the archive. When the path specified by -f, --file
>                            contains a path, missing parent directories will also be created
> ...
> -f, --file=FILE            The archive file name. When omitted, either stdin or
>                            stdout is used based on the operation. Missing parent
>                            directories of the file name path will be created
> ```
> 
> Perhaps, only adding it to `-c, --create` suffices. Having it also on `-f, --file` may confuse users, as this option is used all operation modes.

I think just having the verbiage when creating the jar should suffice as if we were updating it, the path would need to exist already.
> 
> > Also we will need to update the MD file which represents the jar man page via a separate PR.
> 
> Yes. Will create PR for this.

Great, thank you.  Have a good weekend!

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

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

From cstein at openjdk.java.net  Fri Feb  4 21:58:49 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Fri, 4 Feb 2022 21:58:49 GMT
Subject: RFR: 8281104: jar --create should create missing parent
 directories [v2]
In-Reply-To: <BoX4psPENqzTaGF7LS8ztXbQmcmRdhcnUvAZBGD_L7E=.45e1d2bf-1123-41ec-a5e8-d842db1f8731@github.com>
References: <BoX4psPENqzTaGF7LS8ztXbQmcmRdhcnUvAZBGD_L7E=.45e1d2bf-1123-41ec-a5e8-d842db1f8731@github.com>
Message-ID: <trId6aFVqSHx4PX1EvLxV7ICj122FO9VXnZ4B2DzplA=.5f35e77c-7069-4b9c-bb78-fa5324d17b74@github.com>

> Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing parent directories (here `a/b`) on the default file system before storing the JAR file (here `foo.jar`) in the destination directory.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Extend help text for option `-c, --create`

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7327/files
  - new: https://git.openjdk.java.net/jdk/pull/7327/files/f34e767a..65105a36

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

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

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

From lancea at openjdk.java.net  Fri Feb  4 21:58:50 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 4 Feb 2022 21:58:50 GMT
Subject: RFR: 8281104: jar --create should create missing parent
 directories [v2]
In-Reply-To: <trId6aFVqSHx4PX1EvLxV7ICj122FO9VXnZ4B2DzplA=.5f35e77c-7069-4b9c-bb78-fa5324d17b74@github.com>
References: <BoX4psPENqzTaGF7LS8ztXbQmcmRdhcnUvAZBGD_L7E=.45e1d2bf-1123-41ec-a5e8-d842db1f8731@github.com>
 <trId6aFVqSHx4PX1EvLxV7ICj122FO9VXnZ4B2DzplA=.5f35e77c-7069-4b9c-bb78-fa5324d17b74@github.com>
Message-ID: <txHELerhBZYelk3B7LSh0a1wR2fiX58kF45CYXlV09A=.79cf3c2c-d265-4e3d-a34a-b6823a1227d6@github.com>

On Fri, 4 Feb 2022 21:55:28 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing parent directories (here `a/b`) on the default file system before storing the JAR file (here `foo.jar`) in the destination directory.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extend help text for option `-c, --create`

The current changes look good overall

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

Marked as reviewed by lancea (Reviewer).

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

From cstein at openjdk.java.net  Fri Feb  4 21:58:51 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Fri, 4 Feb 2022 21:58:51 GMT
Subject: RFR: 8281104: jar --create should create missing parent
 directories
In-Reply-To: <BoX4psPENqzTaGF7LS8ztXbQmcmRdhcnUvAZBGD_L7E=.45e1d2bf-1123-41ec-a5e8-d842db1f8731@github.com>
References: <BoX4psPENqzTaGF7LS8ztXbQmcmRdhcnUvAZBGD_L7E=.45e1d2bf-1123-41ec-a5e8-d842db1f8731@github.com>
Message-ID: <VV9OM7tuM98Gtu0C-1YTL7GyjA1uuRPE38pgeHfPp2c=.105ee305-93fb-4e23-a3d9-d56bd174aa47@github.com>

On Wed, 2 Feb 2022 20:21:54 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing parent directories (here `a/b`) on the default file system before storing the JAR file (here `foo.jar`) in the destination directory.

Should I also extend this "usage.compat" help message block? When and where is it displayed? ?? 

https://github.com/openjdk/jdk/blob/48523b090886f7b24ed4009f0c150efaa6f7b056/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties#L167-L173

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

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

From lancea at openjdk.java.net  Fri Feb  4 22:12:12 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 4 Feb 2022 22:12:12 GMT
Subject: RFR: 8281104: jar --create should create missing parent
 directories
In-Reply-To: <VV9OM7tuM98Gtu0C-1YTL7GyjA1uuRPE38pgeHfPp2c=.105ee305-93fb-4e23-a3d9-d56bd174aa47@github.com>
References: <BoX4psPENqzTaGF7LS8ztXbQmcmRdhcnUvAZBGD_L7E=.45e1d2bf-1123-41ec-a5e8-d842db1f8731@github.com>
 <VV9OM7tuM98Gtu0C-1YTL7GyjA1uuRPE38pgeHfPp2c=.105ee305-93fb-4e23-a3d9-d56bd174aa47@github.com>
Message-ID: <UpSX1gtwpoqZar418hIF4cN47SpNPaoXas4KAsClPbg=.91d01997-0531-4b27-92f0-6cd9804bd98f@github.com>

On Fri, 4 Feb 2022 21:47:16 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Should I also extend this "usage.compat" help message block? When and where is it displayed? ??
> 
> https://github.com/openjdk/jdk/blob/48523b090886f7b24ed4009f0c150efaa6f7b056/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties#L167-L173

I guess that makes sense.  Not sure how often anyone looks at this but good for consistency.  
Thanks for the reminder of the help message for compat

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

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

From cstein at openjdk.java.net  Fri Feb  4 22:29:45 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Fri, 4 Feb 2022 22:29:45 GMT
Subject: RFR: 8281104: jar --create should create missing parent
 directories [v3]
In-Reply-To: <BoX4psPENqzTaGF7LS8ztXbQmcmRdhcnUvAZBGD_L7E=.45e1d2bf-1123-41ec-a5e8-d842db1f8731@github.com>
References: <BoX4psPENqzTaGF7LS8ztXbQmcmRdhcnUvAZBGD_L7E=.45e1d2bf-1123-41ec-a5e8-d842db1f8731@github.com>
Message-ID: <GBEg4NO0BizhgX4l1YlEzJIp-3yoJaypt5fRCbuMiPY=.8c9b816a-1bed-46ce-bd35-60d4eb41274c@github.com>

> Calling `jar --create --file a/b/foo.jar INPUT-FILES` should create missing parent directories (here `a/b`) on the default file system before storing the JAR file (here `foo.jar`) in the destination directory.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Update help text of Compatibility Interface

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7327/files
  - new: https://git.openjdk.java.net/jdk/pull/7327/files/65105a36..f810c810

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

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

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

From ethan at mccue.dev  Sat Feb  5 02:10:40 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Fri, 4 Feb 2022 21:10:40 -0500
Subject: Source file launch with security manager enabled fails
In-Reply-To: <1a7b61fc-4c31-862a-25be-4bb407633e84@oracle.com>
References: <b26e2754-5849-3d2b-3a06-f3df665c7ebb@gmail.com>
 <0c8d4988-cee1-0c75-f39f-f24c51e19100@oracle.com>
 <1a7b61fc-4c31-862a-25be-4bb407633e84@oracle.com>
Message-ID: <CA+NR86gpJtnN+neFGY-Jr3gV46Vmf=-6B3yCQFDN1=qACjmO5Q@mail.gmail.com>

While early learning was the goal, there are already build systems being
made that make use of the single file mode as a bootstrapping mechanism

https://github.com/sormuras/bach

That being said, it doesn't seem like it's a use case that deserves much
given that the security manager is deprecated for removal.

On Thu, Feb 3, 2022 at 8:38 AM Alan Bateman <Alan.Bateman at oracle.com> wrote:

>
> I think it would be useful to hear from Jon Gibbons or someone else
> working on javac first. It would be a bit unusual to run the compiler
> with a security manager and I thought it was deliberate to not grant
> permissions to jdk.compiler in the default policy. Also the source code
> launcher is aimed at the early stages of learning Java where there
> shouldn't be advanced options or exotic execution modes.
>
> -Alan
>
>
> On 03/02/2022 13:25, Sean Mullan wrote:
> > I only took a quick look, but it looks like a bug. The jdk.compiler
> > module needs to be granted that permission in the default.policy file.
> >
> > Please file a bug, or if you like I can file one on your behalf.
> >
> > Thanks,
> > Sean
> >
> > On 2/3/22 8:01 AM, Jaikiran Pai wrote:
> >> I'm unsure if core-libs is the right place for this or compiler-dev,
> >> sending this to core-libs for now.
> >>
> >> Please consider this trivial Java source file:
> >>
> >> public class HelloWorld {
> >>       public static void main(final String[] args) throws Exception {
> >>           System.out.println("Hello World");
> >>       }
> >> }
> >>
> >> Running this in source file launcher mode as follows:
> >>
> >> java HelloWorld.java
> >>
> >> returns the expected result. However when running in source file
> >> launcher mode *and* with security manager enabled, it throws the
> >> following exception:
> >>
> >> java -Djava.security.manager=default HelloWorld.java
> >>
> >> WARNING: A command line option has enabled the Security Manager
> >> WARNING: The Security Manager is deprecated and will be removed in a
> >> future release
> >> Exception in thread "main" java.security.AccessControlException: access
> >> denied ("java.lang.RuntimePermission"
> >> "accessClassInPackage.jdk.internal.misc")
> >>       at
> >>
> java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:485)
>
> >>
> >>       at
> >>
> java.base/java.security.AccessController.checkPermission(AccessController.java:1068)
>
> >>
> >>       at
> >>
> java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:416)
>
> >>
> >>       at
> >>
> java.base/java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1332)
>
> >>
> >>       at
> >>
> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:184)
>
> >>
> >>       at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
> >>       at
> >> jdk.compiler/com.sun.tools.javac.launcher.Main.main(Main.java:132)
> >>
> >>
> >> This happens in Java 17 as well as latest master branch. I haven't
> >> checked older releases but I guess it's reproducible there too.
> >>
> >> Are users expected to use an explicit policy file to add this permission
> >> in source file launch mode or is this missing an internal doPrivileged
> >> call in the JDK?
> >>
> >> As an additional input, compiling this file first using javac and then
> >> launching it in traditional mode with security manager enabled works
> >> fine:
> >>
> >> javac HelloWorld.java
> >>
> >> java -Djava.security.manager=default HelloWorld
> >> WARNING: A command line option has enabled the Security Manager
> >> WARNING: The Security Manager is deprecated and will be removed in a
> >> future release
> >> Hello World
> >>
> >>
> >> -Jaikiran
> >>
> >>
> >>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20220204/c599cbed/attachment.htm>

From shade at openjdk.java.net  Wed Feb  9 06:51:46 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 9 Feb 2022 06:51:46 GMT
Subject: RFR: 8281507: Two javac tests have bad jtreg `@clean` tags
Message-ID: <BP2PZ4WTeQnNFmOKcRcdjWKZvv11DZr4sz1pScJYGl4=.630c487a-a7f1-485c-bdf7-95c1b80aab15@github.com>

Apparently, jtreg does not support `*` globbing. It now throws errors for upcoming jtreg 7.

Additional testing:
 - [x] Affected tests still pass

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

Commit messages:
 - Fix

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

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

From jlahoda at openjdk.java.net  Wed Feb  9 09:46:32 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 9 Feb 2022 09:46:32 GMT
Subject: RFR: 8281100: Spurious "variable might not have been initialized" with
 sealed class switch
Message-ID: <B1scW4OhFxSp3vumb1WKgR0ZRSEtOFe7MeIvWor1nkA=.8c9d502d-d901-46cc-b247-8ed145deccb2@github.com>

Consider:

interface I permits A, B {}

String data;
I i = ...;
switch (i) {
    case A a -> data = 0;
    case B b -> data = 0;
}
System.err.println(data); //incorrect error here


The specification says that `data` is definitely assigned as the `System.err.println`, as the switch covers `I`, but javac will report an error that the variable may not be assigned.

This patch fixes that - the only tricky part is that if there's an error in the switch (like when the switch is expected to be exhaustive, but is not), the current patch will try to suppress the follow-up "variable may not be assigned" errors. As an example:

interface I permits A, B {}

String data;
I i = ...;
switch (i) { //error here, not exhaustive
    case A a -> data = 0;
}
System.err.println(data); //no error here, due to the preceding exhaustiveness error

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

Commit messages:
 - 8281100: Spurious "variable might not have been initialized" with sealed class switch

Changes: https://git.openjdk.java.net/jdk/pull/7402/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7402&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281100
  Stats: 107 lines in 4 files changed: 90 ins; 3 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7402.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7402/head:pull/7402

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

From cstein at openjdk.java.net  Wed Feb  9 19:18:38 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Wed, 9 Feb 2022 19:18:38 GMT
Subject: RFR: 8280825: Modules that "provide" ToolProvider should document the
 name that can be used
Message-ID: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>

A number of modules declare that the "provide" ToolProvider.

These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag.

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

Commit messages:
 - Separate service type and description text into distinct blocks
 - 8280825: Modules that "provide" ToolProvider should document the name that can be used

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

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

From jjg at openjdk.java.net  Wed Feb  9 19:18:39 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 9 Feb 2022 19:18:39 GMT
Subject: RFR: 8280825: Modules that "provide" ToolProvider should document
 the name that can be used
In-Reply-To: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
References: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
Message-ID: <bO7cDMsa-4fuTqerOUWb0OlCqSCEKUcqBFRKdiTsk-o=.954e27df-7387-4edc-b642-a006430db0ef@github.com>

On Wed, 9 Feb 2022 16:37:00 GMT, Christian Stein <cstein at openjdk.org> wrote:

> A number of modules declare that the "provide" ToolProvider.
> 
> These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag.

Minor format suggestion:  add a newline after the service name, to start the description on its own line, as in:


@provides <service-name>
        <description>


This form would extend well to any modules that provide the service in different ways ... i.e. with different names for `TP.findFirst` to obtain different instances.

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

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

From lancea at openjdk.java.net  Wed Feb  9 19:34:13 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 9 Feb 2022 19:34:13 GMT
Subject: RFR: 8280825: Modules that "provide" ToolProvider should document
 the name that can be used
In-Reply-To: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
References: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
Message-ID: <Dll33X9MuBCtroOV0744N2UuXTUOglcoN1NJjICXU5U=.ce2cc54d-3d12-400c-9e0f-0565369522b5@github.com>

On Wed, 9 Feb 2022 16:37:00 GMT, Christian Stein <cstein at openjdk.org> wrote:

> A number of modules declare that the "provide" ToolProvider.
> 
> These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag.

Marked as reviewed by lancea (Reviewer).

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

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

From jjg at openjdk.java.net  Wed Feb  9 20:24:10 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 9 Feb 2022 20:24:10 GMT
Subject: RFR: 8280825: Modules that "provide" ToolProvider should document
 the name that can be used
In-Reply-To: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
References: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
Message-ID: <6kBOt7R1nPvpcwNdZ5FmmB9ZbhwOw2daNlg_kyf1JSQ=.31dc4ce2-23f5-401e-ab6a-0dab5e7d2c23@github.com>

On Wed, 9 Feb 2022 16:37:00 GMT, Christian Stein <cstein at openjdk.org> wrote:

> A number of modules declare that the "provide" ToolProvider.
> 
> These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag.

Would it be more pedantically accurate to talk about getting an instance of the _tool provider_ (not just _tool_)?

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

Marked as reviewed by jjg (Reviewer).

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

From cstein at openjdk.java.net  Wed Feb  9 20:35:10 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Wed, 9 Feb 2022 20:35:10 GMT
Subject: RFR: 8280825: Modules that "provide" ToolProvider should document
 the name that can be used
In-Reply-To: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
References: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
Message-ID: <BLuF-nJKz6YnyjApANxP-n9lW_FZZI_S0WgqUp4lA2o=.8db6b43b-ebb8-4aa7-8fe0-036f60170210@github.com>

On Wed, 9 Feb 2022 16:37:00 GMT, Christian Stein <cstein at openjdk.org> wrote:

> A number of modules declare that the "provide" ToolProvider.
> 
> These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag.

> Would it be more pedantically accurate to talk about getting an instance of the tool provider (not just tool)?

Yes. That would be more correct.

My wording was aligned to the one used in the main description block, which also talks about "tool(s)". For example:


 * <p> Instances of the tools can be obtained by calling
 * {@link java.util.spi.ToolProvider#findFirst ToolProvider.findFirst}
 * or the {@linkplain java.util.ServiceLoader service loader} with the name
 * {@code "javac"}.

_Here, it should read "Instances of the tool can be..." and not "Instances of the tools can be..." - right? As there's only a single one provided by this module._

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

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

From alanb at openjdk.java.net  Wed Feb  9 20:35:10 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 9 Feb 2022 20:35:10 GMT
Subject: RFR: 8280825: Modules that "provide" ToolProvider should document
 the name that can be used
In-Reply-To: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
References: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
Message-ID: <JIlx1vMqpD30pENymOcPwy9gHHBQSNzyxEUpG2ONbIo=.c325659e-74f2-4e3a-aa9f-582cec32f18c@github.com>

On Wed, 9 Feb 2022 16:37:00 GMT, Christian Stein <cstein at openjdk.org> wrote:

> A number of modules declare that the "provide" ToolProvider.
> 
> These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag.

src/jdk.jartool/share/classes/module-info.java line 45:

> 43:  *         Pass {@code "jar"} as the name to
> 44:  *         {@link java.util.spi.ToolProvider#findFirst ToolProvider.findFirst}
> 45:  *         in order to obtain an instance of the tool.

I'm not sure about the wording. It might be better to say that it provides a tool named "jar". Invoke findFirst("jar") to create an instance of this tool.

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

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

From darcy at openjdk.java.net  Wed Feb  9 21:55:27 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 9 Feb 2022 21:55:27 GMT
Subject: RFR: JDK-8281238: TYPE_USE annotations not printed in correct position
 in toString output
Message-ID: <8ou4K82I4h1Y6lWtVPdCfwWNTG9YPxm-rQBxN7ZHSCc=.cab9dde1-4745-4878-b011-12da1b6eaab5@github.com>

To use a type annotation on a fully qualified type name, the annotations must appear between the package name and the type:

    java.lang. @TypeAnnotation String // good

and *not* before the fully qualified name

   @TypeAnnotation java.lang.String // bad

This required ordering is not preserved in the toString output of TypeMirrors in annotation processing. This changeset corrects that and updates a few tests that assume the older formatting.

(This listed update to the given toString method is necessary; I don't believe any of the other Type toString methods also need to be updated, but some might need updating too.)

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

Commit messages:
 - Appease jcheck.
 - Update copyright and add bug ids to tests.
 - JDK-8281238: TYPE_USE annotations not printed in correct position in toString output

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

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

From vromero at openjdk.java.net  Wed Feb  9 23:00:13 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 9 Feb 2022 23:00:13 GMT
Subject: RFR: 8281100: Spurious "variable might not have been initialized"
 with sealed class switch
In-Reply-To: <B1scW4OhFxSp3vumb1WKgR0ZRSEtOFe7MeIvWor1nkA=.8c9d502d-d901-46cc-b247-8ed145deccb2@github.com>
References: <B1scW4OhFxSp3vumb1WKgR0ZRSEtOFe7MeIvWor1nkA=.8c9d502d-d901-46cc-b247-8ed145deccb2@github.com>
Message-ID: <yUZivrArbXeskcoOwB_4BDTrRUXDaVUmbx3fIY8N-j4=.93376352-d66d-42a8-b7ea-69a5d21effb8@github.com>

On Wed, 9 Feb 2022 09:40:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider:
> 
> interface I permits A, B {}
> 
> String data;
> I i = ...;
> switch (i) {
>     case A a -> data = 0;
>     case B b -> data = 0;
> }
> System.err.println(data); //incorrect error here
> 
> 
> The specification says that `data` is definitely assigned as the `System.err.println`, as the switch covers `I`, but javac will report an error that the variable may not be assigned.
> 
> This patch fixes that - the only tricky part is that if there's an error in the switch (like when the switch is expected to be exhaustive, but is not), the current patch will try to suppress the follow-up "variable may not be assigned" errors. As an example:
> 
> interface I permits A, B {}
> 
> String data;
> I i = ...;
> switch (i) { //error here, not exhaustive
>     case A a -> data = 0;
> }
> System.err.println(data); //no error here, due to the preceding exhaustiveness error

looks sensible

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

Marked as reviewed by vromero (Reviewer).

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

From vromero at openjdk.java.net  Wed Feb  9 23:06:10 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 9 Feb 2022 23:06:10 GMT
Subject: RFR: 8281100: Spurious "variable might not have been initialized"
 with sealed class switch
In-Reply-To: <B1scW4OhFxSp3vumb1WKgR0ZRSEtOFe7MeIvWor1nkA=.8c9d502d-d901-46cc-b247-8ed145deccb2@github.com>
References: <B1scW4OhFxSp3vumb1WKgR0ZRSEtOFe7MeIvWor1nkA=.8c9d502d-d901-46cc-b247-8ed145deccb2@github.com>
Message-ID: <XYylDHIv9Yru9Em8hT77L2UjF_l0Xtch8BLrfPpIMDA=.9667b60e-76e7-44b8-ad38-26bc0151dbaf@github.com>

On Wed, 9 Feb 2022 09:40:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider:
> 
> interface I permits A, B {}
> 
> String data;
> I i = ...;
> switch (i) {
>     case A a -> data = 0;
>     case B b -> data = 0;
> }
> System.err.println(data); //incorrect error here
> 
> 
> The specification says that `data` is definitely assigned as the `System.err.println`, as the switch covers `I`, but javac will report an error that the variable may not be assigned.
> 
> This patch fixes that - the only tricky part is that if there's an error in the switch (like when the switch is expected to be exhaustive, but is not), the current patch will try to suppress the follow-up "variable may not be assigned" errors. As an example:
> 
> interface I permits A, B {}
> 
> String data;
> I i = ...;
> switch (i) { //error here, not exhaustive
>     case A a -> data = 0;
> }
> System.err.println(data); //no error here, due to the preceding exhaustiveness error

this test case is failing for me, I was expecting it to compile:


sealed interface I permits A, B {}

final class A implements I {}

final class B implements I {}

class Test {
    void m(I i) {
        int data;
        switch (i) {
            case A a -> data = 0;
            case B b -> data = 0;
        };
        System.err.println(data);
    }
}

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

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

From jjg at openjdk.java.net  Wed Feb  9 23:19:09 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 9 Feb 2022 23:19:09 GMT
Subject: RFR: 8281507: Two javac tests have bad jtreg `@clean` tags
In-Reply-To: <BP2PZ4WTeQnNFmOKcRcdjWKZvv11DZr4sz1pScJYGl4=.630c487a-a7f1-485c-bdf7-95c1b80aab15@github.com>
References: <BP2PZ4WTeQnNFmOKcRcdjWKZvv11DZr4sz1pScJYGl4=.630c487a-a7f1-485c-bdf7-95c1b80aab15@github.com>
Message-ID: <xCFL625ndkyZEpK8TCo5S9r3SjC2bNN9CAeKGlXQXQU=.44fd56ef-4ff5-4ece-bd6f-fdf966e69ecd@github.com>

On Wed, 9 Feb 2022 06:44:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Apparently, jtreg does not support `*` globbing. It now throws errors for upcoming jtreg 7.
> 
> Additional testing:
>  - [x] Affected tests still pass

Suggest using `@clean *` to remove all previously compiled class files for the test. This seems closest to the original intent.

test/langtools/tools/javac/8074306/TestSyntheticNullChecks.java line 30:

> 28:  * @compile -source 7 -target 7 TestSyntheticNullChecks.java
> 29:  * @run main TestSyntheticNullChecks 7
> 30:  * @clean TestSyntheticNullChecks

This test class has an inner class.  If the original intent was to try to remove all class files, the change is not equivalent, and will not do that; it will clean the main class, but not the nested class.

You may want to use `@clean *` instead, which will clean (remove) all class files in the default package.

test/langtools/tools/javac/StringConcat/TestIndyStringConcat.java line 37:

> 35:  * @modules jdk.jdeps/com.sun.tools.classfile
> 36:  *
> 37:  * @clean TestIndyStringConcat

While this class does not appear to generate any nested classes, you may still want to use `@clean *` to ensure that any/all previously generated class files are removed.

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

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

From jjg at openjdk.java.net  Thu Feb 10 02:23:11 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 10 Feb 2022 02:23:11 GMT
Subject: RFR: 8280825: Modules that "provide" ToolProvider should document
 the name that can be used
In-Reply-To: <JIlx1vMqpD30pENymOcPwy9gHHBQSNzyxEUpG2ONbIo=.c325659e-74f2-4e3a-aa9f-582cec32f18c@github.com>
References: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
 <JIlx1vMqpD30pENymOcPwy9gHHBQSNzyxEUpG2ONbIo=.c325659e-74f2-4e3a-aa9f-582cec32f18c@github.com>
Message-ID: <afDRKISO8d6usemIy1Cc8XwiOh4iZkLGWKAxo-bXuqw=.61eae219-e2cb-4a29-a124-b3c1665226fd@github.com>

On Wed, 9 Feb 2022 20:33:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> A number of modules declare that the "provide" ToolProvider.
>> 
>> These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag.
>
> src/jdk.jartool/share/classes/module-info.java line 45:
> 
>> 43:  *         Pass {@code "jar"} as the name to
>> 44:  *         {@link java.util.spi.ToolProvider#findFirst ToolProvider.findFirst}
>> 45:  *         in order to obtain an instance of the tool.
> 
> I'm not sure about the wording. It might be better to say that it provides a tool named "jar". Invoke findFirst("jar") to create an instance of this tool.

What is "it" in "it provides..." ?

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

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

From cstein at openjdk.java.net  Thu Feb 10 03:08:10 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Thu, 10 Feb 2022 03:08:10 GMT
Subject: RFR: 8280825: Modules that "provide" ToolProvider should document
 the name that can be used
In-Reply-To: <afDRKISO8d6usemIy1Cc8XwiOh4iZkLGWKAxo-bXuqw=.61eae219-e2cb-4a29-a124-b3c1665226fd@github.com>
References: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
 <JIlx1vMqpD30pENymOcPwy9gHHBQSNzyxEUpG2ONbIo=.c325659e-74f2-4e3a-aa9f-582cec32f18c@github.com>
 <afDRKISO8d6usemIy1Cc8XwiOh4iZkLGWKAxo-bXuqw=.61eae219-e2cb-4a29-a124-b3c1665226fd@github.com>
Message-ID: <yyYtSRF_BtpmIj_jI23kzF3ILKJT5TDWTR7vP4bseOk=.62a36950-ab54-4a9f-b666-62fadc5e256e@github.com>

On Thu, 10 Feb 2022 02:19:36 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/module-info.java line 45:
>> 
>>> 43:  *         Pass {@code "jar"} as the name to
>>> 44:  *         {@link java.util.spi.ToolProvider#findFirst ToolProvider.findFirst}
>>> 45:  *         in order to obtain an instance of the tool.
>> 
>> I'm not sure about the wording. It might be better to say that it provides a tool named "jar". Invoke findFirst("jar") to create an instance of this tool.
>
> What is "it" in "it provides..." ?

Perhaps like this?


/**
 * ...
 * @provides java.util.spi.ToolProvider
 *         Module {@code jdk.jartool} provides a tool named {@code "jar"}.
 *         Invoke {@link java.util.spi.ToolProvider#findFirst ToolProvider.findFirst("jar")}
 *         to create an instance of this tool.
 * ...
 */

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

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

From shade at openjdk.java.net  Thu Feb 10 07:09:46 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 10 Feb 2022 07:09:46 GMT
Subject: RFR: 8281507: Two javac tests have bad jtreg `@clean` tags [v2]
In-Reply-To: <BP2PZ4WTeQnNFmOKcRcdjWKZvv11DZr4sz1pScJYGl4=.630c487a-a7f1-485c-bdf7-95c1b80aab15@github.com>
References: <BP2PZ4WTeQnNFmOKcRcdjWKZvv11DZr4sz1pScJYGl4=.630c487a-a7f1-485c-bdf7-95c1b80aab15@github.com>
Message-ID: <E7fufqq_wWXAiY67VKyX2QqEkNbhffZuUW3s967fWtE=.35550f01-bc2d-4403-939f-2dc5b7937df4@github.com>

> Apparently, jtreg does not support `*` globbing. It now throws errors for upcoming jtreg 7.
> 
> Additional testing:
>  - [x] Affected tests still pass

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Use clean * instead

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7398/files
  - new: https://git.openjdk.java.net/jdk/pull/7398/files/15b4a79f..598f013f

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

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

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

From shade at openjdk.java.net  Thu Feb 10 07:09:49 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 10 Feb 2022 07:09:49 GMT
Subject: RFR: 8281507: Two javac tests have bad jtreg `@clean` tags [v2]
In-Reply-To: <xCFL625ndkyZEpK8TCo5S9r3SjC2bNN9CAeKGlXQXQU=.44fd56ef-4ff5-4ece-bd6f-fdf966e69ecd@github.com>
References: <BP2PZ4WTeQnNFmOKcRcdjWKZvv11DZr4sz1pScJYGl4=.630c487a-a7f1-485c-bdf7-95c1b80aab15@github.com>
 <xCFL625ndkyZEpK8TCo5S9r3SjC2bNN9CAeKGlXQXQU=.44fd56ef-4ff5-4ece-bd6f-fdf966e69ecd@github.com>
Message-ID: <lmIpnXOor09FhbelSkqxGrrg1fTWiMA6aSV87ks78Q0=.0ed8011e-eb30-46d9-b726-59a5dad7c64f@github.com>

On Wed, 9 Feb 2022 23:13:43 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use clean * instead
>
> test/langtools/tools/javac/8074306/TestSyntheticNullChecks.java line 30:
> 
>> 28:  * @compile -source 7 -target 7 TestSyntheticNullChecks.java
>> 29:  * @run main TestSyntheticNullChecks 7
>> 30:  * @clean TestSyntheticNullChecks
> 
> This test class has an inner class.  If the original intent was to try to remove all class files, the change is not equivalent, and will not do that; it will clean the main class, but not the nested class.
> 
> You may want to use `@clean *` instead, which will clean (remove) all class files in the default package.

Right, fixed.

> test/langtools/tools/javac/StringConcat/TestIndyStringConcat.java line 37:
> 
>> 35:  * @modules jdk.jdeps/com.sun.tools.classfile
>> 36:  *
>> 37:  * @clean TestIndyStringConcat
> 
> While this class does not appear to generate any nested classes, you may still want to use `@clean *` to ensure that any/all previously generated class files are removed.

Right, fixed.

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

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

From lancea at openjdk.java.net  Thu Feb 10 11:27:09 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 10 Feb 2022 11:27:09 GMT
Subject: RFR: 8280825: Modules that "provide" ToolProvider should document
 the name that can be used
In-Reply-To: <yyYtSRF_BtpmIj_jI23kzF3ILKJT5TDWTR7vP4bseOk=.62a36950-ab54-4a9f-b666-62fadc5e256e@github.com>
References: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
 <JIlx1vMqpD30pENymOcPwy9gHHBQSNzyxEUpG2ONbIo=.c325659e-74f2-4e3a-aa9f-582cec32f18c@github.com>
 <afDRKISO8d6usemIy1Cc8XwiOh4iZkLGWKAxo-bXuqw=.61eae219-e2cb-4a29-a124-b3c1665226fd@github.com>
 <yyYtSRF_BtpmIj_jI23kzF3ILKJT5TDWTR7vP4bseOk=.62a36950-ab54-4a9f-b666-62fadc5e256e@github.com>
Message-ID: <6PtiwnwsLiCIUh7p_ZuVg_ezthZLldYBugkMIfBnNTA=.2e8e10cb-09b0-4c53-940a-b2093c48d391@github.com>

On Thu, 10 Feb 2022 03:04:43 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> What is "it" in "it provides..." ?
>
> Perhaps like this?
> 
> 
> /**
>  * ...
>  * @provides java.util.spi.ToolProvider
>  *         Module {@code jdk.jartool} provides a tool named {@code "jar"}.
>  *         Invoke {@link java.util.spi.ToolProvider#findFirst ToolProvider.findFirst("jar")}
>  *         to create an instance of this tool.
>  * ...
>  */

> Perhaps like this?
> 
> ```java
> /**
>  * ...
>  * @provides java.util.spi.ToolProvider
>  *         Module {@code jdk.jartool} provides a tool named {@code "jar"}.
>  *         Invoke {@link java.util.spi.ToolProvider#findFirst ToolProvider.findFirst("jar")}
>  *         to create an instance of this tool.
>  * ...
>  */
> ```

What about

`Module {@code jdk.jartool) provides the equivalent of command-line access to the {@code "jar"} tool`

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

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

From jlahoda at openjdk.java.net  Thu Feb 10 12:48:08 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 10 Feb 2022 12:48:08 GMT
Subject: RFR: 8281100: Spurious "variable might not have been initialized"
 with sealed class switch
In-Reply-To: <XYylDHIv9Yru9Em8hT77L2UjF_l0Xtch8BLrfPpIMDA=.9667b60e-76e7-44b8-ad38-26bc0151dbaf@github.com>
References: <B1scW4OhFxSp3vumb1WKgR0ZRSEtOFe7MeIvWor1nkA=.8c9d502d-d901-46cc-b247-8ed145deccb2@github.com>
 <XYylDHIv9Yru9Em8hT77L2UjF_l0Xtch8BLrfPpIMDA=.9667b60e-76e7-44b8-ad38-26bc0151dbaf@github.com>
Message-ID: <RxZWG8kIpxXmmxNOsBp9UgLzu0VmnF_0oVkbNravi-Y=.522d298f-b525-4c43-819c-90d49bb680e6@github.com>

On Wed, 9 Feb 2022 23:03:11 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> this test case is failing for me, I was expecting it to compile:
> 
> ```
> sealed interface I permits A, B {}
> 
> final class A implements I {}
> 
> final class B implements I {}
> 
> class Test {
>     void m(I i) {
>         int data;
>         switch (i) {
>             case A a -> data = 0;
>             case B b -> data = 0;
>         };
>         System.err.println(data);
>     }
> }
> ```

Hm, seems to work for me with this patch?

~/src/jdk/jdk (JDK-8281100) $ cat /tmp/Test.java 
sealed interface I permits A, B {}

final class A implements I {}

final class B implements I {}

class Test {
    void m(I i) {
        int data;
        switch (i) {
            case A a -> data = 0;
            case B b -> data = 0;
        };
        System.err.println(data);
    }
}
~/src/jdk/jdk (JDK-8281100) $ ./build/linux-x86_64-server-release/jdk/bin/javac --enable-preview -source 19 /tmp/Test.java 
Note: /tmp/Test.java uses preview features of Java SE 19.
Note: Recompile with -Xlint:preview for details.
~/src/jdk/jdk (JDK-8281100) $ git push origin JDK-8281100
Everything up-to-date

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

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

From vromero at openjdk.java.net  Thu Feb 10 17:12:09 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 10 Feb 2022 17:12:09 GMT
Subject: RFR: 8281100: Spurious "variable might not have been initialized"
 with sealed class switch
In-Reply-To: <B1scW4OhFxSp3vumb1WKgR0ZRSEtOFe7MeIvWor1nkA=.8c9d502d-d901-46cc-b247-8ed145deccb2@github.com>
References: <B1scW4OhFxSp3vumb1WKgR0ZRSEtOFe7MeIvWor1nkA=.8c9d502d-d901-46cc-b247-8ed145deccb2@github.com>
Message-ID: <KqCgHYmdxMU1OTVUYNY33EF9MoMxo1G05AD8KLBM76A=.6ea6c5cf-2094-43a1-876d-72db49f9971d@github.com>

On Wed, 9 Feb 2022 09:40:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider:
> 
> interface I permits A, B {}
> 
> String data;
> I i = ...;
> switch (i) {
>     case A a -> data = 0;
>     case B b -> data = 0;
> }
> System.err.println(data); //incorrect error here
> 
> 
> The specification says that `data` is definitely assigned as the `System.err.println`, as the switch covers `I`, but javac will report an error that the variable may not be assigned.
> 
> This patch fixes that - the only tricky part is that if there's an error in the switch (like when the switch is expected to be exhaustive, but is not), the current patch will try to suppress the follow-up "variable may not be assigned" errors. As an example:
> 
> interface I permits A, B {}
> 
> String data;
> I i = ...;
> switch (i) { //error here, not exhaustive
>     case A a -> data = 0;
> }
> System.err.println(data); //no error here, due to the preceding exhaustiveness error

yep I also can't reproduce the issue, redid everything, I did yesterday, probably some build issue, not sure because I cleaned and rebuilt several times yesterday to be sure, anyway, yes it is working fine for me too now, sorry for the noise,


> > this test case is failing for me, I was expecting it to compile:
> > ```
> > sealed interface I permits A, B {}
> > 
> > final class A implements I {}
> > 
> > final class B implements I {}
> > 
> > class Test {
> >     void m(I i) {
> >         int data;
> >         switch (i) {
> >             case A a -> data = 0;
> >             case B b -> data = 0;
> >         };
> >         System.err.println(data);
> >     }
> > }
> > ```
> 
> Hm, seems to work for me with this patch?
> 
> ```
> ~/src/jdk/jdk (JDK-8281100) $ cat /tmp/Test.java 
> sealed interface I permits A, B {}
> 
> final class A implements I {}
> 
> final class B implements I {}
> 
> class Test {
>     void m(I i) {
>         int data;
>         switch (i) {
>             case A a -> data = 0;
>             case B b -> data = 0;
>         };
>         System.err.println(data);
>     }
> }
> ~/src/jdk/jdk (JDK-8281100) $ ./build/linux-x86_64-server-release/jdk/bin/javac --enable-preview -source 19 /tmp/Test.java 
> Note: /tmp/Test.java uses preview features of Java SE 19.
> Note: Recompile with -Xlint:preview for details.
> ~/src/jdk/jdk (JDK-8281100) $ git push origin JDK-8281100
> Everything up-to-date
> ```

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

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

From jjg at openjdk.java.net  Thu Feb 10 17:30:08 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 10 Feb 2022 17:30:08 GMT
Subject: RFR: 8280825: Modules that "provide" ToolProvider should document
 the name that can be used
In-Reply-To: <6PtiwnwsLiCIUh7p_ZuVg_ezthZLldYBugkMIfBnNTA=.2e8e10cb-09b0-4c53-940a-b2093c48d391@github.com>
References: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
 <JIlx1vMqpD30pENymOcPwy9gHHBQSNzyxEUpG2ONbIo=.c325659e-74f2-4e3a-aa9f-582cec32f18c@github.com>
 <afDRKISO8d6usemIy1Cc8XwiOh4iZkLGWKAxo-bXuqw=.61eae219-e2cb-4a29-a124-b3c1665226fd@github.com>
 <yyYtSRF_BtpmIj_jI23kzF3ILKJT5TDWTR7vP4bseOk=.62a36950-ab54-4a9f-b666-62fadc5e256e@github.com>
 <6PtiwnwsLiCIUh7p_ZuVg_ezthZLldYBugkMIfBnNTA=.2e8e10cb-09b0-4c53-940a-b2093c48d391@github.com>
Message-ID: <6DQ5_BAMP-bV8XkY9txYZBRnXzc3ypCXV9b0YdgvAkk=.7bc88afb-4f9d-4659-9b33-153977afbb34@github.com>

On Thu, 10 Feb 2022 11:24:23 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Perhaps like this?
>> 
>> 
>> /**
>>  * ...
>>  * @provides java.util.spi.ToolProvider
>>  *         Module {@code jdk.jartool} provides a tool named {@code "jar"}.
>>  *         Invoke {@link java.util.spi.ToolProvider#findFirst ToolProvider.findFirst("jar")}
>>  *         to create an instance of this tool.
>>  * ...
>>  */
>
>> Perhaps like this?
>> 
>> ```java
>> /**
>>  * ...
>>  * @provides java.util.spi.ToolProvider
>>  *         Module {@code jdk.jartool} provides a tool named {@code "jar"}.
>>  *         Invoke {@link java.util.spi.ToolProvider#findFirst ToolProvider.findFirst("jar")}
>>  *         to create an instance of this tool.
>>  * ...
>>  */
>> ```
> 
> What about
> 
> `Module {@code jdk.jartool) provides the equivalent of command-line access to the {@code "jar"} tool`

The focus should be to document the service specified in the `@provides` directive, and how to access to access an instance of the service.

How about:

Use `TP.findFirst("NAME")` to obtain an instance of a `ToolProvider` that provides the equivalent of command-line access to the {@code "NAME"} tool.

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

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

From vromero at openjdk.java.net  Thu Feb 10 17:44:05 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 10 Feb 2022 17:44:05 GMT
Subject: RFR: 8281100: Spurious "variable might not have been initialized"
 with sealed class switch
In-Reply-To: <B1scW4OhFxSp3vumb1WKgR0ZRSEtOFe7MeIvWor1nkA=.8c9d502d-d901-46cc-b247-8ed145deccb2@github.com>
References: <B1scW4OhFxSp3vumb1WKgR0ZRSEtOFe7MeIvWor1nkA=.8c9d502d-d901-46cc-b247-8ed145deccb2@github.com>
Message-ID: <Om4Gjus2P-NTbJrt9-3B9JhS_AkQGYnj0rMwqPOmHIU=.5f6683ca-4910-45cc-b0db-aa4e02d1dc0b@github.com>

On Wed, 9 Feb 2022 09:40:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider:
> 
> interface I permits A, B {}
> 
> String data;
> I i = ...;
> switch (i) {
>     case A a -> data = 0;
>     case B b -> data = 0;
> }
> System.err.println(data); //incorrect error here
> 
> 
> The specification says that `data` is definitely assigned as the `System.err.println`, as the switch covers `I`, but javac will report an error that the variable may not be assigned.
> 
> This patch fixes that - the only tricky part is that if there's an error in the switch (like when the switch is expected to be exhaustive, but is not), the current patch will try to suppress the follow-up "variable may not be assigned" errors. As an example:
> 
> interface I permits A, B {}
> 
> String data;
> I i = ...;
> switch (i) { //error here, not exhaustive
>     case A a -> data = 0;
> }
> System.err.println(data); //no error here, due to the preceding exhaustiveness error

Marked as reviewed by vromero (Reviewer).

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

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

From shade at openjdk.java.net  Fri Feb 11 06:54:09 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 11 Feb 2022 06:54:09 GMT
Subject: RFR: 8281507: Two javac tests have bad jtreg `@clean` tags [v2]
In-Reply-To: <xCFL625ndkyZEpK8TCo5S9r3SjC2bNN9CAeKGlXQXQU=.44fd56ef-4ff5-4ece-bd6f-fdf966e69ecd@github.com>
References: <BP2PZ4WTeQnNFmOKcRcdjWKZvv11DZr4sz1pScJYGl4=.630c487a-a7f1-485c-bdf7-95c1b80aab15@github.com>
 <xCFL625ndkyZEpK8TCo5S9r3SjC2bNN9CAeKGlXQXQU=.44fd56ef-4ff5-4ece-bd6f-fdf966e69ecd@github.com>
Message-ID: <A_Qli-1GGcrLkQWYMgcSmKrcku5AVo610SskPCy_lhU=.abb74627-0743-459b-b5ab-e1f8018af9a7@github.com>

On Wed, 9 Feb 2022 23:16:05 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use clean * instead
>
> Suggest using `@clean *` to remove all previously compiled class files for the test. This seems closest to the original intent.

@jonathan-gibbons, please ack this?

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

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

From jlahoda at openjdk.java.net  Fri Feb 11 12:15:13 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 11 Feb 2022 12:15:13 GMT
Subject: Integrated: 8281100: Spurious
 "variable might not have been initialized" with sealed class switch
In-Reply-To: <B1scW4OhFxSp3vumb1WKgR0ZRSEtOFe7MeIvWor1nkA=.8c9d502d-d901-46cc-b247-8ed145deccb2@github.com>
References: <B1scW4OhFxSp3vumb1WKgR0ZRSEtOFe7MeIvWor1nkA=.8c9d502d-d901-46cc-b247-8ed145deccb2@github.com>
Message-ID: <XJDZbsFX7KM_hd7r7W_YVG_PBBhLbtfxx22jemIm95U=.5eb5e472-cc8f-4e5a-878a-131669aee8d0@github.com>

On Wed, 9 Feb 2022 09:40:21 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider:
> 
> interface I permits A, B {}
> 
> String data;
> I i = ...;
> switch (i) {
>     case A a -> data = 0;
>     case B b -> data = 0;
> }
> System.err.println(data); //incorrect error here
> 
> 
> The specification says that `data` is definitely assigned as the `System.err.println`, as the switch covers `I`, but javac will report an error that the variable may not be assigned.
> 
> This patch fixes that - the only tricky part is that if there's an error in the switch (like when the switch is expected to be exhaustive, but is not), the current patch will try to suppress the follow-up "variable may not be assigned" errors. As an example:
> 
> interface I permits A, B {}
> 
> String data;
> I i = ...;
> switch (i) { //error here, not exhaustive
>     case A a -> data = 0;
> }
> System.err.println(data); //no error here, due to the preceding exhaustiveness error

This pull request has now been integrated.

Changeset: 4ff5824f
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4ff5824f5bc13826d2eae1c83094acfcccdb7b8f
Stats:     107 lines in 4 files changed: 90 ins; 3 del; 14 mod

8281100: Spurious "variable might not have been initialized" with sealed class switch

Reviewed-by: vromero

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

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

From vromero at openjdk.java.net  Fri Feb 11 21:18:10 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 11 Feb 2022 21:18:10 GMT
Subject: RFR: JDK-8281238: TYPE_USE annotations not printed in correct
 position in toString output
In-Reply-To: <8ou4K82I4h1Y6lWtVPdCfwWNTG9YPxm-rQBxN7ZHSCc=.cab9dde1-4745-4878-b011-12da1b6eaab5@github.com>
References: <8ou4K82I4h1Y6lWtVPdCfwWNTG9YPxm-rQBxN7ZHSCc=.cab9dde1-4745-4878-b011-12da1b6eaab5@github.com>
Message-ID: <YLG7pAb9vy0gAMSNifWN2GBIDpEcWrKZnc1R_iKurJ8=.74510849-b7cf-4ebf-9047-38bc5ed19354@github.com>

On Wed, 9 Feb 2022 21:43:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To use a type annotation on a fully qualified type name, the annotations must appear between the package name and the type:
> 
>     java.lang. @TypeAnnotation String // good
> 
> and *not* before the fully qualified name
> 
>    @TypeAnnotation java.lang.String // bad
> 
> This required ordering is not preserved in the toString output of TypeMirrors in annotation processing. This changeset corrects that and updates a few tests that assume the older formatting.
> 
> (This listed update to the given toString method is necessary; I don't believe any of the other Type toString methods also need to be updated, but some might need updating too.)

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From darcy at openjdk.java.net  Fri Feb 11 21:56:12 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 11 Feb 2022 21:56:12 GMT
Subject: Integrated: JDK-8281238: TYPE_USE annotations not printed in correct
 position in toString output
In-Reply-To: <8ou4K82I4h1Y6lWtVPdCfwWNTG9YPxm-rQBxN7ZHSCc=.cab9dde1-4745-4878-b011-12da1b6eaab5@github.com>
References: <8ou4K82I4h1Y6lWtVPdCfwWNTG9YPxm-rQBxN7ZHSCc=.cab9dde1-4745-4878-b011-12da1b6eaab5@github.com>
Message-ID: <_15tVC2OIJg9PxRNjAyxxmHVXgzOZbHma_Aevb_8Brc=.83821a8f-c35f-451b-a168-937ece182ea3@github.com>

On Wed, 9 Feb 2022 21:43:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To use a type annotation on a fully qualified type name, the annotations must appear between the package name and the type:
> 
>     java.lang. @TypeAnnotation String // good
> 
> and *not* before the fully qualified name
> 
>    @TypeAnnotation java.lang.String // bad
> 
> This required ordering is not preserved in the toString output of TypeMirrors in annotation processing. This changeset corrects that and updates a few tests that assume the older formatting.
> 
> (This listed update to the given toString method is necessary; I don't believe any of the other Type toString methods also need to be updated, but some might need updating too.)

This pull request has now been integrated.

Changeset: 4032fe76
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4032fe76dccb6da85927361aee7ceedcdb758e89
Stats:     19 lines in 4 files changed: 8 ins; 0 del; 11 mod

8281238: TYPE_USE annotations not printed in correct position in toString output

Reviewed-by: vromero

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

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

From darcy at openjdk.java.net  Sat Feb 12 01:30:20 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 12 Feb 2022 01:30:20 GMT
Subject: RFR: JDK-8281674:
 tools/javac/annotations/typeAnnotations/classfile/AnonyousExtendsTest.java
 fails with AssertionError
Message-ID: <jofJT9ZR2ZtNnvXcYvrwCiHymfp4xl_Hpml9inrjKNM=.19626d9a-9edd-46a3-935d-a29b6f23f69e@github.com>

Update javac test for revised runtime toString output.

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

Commit messages:
 - JDK-8281674: tools/javac/annotations/typeAnnotations/classfile/AnonymousExtendsTest.java fails with "AssertionError: Unexpected annotations"

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

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

From vromero at openjdk.java.net  Sat Feb 12 01:34:03 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Sat, 12 Feb 2022 01:34:03 GMT
Subject: RFR: JDK-8281674:
 tools/javac/annotations/typeAnnotations/classfile/AnonymousExtendsTest.java
 fails with AssertionError
In-Reply-To: <jofJT9ZR2ZtNnvXcYvrwCiHymfp4xl_Hpml9inrjKNM=.19626d9a-9edd-46a3-935d-a29b6f23f69e@github.com>
References: <jofJT9ZR2ZtNnvXcYvrwCiHymfp4xl_Hpml9inrjKNM=.19626d9a-9edd-46a3-935d-a29b6f23f69e@github.com>
Message-ID: <L0VMJLzTAywUhf-FGDV_FE81gtKhDeEGj_7FzdHpuuI=.666939ff-164f-4e8a-b112-27a07f33310d@github.com>

On Sat, 12 Feb 2022 01:23:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update javac test for revised runtime toString output.

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From darcy at openjdk.java.net  Sat Feb 12 01:37:06 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 12 Feb 2022 01:37:06 GMT
Subject: Integrated: JDK-8281674:
 tools/javac/annotations/typeAnnotations/classfile/AnonymousExtendsTest.java
 fails with AssertionError
In-Reply-To: <jofJT9ZR2ZtNnvXcYvrwCiHymfp4xl_Hpml9inrjKNM=.19626d9a-9edd-46a3-935d-a29b6f23f69e@github.com>
References: <jofJT9ZR2ZtNnvXcYvrwCiHymfp4xl_Hpml9inrjKNM=.19626d9a-9edd-46a3-935d-a29b6f23f69e@github.com>
Message-ID: <8tJ8LHXfYWEEpAHbVsYkcvuH0wa_myXgy2T182lgNmM=.5fc9ad5f-e2f6-47e9-9835-684263c49b9f@github.com>

On Sat, 12 Feb 2022 01:23:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update javac test for revised runtime toString output.

This pull request has now been integrated.

Changeset: 6fdfe045
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6fdfe0458df989a7946b4f52a3023e8a39fb3bbb
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8281674: tools/javac/annotations/typeAnnotations/classfile/AnonymousExtendsTest.java fails with AssertionError

Reviewed-by: vromero

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

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

From ethan at mccue.dev  Sat Feb 12 03:02:03 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Fri, 11 Feb 2022 22:02:03 -0500
Subject: Why do Single-File Source-Code programs implicitly run the first
 declared class?
Message-ID: <CA+NR86h7FEpgF5VujiC4NopHXh45qQnYi4+1=bTYXoGjCakTrw@mail.gmail.com>

While testing some serialization warnings I stumbled upon this nugget of
behavior on the Single-File Source-Code mode

In source-file mode, the effect is as though the source file is compiled
into memory, and the first class found in the source file is executed. Any
arguments placed after the name of the source file in the original command
line are passed to the compiled class when it is executed.



So if you have a file named Example.java with these contents

class ABC {}


public class Example {

    public static void main(String args[]) {
        System.out.println(new ABC());
    }
}


Then the result of running the file directly and compiling then running the
file will diverge.

$ java Example.java
error: can't find main(String[]) method in class: ABC


$ javac Example.java
$ java Example
ABC at 251a69d7


I don't think this is a bug since it is documented behavior both on the man
page and JEP 330, but does anyone have a record of what the reasoning for
the decision was? (At least as opposed to the "obvious" behavior of
requiring a class the same name as the file)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20220211/bba6f817/attachment.htm>

From jpai at openjdk.java.net  Mon Feb 14 05:34:29 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 14 Feb 2022 05:34:29 GMT
Subject: RFR: 8281634: jdeps: java.lang.InternalError: Missing message:
 err.invalid.filters
Message-ID: <PqO_1jJUnToB2Myzkq5ErmWloGo6Dx-qiNdopNAnIVI=.bbc1d4d3-897d-460e-89e3-7ffcdb1df02c@github.com>

Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8281634?

The commit introduces the missing `err.invalid.filters` key in the jdeps resource bundle. I have run a simple check to make sure this resource bundle doesn't miss any other `err.` keys. From a simple search, following are the  unique `err.` keys used in the code of jdeps (under `src/jdk.jdeps/share/classes/com/sun/tools/jdeps` directory):

err.exception.message
err.invalid.options
err.multirelease.version.associated
err.missing.arg
err.multirelease.jar.malformed
err.option.already.specified
err.missing.dependences
err.module.not.found
err.invalid.path
err.genmoduleinfo.not.jarfile
err.invalid.arg.for.option
err.multirelease.option.notfound
err.filter.not.specified
err.unknown.option
err.command.set
err.invalid.filters
err.genmoduleinfo.unnamed.package
err.option.after.class

Apart from the `err.invalid.filters` key which this PR is fixing, none of the other keys are missing from the resource bundle. I haven't updated the resource bundles for Japanese and Chinese languages because I don't know their equivalent values and looking at the commit history of those files, it appears that those changes are done as separate tasks (should a JBS issue be raised for this?)

The existing `test/langtools/tools/jdeps/Options.java` jtreg test has been updated to reproduce the issue and verify this fix.

An important detail about the update to the test is that while working on the update to this test, I realized that the current implementation in the test isn't fully functional. As a result, this test is currently, incorrectly considered as passing. Specifically, the test was missing a `assertTrue` call against the ouput/error content generated by the run of the `jdeps` tool.  This PR adds that assertion.
Once that assertion is added, it started showing up 3 genuine failures. These failures are within that test code:
- The test uses `-jdkinternal` instead of `-jdkinternals`. This appears to be a typo when this section in the test was added. The commit history of the source of jdeps tool shows that this option was always `-jdkinternals`. This PR fixes that part in the test.
- The test expects an error message "-R cannot be used with --inverse option" when `-R` and `--inverse` are used together. However, at some point the source of jdeps tool was changed (as part of https://bugs.openjdk.java.net/browse/JDK-8213909) to return a different error message. That changes appears to have missed changing this test case error message and since this test has been falsely passing, it never got caught. This PR now fixes that issue by expecting the correct error message.
- The test was expecting an error message "--list-deps and --list-reduced-deps options are specified" when "--list-deps" was used along with "--summary". This appears to be a copy/paste error in the test case and wasn't caught because the test was falsely passing. This too has been fixed in this PR.

With the fixes in this test, the test now reproduces the original issue and verifies the fix. I realize that this PR has changes in the test that aren't directly related to the issue raised in https://bugs.openjdk.java.net/browse/JDK-8281634, but those changes are necessary to get the test functional. However if a separate JBS issue needs to be opened to track those changes, please do let me know and I'll address these test changes in a separate PR.

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

Commit messages:
 - 8281634: jdeps: java.lang.InternalError: Missing message: err.invalid.filters

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

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

From jpai at openjdk.java.net  Mon Feb 14 06:44:32 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 14 Feb 2022 06:44:32 GMT
Subject: RFR: 8281705: SourceLauncherTest.testSystemProperty isn't being run
Message-ID: <UkGIFcUqulzfEhXyDu9HHaR6Owf0F5RrlWR3wxO1Zng=.59c4cf1a-ab41-4ca4-bbd2-a43653ac374a@github.com>

Can I please get a review of this test-only change which fixes the issue noted in https://bugs.openjdk.java.net/browse/JDK-8281705? 

The change in this commit adds the `@Test` annotation on the test method to make sure it gets run. Before this change, the test run logs showed that `28 tests` were being run and now after this change, the logs report `29 tests` and I can see `testSystemProperty` in the test run logs.

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

Commit messages:
 - 8281705: SourceLauncherTest.testSystemProperty isn't being run

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

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

From dfuchs at openjdk.java.net  Mon Feb 14 10:23:10 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 14 Feb 2022 10:23:10 GMT
Subject: RFR: 8281634: jdeps: java.lang.InternalError: Missing message:
 err.invalid.filters
In-Reply-To: <PqO_1jJUnToB2Myzkq5ErmWloGo6Dx-qiNdopNAnIVI=.bbc1d4d3-897d-460e-89e3-7ffcdb1df02c@github.com>
References: <PqO_1jJUnToB2Myzkq5ErmWloGo6Dx-qiNdopNAnIVI=.bbc1d4d3-897d-460e-89e3-7ffcdb1df02c@github.com>
Message-ID: <EFDUA-OWfYPsHq3EfflTIlBwNSrqWfq_GHo131wv4QM=.b0e0571f-ad75-4f1b-957e-d136c1861dfc@github.com>

On Mon, 14 Feb 2022 05:27:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8281634?
> 
> The commit introduces the missing `err.invalid.filters` key in the jdeps resource bundle. I have run a simple check to make sure this resource bundle doesn't miss any other `err.` keys. From a simple search, following are the  unique `err.` keys used in the code of jdeps (under `src/jdk.jdeps/share/classes/com/sun/tools/jdeps` directory):
> 
> err.exception.message
> err.invalid.options
> err.multirelease.version.associated
> err.missing.arg
> err.multirelease.jar.malformed
> err.option.already.specified
> err.missing.dependences
> err.module.not.found
> err.invalid.path
> err.genmoduleinfo.not.jarfile
> err.invalid.arg.for.option
> err.multirelease.option.notfound
> err.filter.not.specified
> err.unknown.option
> err.command.set
> err.invalid.filters
> err.genmoduleinfo.unnamed.package
> err.option.after.class
> 
> Apart from the `err.invalid.filters` key which this PR is fixing, none of the other keys are missing from the resource bundle. I haven't updated the resource bundles for Japanese and Chinese languages because I don't know their equivalent values and looking at the commit history of those files, it appears that those changes are done as separate tasks (should a JBS issue be raised for this?)
> 
> The existing `test/langtools/tools/jdeps/Options.java` jtreg test has been updated to reproduce the issue and verify this fix.
> 
> An important detail about the update to the test is that while working on the update to this test, I realized that the current implementation in the test isn't fully functional. As a result, this test is currently, incorrectly considered as passing. Specifically, the test was missing a `assertTrue` call against the ouput/error content generated by the run of the `jdeps` tool.  This PR adds that assertion.
> Once that assertion is added, it started showing up 3 genuine failures. These failures are within that test code:
> - The test uses `-jdkinternal` instead of `-jdkinternals`. This appears to be a typo when this section in the test was added. The commit history of the source of jdeps tool shows that this option was always `-jdkinternals`. This PR fixes that part in the test.
> - The test expects an error message "-R cannot be used with --inverse option" when `-R` and `--inverse` are used together. However, at some point the source of jdeps tool was changed (as part of https://bugs.openjdk.java.net/browse/JDK-8213909) to return a different error message. That changes appears to have missed changing this test case error message and since this test has been falsely passing, it never got caught. This PR now fixes that issue by expecting the correct error message.
> - The test was expecting an error message "--list-deps and --list-reduced-deps options are specified" when "--list-deps" was used along with "--summary". This appears to be a copy/paste error in the test case and wasn't caught because the test was falsely passing. This too has been fixed in this PR.
> 
> With the fixes in this test, the test now reproduces the original issue and verifies the fix. I realize that this PR has changes in the test that aren't directly related to the issue raised in https://bugs.openjdk.java.net/browse/JDK-8281634, but those changes are necessary to get the test functional. However if a separate JBS issue needs to be opened to track those changes, please do let me know and I'll address these test changes in a separate PR.

The changes look reasonable. Thanks for taking that on Jaikiran!
Maybe wait one day or two before integrating to give Mandy a chance to chime in.

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

Marked as reviewed by dfuchs (Reviewer).

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

From jpai at openjdk.java.net  Mon Feb 14 11:42:14 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 14 Feb 2022 11:42:14 GMT
Subject: RFR: 8281634: jdeps: java.lang.InternalError: Missing message:
 err.invalid.filters
In-Reply-To: <PqO_1jJUnToB2Myzkq5ErmWloGo6Dx-qiNdopNAnIVI=.bbc1d4d3-897d-460e-89e3-7ffcdb1df02c@github.com>
References: <PqO_1jJUnToB2Myzkq5ErmWloGo6Dx-qiNdopNAnIVI=.bbc1d4d3-897d-460e-89e3-7ffcdb1df02c@github.com>
Message-ID: <YzppbszCm8xuU8tTkYFxRjUTgH_NHJ0HjugFI7MR5xs=.de530336-0421-40b8-b996-4fbdff827e31@github.com>

On Mon, 14 Feb 2022 05:27:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8281634?
> 
> The commit introduces the missing `err.invalid.filters` key in the jdeps resource bundle. I have run a simple check to make sure this resource bundle doesn't miss any other `err.` keys. From a simple search, following are the  unique `err.` keys used in the code of jdeps (under `src/jdk.jdeps/share/classes/com/sun/tools/jdeps` directory):
> 
> err.exception.message
> err.invalid.options
> err.multirelease.version.associated
> err.missing.arg
> err.multirelease.jar.malformed
> err.option.already.specified
> err.missing.dependences
> err.module.not.found
> err.invalid.path
> err.genmoduleinfo.not.jarfile
> err.invalid.arg.for.option
> err.multirelease.option.notfound
> err.filter.not.specified
> err.unknown.option
> err.command.set
> err.invalid.filters
> err.genmoduleinfo.unnamed.package
> err.option.after.class
> 
> Apart from the `err.invalid.filters` key which this PR is fixing, none of the other keys are missing from the resource bundle. I haven't updated the resource bundles for Japanese and Chinese languages because I don't know their equivalent values and looking at the commit history of those files, it appears that those changes are done as separate tasks (should a JBS issue be raised for this?)
> 
> The existing `test/langtools/tools/jdeps/Options.java` jtreg test has been updated to reproduce the issue and verify this fix.
> 
> An important detail about the update to the test is that while working on the update to this test, I realized that the current implementation in the test isn't fully functional. As a result, this test is currently, incorrectly considered as passing. Specifically, the test was missing a `assertTrue` call against the ouput/error content generated by the run of the `jdeps` tool.  This PR adds that assertion.
> Once that assertion is added, it started showing up 3 genuine failures. These failures are within that test code:
> - The test uses `-jdkinternal` instead of `-jdkinternals`. This appears to be a typo when this section in the test was added. The commit history of the source of jdeps tool shows that this option was always `-jdkinternals`. This PR fixes that part in the test.
> - The test expects an error message "-R cannot be used with --inverse option" when `-R` and `--inverse` are used together. However, at some point the source of jdeps tool was changed (as part of https://bugs.openjdk.java.net/browse/JDK-8213909) to return a different error message. That changes appears to have missed changing this test case error message and since this test has been falsely passing, it never got caught. This PR now fixes that issue by expecting the correct error message.
> - The test was expecting an error message "--list-deps and --list-reduced-deps options are specified" when "--list-deps" was used along with "--summary". This appears to be a copy/paste error in the test case and wasn't caught because the test was falsely passing. This too has been fixed in this PR.
> 
> With the fixes in this test, the test now reproduces the original issue and verifies the fix. I realize that this PR has changes in the test that aren't directly related to the issue raised in https://bugs.openjdk.java.net/browse/JDK-8281634, but those changes are necessary to get the test functional. However if a separate JBS issue needs to be opened to track those changes, please do let me know and I'll address these test changes in a separate PR.

Thank you for your review, Daniel.

>  Maybe wait one day or two before integrating to give Mandy a chance to chime in.

Certainly.

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

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

From naoto at openjdk.java.net  Mon Feb 14 17:46:10 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 14 Feb 2022 17:46:10 GMT
Subject: RFR: 8281634: jdeps: java.lang.InternalError: Missing message:
 err.invalid.filters
In-Reply-To: <PqO_1jJUnToB2Myzkq5ErmWloGo6Dx-qiNdopNAnIVI=.bbc1d4d3-897d-460e-89e3-7ffcdb1df02c@github.com>
References: <PqO_1jJUnToB2Myzkq5ErmWloGo6Dx-qiNdopNAnIVI=.bbc1d4d3-897d-460e-89e3-7ffcdb1df02c@github.com>
Message-ID: <b4mRM0aFUZQsQRi9tdYorl6ab4huD_al70xQDSEUIyU=.367ac6c5-885d-4a50-b685-9a1f12a3aee5@github.com>

On Mon, 14 Feb 2022 05:27:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8281634?
> 
> The commit introduces the missing `err.invalid.filters` key in the jdeps resource bundle. I have run a simple check to make sure this resource bundle doesn't miss any other `err.` keys. From a simple search, following are the  unique `err.` keys used in the code of jdeps (under `src/jdk.jdeps/share/classes/com/sun/tools/jdeps` directory):
> 
> err.exception.message
> err.invalid.options
> err.multirelease.version.associated
> err.missing.arg
> err.multirelease.jar.malformed
> err.option.already.specified
> err.missing.dependences
> err.module.not.found
> err.invalid.path
> err.genmoduleinfo.not.jarfile
> err.invalid.arg.for.option
> err.multirelease.option.notfound
> err.filter.not.specified
> err.unknown.option
> err.command.set
> err.invalid.filters
> err.genmoduleinfo.unnamed.package
> err.option.after.class
> 
> Apart from the `err.invalid.filters` key which this PR is fixing, none of the other keys are missing from the resource bundle. I haven't updated the resource bundles for Japanese and Chinese languages because I don't know their equivalent values and looking at the commit history of those files, it appears that those changes are done as separate tasks (should a JBS issue be raised for this?)
> 
> The existing `test/langtools/tools/jdeps/Options.java` jtreg test has been updated to reproduce the issue and verify this fix.
> 
> An important detail about the update to the test is that while working on the update to this test, I realized that the current implementation in the test isn't fully functional. As a result, this test is currently, incorrectly considered as passing. Specifically, the test was missing a `assertTrue` call against the ouput/error content generated by the run of the `jdeps` tool.  This PR adds that assertion.
> Once that assertion is added, it started showing up 3 genuine failures. These failures are within that test code:
> - The test uses `-jdkinternal` instead of `-jdkinternals`. This appears to be a typo when this section in the test was added. The commit history of the source of jdeps tool shows that this option was always `-jdkinternals`. This PR fixes that part in the test.
> - The test expects an error message "-R cannot be used with --inverse option" when `-R` and `--inverse` are used together. However, at some point the source of jdeps tool was changed (as part of https://bugs.openjdk.java.net/browse/JDK-8213909) to return a different error message. That changes appears to have missed changing this test case error message and since this test has been falsely passing, it never got caught. This PR now fixes that issue by expecting the correct error message.
> - The test was expecting an error message "--list-deps and --list-reduced-deps options are specified" when "--list-deps" was used along with "--summary". This appears to be a copy/paste error in the test case and wasn't caught because the test was falsely passing. This too has been fixed in this PR.
> 
> With the fixes in this test, the test now reproduces the original issue and verifies the fix. I realize that this PR has changes in the test that aren't directly related to the issue raised in https://bugs.openjdk.java.net/browse/JDK-8281634, but those changes are necessary to get the test functional. However if a separate JBS issue needs to be opened to track those changes, please do let me know and I'll address these test changes in a separate PR.

Looks good. As to the l10n of those English resources should be handled with https://bugs.openjdk.java.net/browse/JDK-8280400

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

Marked as reviewed by naoto (Reviewer).

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

From mchung at openjdk.java.net  Mon Feb 14 17:52:08 2022
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 14 Feb 2022 17:52:08 GMT
Subject: RFR: 8281634: jdeps: java.lang.InternalError: Missing message:
 err.invalid.filters
In-Reply-To: <PqO_1jJUnToB2Myzkq5ErmWloGo6Dx-qiNdopNAnIVI=.bbc1d4d3-897d-460e-89e3-7ffcdb1df02c@github.com>
References: <PqO_1jJUnToB2Myzkq5ErmWloGo6Dx-qiNdopNAnIVI=.bbc1d4d3-897d-460e-89e3-7ffcdb1df02c@github.com>
Message-ID: <Z0nnumXS3iGmxcXqCPckD31MbLoMyOMLZyMWPWbrlqc=.6dda3d7e-087f-43b0-88da-a116b018c79e@github.com>

On Mon, 14 Feb 2022 05:27:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8281634?
> 
> The commit introduces the missing `err.invalid.filters` key in the jdeps resource bundle. I have run a simple check to make sure this resource bundle doesn't miss any other `err.` keys. From a simple search, following are the  unique `err.` keys used in the code of jdeps (under `src/jdk.jdeps/share/classes/com/sun/tools/jdeps` directory):
> 
> err.exception.message
> err.invalid.options
> err.multirelease.version.associated
> err.missing.arg
> err.multirelease.jar.malformed
> err.option.already.specified
> err.missing.dependences
> err.module.not.found
> err.invalid.path
> err.genmoduleinfo.not.jarfile
> err.invalid.arg.for.option
> err.multirelease.option.notfound
> err.filter.not.specified
> err.unknown.option
> err.command.set
> err.invalid.filters
> err.genmoduleinfo.unnamed.package
> err.option.after.class
> 
> Apart from the `err.invalid.filters` key which this PR is fixing, none of the other keys are missing from the resource bundle. I haven't updated the resource bundles for Japanese and Chinese languages because I don't know their equivalent values and looking at the commit history of those files, it appears that those changes are done as separate tasks (should a JBS issue be raised for this?)
> 
> The existing `test/langtools/tools/jdeps/Options.java` jtreg test has been updated to reproduce the issue and verify this fix.
> 
> An important detail about the update to the test is that while working on the update to this test, I realized that the current implementation in the test isn't fully functional. As a result, this test is currently, incorrectly considered as passing. Specifically, the test was missing a `assertTrue` call against the ouput/error content generated by the run of the `jdeps` tool.  This PR adds that assertion.
> Once that assertion is added, it started showing up 3 genuine failures. These failures are within that test code:
> - The test uses `-jdkinternal` instead of `-jdkinternals`. This appears to be a typo when this section in the test was added. The commit history of the source of jdeps tool shows that this option was always `-jdkinternals`. This PR fixes that part in the test.
> - The test expects an error message "-R cannot be used with --inverse option" when `-R` and `--inverse` are used together. However, at some point the source of jdeps tool was changed (as part of https://bugs.openjdk.java.net/browse/JDK-8213909) to return a different error message. That changes appears to have missed changing this test case error message and since this test has been falsely passing, it never got caught. This PR now fixes that issue by expecting the correct error message.
> - The test was expecting an error message "--list-deps and --list-reduced-deps options are specified" when "--list-deps" was used along with "--summary". This appears to be a copy/paste error in the test case and wasn't caught because the test was falsely passing. This too has been fixed in this PR.
> 
> With the fixes in this test, the test now reproduces the original issue and verifies the fix. I realize that this PR has changes in the test that aren't directly related to the issue raised in https://bugs.openjdk.java.net/browse/JDK-8281634, but those changes are necessary to get the test functional. However if a separate JBS issue needs to be opened to track those changes, please do let me know and I'll address these test changes in a separate PR.

Thanks for fixing this.   This looks good.  Fixing the test together is fine.

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

Marked as reviewed by mchung (Reviewer).

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

From cstein at openjdk.java.net  Mon Feb 14 18:23:11 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Mon, 14 Feb 2022 18:23:11 GMT
Subject: RFR: 8280825: Modules that "provide" ToolProvider should document
 the name that can be used
In-Reply-To: <6DQ5_BAMP-bV8XkY9txYZBRnXzc3ypCXV9b0YdgvAkk=.7bc88afb-4f9d-4659-9b33-153977afbb34@github.com>
References: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
 <JIlx1vMqpD30pENymOcPwy9gHHBQSNzyxEUpG2ONbIo=.c325659e-74f2-4e3a-aa9f-582cec32f18c@github.com>
 <afDRKISO8d6usemIy1Cc8XwiOh4iZkLGWKAxo-bXuqw=.61eae219-e2cb-4a29-a124-b3c1665226fd@github.com>
 <yyYtSRF_BtpmIj_jI23kzF3ILKJT5TDWTR7vP4bseOk=.62a36950-ab54-4a9f-b666-62fadc5e256e@github.com>
 <6PtiwnwsLiCIUh7p_ZuVg_ezthZLldYBugkMIfBnNTA=.2e8e10cb-09b0-4c53-940a-b2093c48d391@github.com>
 <6DQ5_BAMP-bV8XkY9txYZBRnXzc3ypCXV9b0YdgvAkk=.7bc88afb-4f9d-4659-9b33-153977afbb34@github.com>
Message-ID: <Jiu8_ptDNOIXtgsSft1y0_N-WGIw35FgbSedjIHxQrA=.bede5a12-ca79-49d4-a0a4-2b66c49f62fd@github.com>

On Thu, 10 Feb 2022 17:24:17 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>>> Perhaps like this?
>>> 
>>> ```java
>>> /**
>>>  * ...
>>>  * @provides java.util.spi.ToolProvider
>>>  *         Module {@code jdk.jartool} provides a tool named {@code "jar"}.
>>>  *         Invoke {@link java.util.spi.ToolProvider#findFirst ToolProvider.findFirst("jar")}
>>>  *         to create an instance of this tool.
>>>  * ...
>>>  */
>>> ```
>> 
>> What about
>> 
>> `Module {@code jdk.jartool) provides the equivalent of command-line access to the {@code "jar"} tool`
>
> The focus should be to document the service specified in the `@provides` directive, and how to access to access an instance of the service.
> 
> How about:
> 
> Use `TP.findFirst("NAME")` to obtain an instance of a `ToolProvider` that provides the equivalent of command-line access to the {@code "NAME"} tool.

I think Jon's latest proposal combines all requirements with using better wording than my initial text.

Do you agree, @AlanBateman and @LanceAndersen?

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

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

From lancea at openjdk.java.net  Mon Feb 14 19:12:07 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 14 Feb 2022 19:12:07 GMT
Subject: RFR: 8280825: Modules that "provide" ToolProvider should document
 the name that can be used
In-Reply-To: <Jiu8_ptDNOIXtgsSft1y0_N-WGIw35FgbSedjIHxQrA=.bede5a12-ca79-49d4-a0a4-2b66c49f62fd@github.com>
References: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
 <JIlx1vMqpD30pENymOcPwy9gHHBQSNzyxEUpG2ONbIo=.c325659e-74f2-4e3a-aa9f-582cec32f18c@github.com>
 <afDRKISO8d6usemIy1Cc8XwiOh4iZkLGWKAxo-bXuqw=.61eae219-e2cb-4a29-a124-b3c1665226fd@github.com>
 <yyYtSRF_BtpmIj_jI23kzF3ILKJT5TDWTR7vP4bseOk=.62a36950-ab54-4a9f-b666-62fadc5e256e@github.com>
 <6PtiwnwsLiCIUh7p_ZuVg_ezthZLldYBugkMIfBnNTA=.2e8e10cb-09b0-4c53-940a-b2093c48d391@github.com>
 <6DQ5_BAMP-bV8XkY9txYZBRnXzc3ypCXV9b0YdgvAkk=.7bc88afb-4f9d-4659-9b33-153977afbb34@github.com>
 <Jiu8_ptDNOIXtgsSft1y0_N-WGIw35FgbSedjIHxQrA=.bede5a12-ca79-49d4-a0a4-2b66c49f62fd@github.com>
Message-ID: <BXDfm7wY7t5s0_-GHMf8CjxdnN_VgQHn0PX2nqQZB9A=.6366ce73-ef7e-4a1a-8865-d620b46b6897@github.com>

On Mon, 14 Feb 2022 18:20:19 GMT, Christian Stein <cstein at openjdk.org> wrote:

> I think Jon's latest proposal combines all requirements with using better wording than my initial text.
> 
> Do you agree, @AlanBateman and @LanceAndersen?

Yes, I think that sounds good

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

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

From jpai at openjdk.java.net  Tue Feb 15 03:58:18 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 15 Feb 2022 03:58:18 GMT
Subject: RFR: 8281634: jdeps: java.lang.InternalError: Missing message:
 err.invalid.filters
In-Reply-To: <PqO_1jJUnToB2Myzkq5ErmWloGo6Dx-qiNdopNAnIVI=.bbc1d4d3-897d-460e-89e3-7ffcdb1df02c@github.com>
References: <PqO_1jJUnToB2Myzkq5ErmWloGo6Dx-qiNdopNAnIVI=.bbc1d4d3-897d-460e-89e3-7ffcdb1df02c@github.com>
Message-ID: <M3pBgWLgZA_5WB3MwIhx3YeN7oyBZcfOePJLEQ9hRDA=.8de400ef-ef8c-43bd-8df1-9303a07d48ba@github.com>

On Mon, 14 Feb 2022 05:27:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8281634?
> 
> The commit introduces the missing `err.invalid.filters` key in the jdeps resource bundle. I have run a simple check to make sure this resource bundle doesn't miss any other `err.` keys. From a simple search, following are the  unique `err.` keys used in the code of jdeps (under `src/jdk.jdeps/share/classes/com/sun/tools/jdeps` directory):
> 
> err.exception.message
> err.invalid.options
> err.multirelease.version.associated
> err.missing.arg
> err.multirelease.jar.malformed
> err.option.already.specified
> err.missing.dependences
> err.module.not.found
> err.invalid.path
> err.genmoduleinfo.not.jarfile
> err.invalid.arg.for.option
> err.multirelease.option.notfound
> err.filter.not.specified
> err.unknown.option
> err.command.set
> err.invalid.filters
> err.genmoduleinfo.unnamed.package
> err.option.after.class
> 
> Apart from the `err.invalid.filters` key which this PR is fixing, none of the other keys are missing from the resource bundle. I haven't updated the resource bundles for Japanese and Chinese languages because I don't know their equivalent values and looking at the commit history of those files, it appears that those changes are done as separate tasks (should a JBS issue be raised for this?)
> 
> The existing `test/langtools/tools/jdeps/Options.java` jtreg test has been updated to reproduce the issue and verify this fix.
> 
> An important detail about the update to the test is that while working on the update to this test, I realized that the current implementation in the test isn't fully functional. As a result, this test is currently, incorrectly considered as passing. Specifically, the test was missing a `assertTrue` call against the ouput/error content generated by the run of the `jdeps` tool.  This PR adds that assertion.
> Once that assertion is added, it started showing up 3 genuine failures. These failures are within that test code:
> - The test uses `-jdkinternal` instead of `-jdkinternals`. This appears to be a typo when this section in the test was added. The commit history of the source of jdeps tool shows that this option was always `-jdkinternals`. This PR fixes that part in the test.
> - The test expects an error message "-R cannot be used with --inverse option" when `-R` and `--inverse` are used together. However, at some point the source of jdeps tool was changed (as part of https://bugs.openjdk.java.net/browse/JDK-8213909) to return a different error message. That changes appears to have missed changing this test case error message and since this test has been falsely passing, it never got caught. This PR now fixes that issue by expecting the correct error message.
> - The test was expecting an error message "--list-deps and --list-reduced-deps options are specified" when "--list-deps" was used along with "--summary". This appears to be a copy/paste error in the test case and wasn't caught because the test was falsely passing. This too has been fixed in this PR.
> 
> With the fixes in this test, the test now reproduces the original issue and verifies the fix. I realize that this PR has changes in the test that aren't directly related to the issue raised in https://bugs.openjdk.java.net/browse/JDK-8281634, but those changes are necessary to get the test functional. However if a separate JBS issue needs to be opened to track those changes, please do let me know and I'll address these test changes in a separate PR.

Thank you for the reviews, Mandy and Naoto.

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

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

From jpai at openjdk.java.net  Tue Feb 15 03:58:18 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 15 Feb 2022 03:58:18 GMT
Subject: Integrated: 8281634: jdeps: java.lang.InternalError: Missing message:
 err.invalid.filters
In-Reply-To: <PqO_1jJUnToB2Myzkq5ErmWloGo6Dx-qiNdopNAnIVI=.bbc1d4d3-897d-460e-89e3-7ffcdb1df02c@github.com>
References: <PqO_1jJUnToB2Myzkq5ErmWloGo6Dx-qiNdopNAnIVI=.bbc1d4d3-897d-460e-89e3-7ffcdb1df02c@github.com>
Message-ID: <usKXaACPJ5hI7DH1HJaIQM3IASV7Xcq4jstJm0Dblgw=.81fefeaa-846a-4017-b91a-d761c76882fb@github.com>

On Mon, 14 Feb 2022 05:27:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which proposes to fix the issue noted in https://bugs.openjdk.java.net/browse/JDK-8281634?
> 
> The commit introduces the missing `err.invalid.filters` key in the jdeps resource bundle. I have run a simple check to make sure this resource bundle doesn't miss any other `err.` keys. From a simple search, following are the  unique `err.` keys used in the code of jdeps (under `src/jdk.jdeps/share/classes/com/sun/tools/jdeps` directory):
> 
> err.exception.message
> err.invalid.options
> err.multirelease.version.associated
> err.missing.arg
> err.multirelease.jar.malformed
> err.option.already.specified
> err.missing.dependences
> err.module.not.found
> err.invalid.path
> err.genmoduleinfo.not.jarfile
> err.invalid.arg.for.option
> err.multirelease.option.notfound
> err.filter.not.specified
> err.unknown.option
> err.command.set
> err.invalid.filters
> err.genmoduleinfo.unnamed.package
> err.option.after.class
> 
> Apart from the `err.invalid.filters` key which this PR is fixing, none of the other keys are missing from the resource bundle. I haven't updated the resource bundles for Japanese and Chinese languages because I don't know their equivalent values and looking at the commit history of those files, it appears that those changes are done as separate tasks (should a JBS issue be raised for this?)
> 
> The existing `test/langtools/tools/jdeps/Options.java` jtreg test has been updated to reproduce the issue and verify this fix.
> 
> An important detail about the update to the test is that while working on the update to this test, I realized that the current implementation in the test isn't fully functional. As a result, this test is currently, incorrectly considered as passing. Specifically, the test was missing a `assertTrue` call against the ouput/error content generated by the run of the `jdeps` tool.  This PR adds that assertion.
> Once that assertion is added, it started showing up 3 genuine failures. These failures are within that test code:
> - The test uses `-jdkinternal` instead of `-jdkinternals`. This appears to be a typo when this section in the test was added. The commit history of the source of jdeps tool shows that this option was always `-jdkinternals`. This PR fixes that part in the test.
> - The test expects an error message "-R cannot be used with --inverse option" when `-R` and `--inverse` are used together. However, at some point the source of jdeps tool was changed (as part of https://bugs.openjdk.java.net/browse/JDK-8213909) to return a different error message. That changes appears to have missed changing this test case error message and since this test has been falsely passing, it never got caught. This PR now fixes that issue by expecting the correct error message.
> - The test was expecting an error message "--list-deps and --list-reduced-deps options are specified" when "--list-deps" was used along with "--summary". This appears to be a copy/paste error in the test case and wasn't caught because the test was falsely passing. This too has been fixed in this PR.
> 
> With the fixes in this test, the test now reproduces the original issue and verifies the fix. I realize that this PR has changes in the test that aren't directly related to the issue raised in https://bugs.openjdk.java.net/browse/JDK-8281634, but those changes are necessary to get the test functional. However if a separate JBS issue needs to be opened to track those changes, please do let me know and I'll address these test changes in a separate PR.

This pull request has now been integrated.

Changeset: d4cd8dfe
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d4cd8dfedbe220fb3b9a68650aba90536e9b12ee
Stats:     14 lines in 2 files changed: 5 ins; 0 del; 9 mod

8281634: jdeps: java.lang.InternalError: Missing message: err.invalid.filters

Reviewed-by: dfuchs, naoto, mchung

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

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

From cstein at openjdk.java.net  Tue Feb 15 04:45:50 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Tue, 15 Feb 2022 04:45:50 GMT
Subject: RFR: 8280825: Modules that "provide" ToolProvider should document
 the name that can be used [v2]
In-Reply-To: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
References: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
Message-ID: <dN8VCmHiFOPIEMv-ktIKXKjipH7we9pwJl1z9MVHcTM=.8ad4b4fd-07df-41ee-ae17-8782736208e0@github.com>

> A number of modules declare that the "provide" ToolProvider.
> 
> These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Update wording

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7406/files
  - new: https://git.openjdk.java.net/jdk/pull/7406/files/56e0c249..eaa9a322

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

  Stats: 19 lines in 6 files changed: 1 ins; 0 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7406.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7406/head:pull/7406

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

From cstein at openjdk.java.net  Tue Feb 15 06:40:57 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Tue, 15 Feb 2022 06:40:57 GMT
Subject: RFR: 8280825: Modules that "provide" ToolProvider should document
 the name that can be used [v3]
In-Reply-To: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
References: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
Message-ID: <arTU-j_MFS5dY_OpYnnZYZIfzIRAYmPdLtyomC9wFSY=.5122beb9-90cc-4da3-a128-c3813a2b1ccb@github.com>

> A number of modules declare that the "provide" ToolProvider.
> 
> These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag.

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo
  
  [skip actions]

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7406/files
  - new: https://git.openjdk.java.net/jdk/pull/7406/files/eaa9a322..ca92a6cc

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

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

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

From lancea at openjdk.java.net  Tue Feb 15 11:23:09 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 15 Feb 2022 11:23:09 GMT
Subject: RFR: 8280825: Modules that "provide" ToolProvider should document
 the name that can be used [v3]
In-Reply-To: <arTU-j_MFS5dY_OpYnnZYZIfzIRAYmPdLtyomC9wFSY=.5122beb9-90cc-4da3-a128-c3813a2b1ccb@github.com>
References: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
 <arTU-j_MFS5dY_OpYnnZYZIfzIRAYmPdLtyomC9wFSY=.5122beb9-90cc-4da3-a128-c3813a2b1ccb@github.com>
Message-ID: <qPSQvlPgnNreJ1atP3fzhLE6HpyBPFHPg3fHKJhpd5E=.9e567ec9-1e3a-434e-8b4f-ffbc9087e67d@github.com>

On Tue, 15 Feb 2022 06:40:57 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> A number of modules declare that the "provide" ToolProvider.
>> 
>> These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo
>   
>   [skip actions]

I think we are looking good.  Thank you for your persistence on the wordsmithing

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

Marked as reviewed by lancea (Reviewer).

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

From alanb at openjdk.java.net  Tue Feb 15 14:40:16 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 15 Feb 2022 14:40:16 GMT
Subject: RFR: 8280825: Modules that "provide" ToolProvider should document
 the name that can be used [v3]
In-Reply-To: <arTU-j_MFS5dY_OpYnnZYZIfzIRAYmPdLtyomC9wFSY=.5122beb9-90cc-4da3-a128-c3813a2b1ccb@github.com>
References: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
 <arTU-j_MFS5dY_OpYnnZYZIfzIRAYmPdLtyomC9wFSY=.5122beb9-90cc-4da3-a128-c3813a2b1ccb@github.com>
Message-ID: <_Ua0IDQTMbEnwATcYEu33eJBDjh3R8TINQ_OeIKgoUY=.71140c81-5672-47e3-9615-564a2428210f@github.com>

On Tue, 15 Feb 2022 06:40:57 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> A number of modules declare that the "provide" ToolProvider.
>> 
>> These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo
>   
>   [skip actions]

Marked as reviewed by alanb (Reviewer).

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

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

From shade at openjdk.java.net  Tue Feb 15 16:45:06 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 15 Feb 2022 16:45:06 GMT
Subject: RFR: 8281507: Two javac tests have bad jtreg `@clean` tags [v2]
In-Reply-To: <xCFL625ndkyZEpK8TCo5S9r3SjC2bNN9CAeKGlXQXQU=.44fd56ef-4ff5-4ece-bd6f-fdf966e69ecd@github.com>
References: <BP2PZ4WTeQnNFmOKcRcdjWKZvv11DZr4sz1pScJYGl4=.630c487a-a7f1-485c-bdf7-95c1b80aab15@github.com>
 <xCFL625ndkyZEpK8TCo5S9r3SjC2bNN9CAeKGlXQXQU=.44fd56ef-4ff5-4ece-bd6f-fdf966e69ecd@github.com>
Message-ID: <-7c9BtxMALDAI7mGbgVTa80pmkmKvlME5aFH3lpmmZk=.a9fc5845-a3ed-4f59-bff3-c26af951cb85@github.com>

On Wed, 9 Feb 2022 23:16:05 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use clean * instead
>
> Suggest using `@clean *` to remove all previously compiled class files for the test. This seems closest to the original intent.

Paging @jonathan-gibbons or anybody else :)

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

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

From cstein at openjdk.java.net  Tue Feb 15 17:59:09 2022
From: cstein at openjdk.java.net (Christian Stein)
Date: Tue, 15 Feb 2022 17:59:09 GMT
Subject: Integrated: 8280825: Modules that "provide" ToolProvider should
 document the name that can be used
In-Reply-To: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
References: <gzURKmzi3lFRXdmuOLi8pmsMzAHxCJz6er7kYscDUQo=.72db9c5e-ec3a-4647-a071-59d245e19924@github.com>
Message-ID: <8zb_ci6u-SZ3pwg_J4JQbsGaB1GecpIJPrEP1j1BgVs=.4ac2ef58-66c6-4bd6-bfff-2f856ac89041@github.com>

On Wed, 9 Feb 2022 16:37:00 GMT, Christian Stein <cstein at openjdk.org> wrote:

> A number of modules declare that the "provide" ToolProvider.
> 
> These modules now specify the "name" of the argument used by `ToolProvider.findFirst` to access an instance of the tool provider within the description part of a `@provides` API tag.

This pull request has now been integrated.

Changeset: 394ce5f9
Author:    Christian Stein <cstein at openjdk.org>
Committer: Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/394ce5f948c21b3861d76dd8db57957efa1df979
Stats:     27 lines in 6 files changed: 22 ins; 0 del; 5 mod

8280825: Modules that "provide" ToolProvider should document the name that can be used

Reviewed-by: jjg, lancea, alanb

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

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

From duke at openjdk.java.net  Wed Feb 16 10:47:10 2022
From: duke at openjdk.java.net (duke)
Date: Wed, 16 Feb 2022 10:47:10 GMT
Subject: Withdrawn: 8274617: constructor and parameter annotations are not
 copied to the anonymous class constructor
In-Reply-To: <CqHLqLwPqP7FNqq1_-y0qLEXEm5y0CBmNZMXUxyUdl0=.2b9cfb9c-9aea-4947-9776-695badde0fa3@github.com>
References: <CqHLqLwPqP7FNqq1_-y0qLEXEm5y0CBmNZMXUxyUdl0=.2b9cfb9c-9aea-4947-9776-695badde0fa3@github.com>
Message-ID: <UQO9RtafD97OQ83zJotm9ASmI2wO463ZHKlZAE2ZtNU=.bef4ad59-e12f-456e-9132-bc01dc3342e0@github.com>

On Wed, 24 Nov 2021 22:34:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is about propagating constructor and parameter annotations to the anonymous class constructor. Currently we are propagating them to bridge methods which are synthetic. Propagating them to the anonymous class constructor seems sensible given that they are mandated by the spec. Please review also the related CSR,
> 
> TIA

This pull request has been closed without being integrated.

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

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

From alex.buckley at oracle.com  Wed Feb 16 18:33:14 2022
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 16 Feb 2022 10:33:14 -0800
Subject: RFE to change try-with-resources
Message-ID: <1804cbd0-4a4d-096e-c386-e80d2f36129f@oracle.com>

We received a suggestion to change the exception thrown by 
try-with-resources in the case when (paraphrasing) a more serious 
exception is thrown from closing a resource than was thrown from the try 
block.

https://bugs.openjdk.java.net/browse/JDK-8281964

Notably, if the try block throws an Exception but the automatic call to 
close() throws an Error, then _today_ try-with-resources throws the 
Exception (with the Error as a suppressed exception) but _in future_ 
would throw the Error (with the Exception as a suppressed exception).

Because a try-with-resources statement has so many parts that can throw 
-- resource initializers, try block, catch block(s), finally block, and 
resource closers -- there are numerous scenarios where a single 
try-with-resources statement can have different exceptions arising from 
different parts, and we need to choose which exception is the "real" 
reason for terminating the try-with-resources statement. A policy that 
chooses a more-serious exception over a less-serious exception is, 
perhaps, in itself, a good idea -- but such a policy would have to be 
applied consistently in all scenarios, which would significantly change 
the try-with-resources feature.

In any case, it's not a source-compatible change. A try-with-resources 
statement that throws a checked exception today could throw an unchecked 
exception in future, so you would get a compile-time error where the 
rest of the program tries to catch the checked exception.

This RFE is a good example of something that feels like a "small tweak" 
to a much-loved feature, but would actually make the feature harder to 
learn and use -- to say nothing of the compatibility impact of changing 
the feature so long after its introduction (try-with-resources shipped 
in Java 7 after huge amounts of discussion).

Alex

From jjg at openjdk.java.net  Thu Feb 17 16:30:20 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 17 Feb 2022 16:30:20 GMT
Subject: RFR: JDK-8281217: Source file launch with security manager enabled
 fails
Message-ID: <D2G_y9ZLFzQy8gDw-WU9OHwbTu-BQczqrNt9rOqTOM4=.cccf0a50-8a48-4233-88f4-2c8f7bdc2e32@github.com>

Please review a small change to the source-code launcher to formally reject the use of a security manager in programs launched by the source-code launcher.  This changes the previous behavior where it was tacitly allowed but would trigger an `IllegalAccessException` unless extra (effectively, all) privileges were granted to the `jdk.compiler` module.

The test is modified too reflect the new behavior.

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

Commit messages:
 - JDK-8281217: Source file launch with security manager enabled fails

Changes: https://git.openjdk.java.net/jdk/pull/7518/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=7518&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8281217
  Stats: 67 lines in 3 files changed: 26 ins; 28 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7518.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7518/head:pull/7518

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

From vromero at openjdk.java.net  Thu Feb 17 17:11:07 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 17 Feb 2022 17:11:07 GMT
Subject: RFR: 8280866: SuppressWarnings does not work properly in
 package-info and module-info
In-Reply-To: <seVJWKBGW5-VNijGS76vF7lnNzHgjc7wSCsLFV40n48=.9acbcfde-b72d-4b81-96b1-f491ed276dd8@github.com>
References: <seVJWKBGW5-VNijGS76vF7lnNzHgjc7wSCsLFV40n48=.9acbcfde-b72d-4b81-96b1-f491ed276dd8@github.com>
Message-ID: <H0yxZSnaMFK6JN5OU_RxkfEpfeBE6bqicO7GqbcKjOs=.5bc76c7d-d181-41fe-aee7-59bfb5cdb59f@github.com>

On Fri, 28 Jan 2022 10:57:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> `@SuppressWarnings` is not handled properly in `module-info` and, after https://bugs.openjdk.java.net/browse/JDK-8280744, also not in `package-info`. This patch attempts to fix that, by correctly deferring the warnings, and the printing them at an appropriate point.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

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

From prappo at openjdk.java.net  Thu Feb 17 17:52:24 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Thu, 17 Feb 2022 17:52:24 GMT
Subject: RFR: 8282056: Clean up com.sun.tools.javac.util.GraphUtils
Message-ID: <QS60KZ9wBYlTtNWsz7bgrwj4k2RO-ZlqhRX8RuZ_Pf4=.b3e82e6b-5ae8-429e-9133-071f5590abbd@github.com>

Please review this trivial cleanup.

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

Commit messages:
 - Fix code
 - Fix comments

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

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

From jjg at openjdk.java.net  Thu Feb 17 18:55:09 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 17 Feb 2022 18:55:09 GMT
Subject: RFR: 8282056: Clean up com.sun.tools.javac.util.GraphUtils
In-Reply-To: <QS60KZ9wBYlTtNWsz7bgrwj4k2RO-ZlqhRX8RuZ_Pf4=.b3e82e6b-5ae8-429e-9133-071f5590abbd@github.com>
References: <QS60KZ9wBYlTtNWsz7bgrwj4k2RO-ZlqhRX8RuZ_Pf4=.b3e82e6b-5ae8-429e-9133-071f5590abbd@github.com>
Message-ID: <TYH-rIF4Iz4CEbDKSdvPv1z3KSKmpg3iYVaWmDeOoo4=.6c86043b-7a4d-4b5b-af74-a28cb22c0b6d@github.com>

On Thu, 17 Feb 2022 17:45:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial cleanup.

Good catches

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

Marked as reviewed by jjg (Reviewer).

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

From mcimadamore at openjdk.java.net  Thu Feb 17 18:55:09 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 17 Feb 2022 18:55:09 GMT
Subject: RFR: 8282056: Clean up com.sun.tools.javac.util.GraphUtils
In-Reply-To: <QS60KZ9wBYlTtNWsz7bgrwj4k2RO-ZlqhRX8RuZ_Pf4=.b3e82e6b-5ae8-429e-9133-071f5590abbd@github.com>
References: <QS60KZ9wBYlTtNWsz7bgrwj4k2RO-ZlqhRX8RuZ_Pf4=.b3e82e6b-5ae8-429e-9133-071f5590abbd@github.com>
Message-ID: <47mtZLW50AKwMhJ3enhrmy-Hv7EQLyaH_jtBfdU_GUI=.ee3a3c4c-7920-4778-92e5-707c9b81f85f@github.com>

On Thu, 17 Feb 2022 17:45:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial cleanup.

Looks good!

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

Marked as reviewed by mcimadamore (Reviewer).

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

From vromero at openjdk.java.net  Thu Feb 17 23:53:50 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 17 Feb 2022 23:53:50 GMT
Subject: RFR: 8282056: Clean up com.sun.tools.javac.util.GraphUtils
In-Reply-To: <QS60KZ9wBYlTtNWsz7bgrwj4k2RO-ZlqhRX8RuZ_Pf4=.b3e82e6b-5ae8-429e-9133-071f5590abbd@github.com>
References: <QS60KZ9wBYlTtNWsz7bgrwj4k2RO-ZlqhRX8RuZ_Pf4=.b3e82e6b-5ae8-429e-9133-071f5590abbd@github.com>
Message-ID: <wK_MpUA6ZmHgI2QwixxYjU3mvEDIUVn2wWpXjj6cnzg=.36511d2c-629b-4ac2-89b7-7d8f26dabeda@github.com>

On Thu, 17 Feb 2022 17:45:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial cleanup.

Marked as reviewed by vromero (Reviewer).

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

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

From sundar at openjdk.java.net  Fri Feb 18 05:10:53 2022
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Fri, 18 Feb 2022 05:10:53 GMT
Subject: RFR: JDK-8281217: Source file launch with security manager enabled
 fails
In-Reply-To: <D2G_y9ZLFzQy8gDw-WU9OHwbTu-BQczqrNt9rOqTOM4=.cccf0a50-8a48-4233-88f4-2c8f7bdc2e32@github.com>
References: <D2G_y9ZLFzQy8gDw-WU9OHwbTu-BQczqrNt9rOqTOM4=.cccf0a50-8a48-4233-88f4-2c8f7bdc2e32@github.com>
Message-ID: <ofUJmuUCaWoswtDVVCxM2vZkCw2oWL6MwwOnudDJBCc=.c9039b79-76da-454c-9447-1b7b3b44e538@github.com>

On Thu, 17 Feb 2022 16:22:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a small change to the source-code launcher to formally reject the use of a security manager in programs launched by the source-code launcher.  This changes the previous behavior where it was tacitly allowed but would trigger an `IllegalAccessException` unless extra (effectively, all) privileges were granted to the `jdk.compiler` module.
> 
> The test is modified too reflect the new behavior.

LGTM

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

Marked as reviewed by sundar (Reviewer).

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

From jlahoda at openjdk.java.net  Fri Feb 18 11:07:58 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 18 Feb 2022 11:07:58 GMT
Subject: Integrated: 8280866: SuppressWarnings does not work properly in
 package-info and module-info
In-Reply-To: <seVJWKBGW5-VNijGS76vF7lnNzHgjc7wSCsLFV40n48=.9acbcfde-b72d-4b81-96b1-f491ed276dd8@github.com>
References: <seVJWKBGW5-VNijGS76vF7lnNzHgjc7wSCsLFV40n48=.9acbcfde-b72d-4b81-96b1-f491ed276dd8@github.com>
Message-ID: <gXf9lBcD70K6pUQkCfXqDQ5bn_vyLcnPLKECkUksBjs=.4ec85473-3a66-48ce-944a-6e64d11c8572@github.com>

On Fri, 28 Jan 2022 10:57:50 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> `@SuppressWarnings` is not handled properly in `module-info` and, after https://bugs.openjdk.java.net/browse/JDK-8280744, also not in `package-info`. This patch attempts to fix that, by correctly deferring the warnings, and the printing them at an appropriate point.

This pull request has now been integrated.

Changeset: e3365041
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e3365041bdef4dc09f3e5967124103e4364614fb
Stats:     246 lines in 4 files changed: 234 ins; 0 del; 12 mod

8280866: SuppressWarnings does not work properly in package-info and module-info

Reviewed-by: darcy, vromero

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

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

From prappo at openjdk.java.net  Fri Feb 18 13:13:52 2022
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 18 Feb 2022 13:13:52 GMT
Subject: Integrated: 8282056: Clean up com.sun.tools.javac.util.GraphUtils
In-Reply-To: <QS60KZ9wBYlTtNWsz7bgrwj4k2RO-ZlqhRX8RuZ_Pf4=.b3e82e6b-5ae8-429e-9133-071f5590abbd@github.com>
References: <QS60KZ9wBYlTtNWsz7bgrwj4k2RO-ZlqhRX8RuZ_Pf4=.b3e82e6b-5ae8-429e-9133-071f5590abbd@github.com>
Message-ID: <sld3VWVYAGECqJwNjOw3S2IQKYMGiZudLGH5uxKMw1Y=.05503ae7-844a-4b52-9423-e9bf45692ded@github.com>

On Thu, 17 Feb 2022 17:45:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial cleanup.

This pull request has now been integrated.

Changeset: f5120b76
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f5120b764c6f84776e7ea335d7ff59b16f6496b0
Stats:     12 lines in 2 files changed: 1 ins; 0 del; 11 mod

8282056: Clean up com.sun.tools.javac.util.GraphUtils

Reviewed-by: jjg, mcimadamore, vromero

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

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

From john.r.rose at oracle.com  Fri Feb 18 22:41:56 2022
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 18 Feb 2022 14:41:56 -0800
Subject: RFE to change try-with-resources
In-Reply-To: <1804cbd0-4a4d-096e-c386-e80d2f36129f@oracle.com>
References: <1804cbd0-4a4d-096e-c386-e80d2f36129f@oracle.com>
Message-ID: <6B4D7264-0C1B-4AC8-9785-52010FB72535@oracle.com>

On 16 Feb 2022, at 10:33, Alex Buckley wrote:

> This RFE is a good example of something that feels like a "small 
> tweak" to a much-loved feature, but would actually make the feature 
> harder to learn and use --
> to say nothing of the compatibility impact of changing the feature so 
> long after its introduction (try-with-resources shipped in Java 7 
> after huge amounts of discussion).

Good summary.  This case is also an example of that other kind of 
?small tweak? that turns out to be the first step down a slippery 
slope, even if at first we thought it was a ?one and done? 
incremental improvement.  The slope in this case is dealing with an 
amorphous cloud of expectations about which throwables should take 
precedence over which other throwables.  Anything the language does 
(including basically nothing, as today) is going to leave open 
disappointments (from those with more definite expectations) that we 
didn?t go far enough in defining the new priority/suppression order 
for exceptions.  The JBS entry doesn?t ask for a distinction between 
RuntimeExceptions and other Exceptions, but the next one surely would.  
(And maybe java.base throwables should be ordered differently from 
application throwables?)

Ultimately, requests like this for finely-graded distinctions like this 
tend to be proxies for the basic complaint of, ?why doesn?t javac 
just read my mind??  If such a complaint is dressed up as a plausible 
incremental tweak like the JBS entry in question here, then we might 
fall for it, but afterwards we will still be hearing users say, ?hey 
wait, *that* didn?t really read my mind, so here?s *another* RFE?.

The best way to stay out of the mind-reading game is to stick to 
reasonably simple semantics, and say ?that?s what we all get, 
let?s make the best of it?.

Another way to skirt the mind-reading game is to add small annotations 
which would change the behavior from the main meaning of the code to 
some (hopefully popular) secondary variant meaning.  In the case of TWR 
I mean some simple declarative notation to add to a TWR statement that 
would guide close-errors correctly atop body-exceptions.  (Can you do 
this today?  Don?t know; don?t care ATM, and it?s probably not 
worth the complexity.)  Another example would be legacy non-total switch 
statements, which unfortunately fail to read the minds of programmers 
who intend them to be total; again, you can?t just change the language 
to read everyone?s mind differently, but you could add some tweaky 
annotation.  This would be a different slippery slope, though:  The 
extra tweaky annotations are usually not worth the language complexity 
they add.

? John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20220218/43681fa4/attachment.htm>

From joe.darcy at oracle.com  Sat Feb 19 01:34:38 2022
From: joe.darcy at oracle.com (Joe Darcy)
Date: Fri, 18 Feb 2022 17:34:38 -0800
Subject: RFE to change try-with-resources
In-Reply-To: <6B4D7264-0C1B-4AC8-9785-52010FB72535@oracle.com>
References: <1804cbd0-4a4d-096e-c386-e80d2f36129f@oracle.com>
 <6B4D7264-0C1B-4AC8-9785-52010FB72535@oracle.com>
Message-ID: <df9adbbe-d497-107b-9366-05462a5fa97d@oracle.com>


On 2/18/2022 2:41 PM, John Rose wrote:
>
> On 16 Feb 2022, at 10:33, Alex Buckley wrote:
>
>     This RFE is a good example of something that feels like a "small
>     tweak" to a much-loved feature, but would actually make the
>     feature harder to learn and use --
>     to say nothing of the compatibility impact of changing the feature
>     so long after its introduction (try-with-resources shipped in Java
>     7 after huge amounts of discussion).
>
> Good summary. This case is also an example of that other kind of 
> ?small tweak? that turns out to be the first step down a slippery 
> slope, even if at first we thought it was a ?one and done? incremental 
> improvement. The slope in this case is dealing with an amorphous cloud 
> of expectations about which throwables should take precedence over 
> which other throwables. Anything the language does (including 
> basically nothing, as today) is going to leave open disappointments 
> (from those with more definite expectations) that we didn?t go far 
> enough in defining the new priority/suppression order for exceptions. 
> The JBS entry doesn?t ask for a distinction between RuntimeExceptions 
> and other Exceptions, but the next one surely would. (And maybe 
> java.base throwables should be ordered differently from application 
> throwables?)
>
> Ultimately, requests like this for finely-graded distinctions like 
> this tend to be proxies for the basic complaint of, ?why doesn?t javac 
> just read my mind?? If such a complaint is dressed up as a plausible 
> incremental tweak like the JBS entry in question here, then we might 
> fall for it, but afterwards we will still be hearing users say, ?hey 
> wait, /that/ didn?t really read my mind, so here?s /another/ RFE?.
>
> The best way to stay out of the mind-reading game is to stick to 
> reasonably simple semantics, and say ?that?s what we all get, let?s 
> make the best of it?.
>
FYI, there were voluminous discussions about try-with-resource (nee ARM 
-- automatic resource management) during Project Coin. The public 
discussions are archived at:

https://mail.openjdk.java.net/pipermail/coin-dev/

IIRC, during? the development phase of try-with-sources it was also 
suggested that more severe throwables should receive more prominent 
placement in the array of suppressed exceptions. It was also explicitly 
considered, and rejected, to have any special handling for the 
ThreadDeath error thrown? by the long-deprecated Thead.stop method.

The reasons these variants were rejected are aligned with the rationale 
put forward by Alex and John: having a predictable feature that is more 
straightforward to use was judged to be better than a more "clever" 
feature in error handling.

I find there is usually better leverage to spend effort on the 
common-path rather than making the error-handling more complicated.

As a retrospective investigation of the usage of try-with-resources, it 
would be interesting to see how often suppressed exception are checked 
at all.

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

From shade at openjdk.java.net  Mon Feb 21 06:03:49 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 21 Feb 2022 06:03:49 GMT
Subject: RFR: 8281507: Two javac tests have bad jtreg `@clean` tags [v2]
In-Reply-To: <E7fufqq_wWXAiY67VKyX2QqEkNbhffZuUW3s967fWtE=.35550f01-bc2d-4403-939f-2dc5b7937df4@github.com>
References: <BP2PZ4WTeQnNFmOKcRcdjWKZvv11DZr4sz1pScJYGl4=.630c487a-a7f1-485c-bdf7-95c1b80aab15@github.com>
 <E7fufqq_wWXAiY67VKyX2QqEkNbhffZuUW3s967fWtE=.35550f01-bc2d-4403-939f-2dc5b7937df4@github.com>
Message-ID: <ofriVOTunAHLnTazeCyQc6E7acTLJBwu9OpbTJ_Hqg0=.5ec414cf-6191-4fd4-a7cb-1578429fbe0a@github.com>

On Thu, 10 Feb 2022 07:09:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Apparently, jtreg does not support `*` globbing. It now throws errors for upcoming jtreg 7.
>> 
>> Additional testing:
>>  - [x] Affected tests still pass
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use clean * instead

Anyone? :)

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

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

From jpai at openjdk.java.net  Mon Feb 21 11:27:55 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 21 Feb 2022 11:27:55 GMT
Subject: RFR: 8281705: SourceLauncherTest.testSystemProperty isn't being
 run
In-Reply-To: <UkGIFcUqulzfEhXyDu9HHaR6Owf0F5RrlWR3wxO1Zng=.59c4cf1a-ab41-4ca4-bbd2-a43653ac374a@github.com>
References: <UkGIFcUqulzfEhXyDu9HHaR6Owf0F5RrlWR3wxO1Zng=.59c4cf1a-ab41-4ca4-bbd2-a43653ac374a@github.com>
Message-ID: <O29t4ICUtzcrp4z2R3tKDYVO7XEuZid5wFqC2Jn0JqI=.7dcbed4b-c1c3-4d34-b3ac-edcc3da5f0e1@github.com>

On Mon, 14 Feb 2022 06:37:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which fixes the issue noted in https://bugs.openjdk.java.net/browse/JDK-8281705? 
> 
> The change in this commit adds the `@Test` annotation on the test method to make sure it gets run. Before this change, the test run logs showed that `28 tests` were being run and now after this change, the logs report `29 tests` and I can see `testSystemProperty` in the test run logs.

Any reviews for this one, please?

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

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

From hchao at openjdk.java.net  Tue Feb 22 20:27:22 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 22 Feb 2022 20:27:22 GMT
Subject: RFR: 8277474: jarsigner does not check if algorithm parameters are
 disabled
Message-ID: <mkhEn9Jgvl78arz0_BZYU1a50q2boR0e1qNHmge0aXk=.b63d4fb3-732e-4f2f-a665-98ca53c5ef94@github.com>

This fixes jarsigner to enforce checking against algorithm constraint properties so when the signature algorithms parameters use disabled or legacy algorithms, it will emit warnings accordingly. If the algorithm used in parameters is disabled, jarsigner treats the jar as unsigned.

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

Commit messages:
 - 8277474: jarsigner does not check if algorithm parameters are disabled
 - Testcase updated
 - 8265765: DomainKeyStore may stop enumerating aliases if a constituting KeyStore is empty

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

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

From hchao at openjdk.java.net  Tue Feb 22 20:31:50 2022
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Tue, 22 Feb 2022 20:31:50 GMT
Subject: Withdrawn: 8277474: jarsigner does not check if algorithm parameters
 are disabled
In-Reply-To: <mkhEn9Jgvl78arz0_BZYU1a50q2boR0e1qNHmge0aXk=.b63d4fb3-732e-4f2f-a665-98ca53c5ef94@github.com>
References: <mkhEn9Jgvl78arz0_BZYU1a50q2boR0e1qNHmge0aXk=.b63d4fb3-732e-4f2f-a665-98ca53c5ef94@github.com>
Message-ID: <GTXqYSCuBAjkrjcLy46kOpeB0jbEYTVVfDknbduj6oE=.f033b89f-6d87-41db-85cc-c2399b7c2dd0@github.com>

On Tue, 22 Feb 2022 20:18:19 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> This fixes jarsigner to enforce checking against algorithm constraint properties so when the signature algorithms parameters use disabled or legacy algorithms, it will emit warnings accordingly. If the algorithm used in parameters is disabled, jarsigner treats the jar as unsigned.

This pull request has been closed without being integrated.

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

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

From jpai at openjdk.java.net  Wed Feb 23 01:42:26 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 23 Feb 2022 01:42:26 GMT
Subject: RFR: 8281705: SourceLauncherTest.testSystemProperty isn't being
 run [v2]
In-Reply-To: <UkGIFcUqulzfEhXyDu9HHaR6Owf0F5RrlWR3wxO1Zng=.59c4cf1a-ab41-4ca4-bbd2-a43653ac374a@github.com>
References: <UkGIFcUqulzfEhXyDu9HHaR6Owf0F5RrlWR3wxO1Zng=.59c4cf1a-ab41-4ca4-bbd2-a43653ac374a@github.com>
Message-ID: <NY5lgbJ8FvhYkL-nXEqPFS1WH0Fs_ZhdZ01AHTSRjqI=.67b145fc-e248-42a4-98aa-d2d92e6e158b@github.com>

> Can I please get a review of this test-only change which fixes the issue noted in https://bugs.openjdk.java.net/browse/JDK-8281705? 
> 
> The change in this commit adds the `@Test` annotation on the test method to make sure it gets run. Before this change, the test run logs showed that `28 tests` were being run and now after this change, the logs report `29 tests` and I can see `testSystemProperty` in the test run logs.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge latest from master branch
 - 8281705: SourceLauncherTest.testSystemProperty isn't being run

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7456/files
  - new: https://git.openjdk.java.net/jdk/pull/7456/files/cc170b6f..970b2a0e

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

  Stats: 14358 lines in 429 files changed: 9621 ins; 2862 del; 1875 mod
  Patch: https://git.openjdk.java.net/jdk/pull/7456.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/7456/head:pull/7456

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

From jjg at openjdk.java.net  Wed Feb 23 16:53:52 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 23 Feb 2022 16:53:52 GMT
Subject: Integrated: JDK-8281217: Source file launch with security manager
 enabled fails
In-Reply-To: <D2G_y9ZLFzQy8gDw-WU9OHwbTu-BQczqrNt9rOqTOM4=.cccf0a50-8a48-4233-88f4-2c8f7bdc2e32@github.com>
References: <D2G_y9ZLFzQy8gDw-WU9OHwbTu-BQczqrNt9rOqTOM4=.cccf0a50-8a48-4233-88f4-2c8f7bdc2e32@github.com>
Message-ID: <ca730Fcgae4Iem7SfHLVcTAsjd6tWLRgGQuoqdwVhbg=.98c23cbd-d561-474d-9211-1f121eb61f20@github.com>

On Thu, 17 Feb 2022 16:22:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a small change to the source-code launcher to formally reject the use of a security manager in programs launched by the source-code launcher.  This changes the previous behavior where it was tacitly allowed but would trigger an `IllegalAccessException` unless extra (effectively, all) privileges were granted to the `jdk.compiler` module.
> 
> The test is modified too reflect the new behavior.

This pull request has now been integrated.

Changeset: 99b8ed9d
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/99b8ed9dbf88e21a42a8d2f6249bfab7176e7d42
Stats:     67 lines in 3 files changed: 26 ins; 28 del; 13 mod

8281217: Source file launch with security manager enabled fails

Reviewed-by: sundar

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

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

From darcy at openjdk.java.net  Fri Feb 25 03:01:05 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 25 Feb 2022 03:01:05 GMT
Subject: RFR: 8281507: Two javac tests have bad jtreg `@clean` tags [v2]
In-Reply-To: <E7fufqq_wWXAiY67VKyX2QqEkNbhffZuUW3s967fWtE=.35550f01-bc2d-4403-939f-2dc5b7937df4@github.com>
References: <BP2PZ4WTeQnNFmOKcRcdjWKZvv11DZr4sz1pScJYGl4=.630c487a-a7f1-485c-bdf7-95c1b80aab15@github.com>
 <E7fufqq_wWXAiY67VKyX2QqEkNbhffZuUW3s967fWtE=.35550f01-bc2d-4403-939f-2dc5b7937df4@github.com>
Message-ID: <S7mQyb-reEJOW-AFLVO4BFqa3Ea-QtHpE6NmBARq42s=.716106de-9eb2-4796-8134-505970c63f09@github.com>

On Thu, 10 Feb 2022 07:09:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Apparently, jtreg does not support `*` globbing. It now throws errors for upcoming jtreg 7.
>> 
>> Additional testing:
>>  - [x] Affected tests still pass
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use clean * instead

Marked as reviewed by darcy (Reviewer).

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

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

From ethan at mccue.dev  Fri Feb 25 03:21:51 2022
From: ethan at mccue.dev (Ethan McCue)
Date: Thu, 24 Feb 2022 22:21:51 -0500
Subject: JDK-6397027 likely doesn't have a satisfying solution
Message-ID: <CA+NR86hujcpV9JW4hY+J0q1tALk2ibzFs8g1EHZBBqj9SPMNoQ@mail.gmail.com>

Following advice from Vicente, ~3 weeks ago I started to look at
JDK-6397027.

"Some messages begin with capital letters; others do not. We should decide
which is right and fix the rest."

The issue as stated seems to just be one of consistency. There are some
messages which begin with capital letters and others do not. So to start I
tried to figure out who the winner should be.

When an error message is a single sentence on a single line it is the
overwhelming "consensus of the corpus" that it starts with a lower-case
letter.

A few examples

compiler.err.wrong.receiver
wrong receiver parameter name

compiler.err.initializer.not.allowed
initializers not allowed in interfaces

compiler.err.cant.inherit.from.anon
cannot inherit from anonymous class


There are some error messages which obviously break this convention and
could be put more in line.

compiler.err.bad.functional.intf.anno
Unexpected @FunctionalInterface annotation

compiler.err.proc.no.service
A ServiceLoader was not usable and is required for annotation processing.

compiler.err.no.java.lang
Unable to find package java.lang in platform classes

But after mulling it over, I don't think the solution is as clear cut as
performing find-and-replace on all leading capital letters.

---

I started my analysis by going through all 90 messages
in compiler.properties and marking the ones that felt like "obvious"
candidates to change to start lower case. Of these 38 did not feel clear
cut, so I went back through to try to find a way to articulate why.

Capitals seem to most necessary as a mechanism for making grammar "flow" if
we have

* Messages that go on multiple lines.

compiler.err.icls.cant.have.static.decl
Illegal static declaration in inner class {0} modifier ''static'' is only
allowed in constant variable declarations
* Messages which have multiple distinct clauses

compiler.err.option.removed.source Source option {0} is no longer
supported. Use {1} or later.
compiler.err.proc.cant.create.loader
Could not create class loader for annotation processors: {0}
compiler.note.compressed.diags
Some messages have been simplified; recompile with -Xdiags:verbose to get
full output

* Messages which will be composed into one of the above

compiler.note.removal.recompile
Recompile with -Xlint:removal for details.

* Consistency with a variant which does one of the above.

compiler.err.bad.functional.intf.anno
Unexpected @FunctionalInterface annotation

compiler.err.bad.functional.intf.anno.1
Unexpected @FunctionalInterface annotation {0}
---

I broke up the categories of information that existing error messages
convey as follows.

* where - What area of the code was incorrect
* what - The thing that was wrong about the code
* why - Why that thing that was wrong was wrong
* hint - How the user might remedy this error

I then made a spreadsheet here where I manually filled in my read on that
information

https://docs.google.com/spreadsheets/d/149dqMEODacRQrjA4mrjh-4quN_vFw0yF5SIPslefiCc/edit?usp=sharing

And with that framing, it seems most "legitimate" use of capitals is in an
attempt to encode more information that just "what" went wrong. Most often
the culprit is a message trying to present a "hint" to the user, but
sometimes it is just that the "what", "why" or "where" does not fit
naturally into a single sentence.

And at this point I think I've opened a can of worms, because there are
quite a few other errors in the corpus which break the "single statement"
rule for good reason, and with different solutions.

compiler.err.foreach.not.applicable.to.type
for-each not applicable to expression type required: {1} found: {0}

compiler.err.preview.not.latest
invalid source release {0} with --enable-preview\n(preview language
features are only supported for release {1})
What I think this means is that there is no easy way to make the error
messages "consistent" within the current framework without either stripping
useful info from the offenders or adopting some output style which doesn't
need to bend to support hints.

---

I am at least partially conscious that the "right" solution here - the one
that ends with the JDK having consistent, helpful, and informative error
messages - is a JEP level effort. I haven't proven yet that I'm tall enough
to ride that ride, but I hope articulating this can move the needle some.

Caveats
* There is probably an unhealthy dose of confirmation bias on my part.
Error messages are my White Whale and "why can't they just be like rust"
crosses my mind a bit too often.
* I mostly looked directly at what was in the compiler.properties files so
I don't have a totally complete picture of how some of the smaller messages
are glued together.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20220224/9bbbebf3/attachment.htm>

From jlahoda at openjdk.java.net  Fri Feb 25 12:39:32 2022
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 25 Feb 2022 12:39:32 GMT
Subject: RFR: 8178701: Compile error with switch statement on protected enum
 defined in parent inner class
Message-ID: <UXMkMNM0f1oqwPNmDrtDcMHOaDNJEWiZ7wMAXTU_HlQ=.534de418-1724-4c56-b61a-b6265f3c4b8b@github.com>

Consider the following code in two packages:

package foo;

import bar.D.E;

public class A {

    public static class B {

        protected enum C {
            X, Y, Z
        }
    }

    public static void main(String... args) {
        new E().run(B.C.X);
    }
}



package bar;

import foo.A.B;

public class D {

    public static class E extends B {

        public void run(C arg) {
            switch (arg) {
                default:
                    System.out.println("OK");
            }
        }
    }
}


Accessing `foo.A.B.C` in `bar.D.E` is OK, as it is accessible through the `E`'s superclass. But, for the `switch`, javac creates a map (array) from runtime ordinals of constants of `E` to compile-time positions. But, this mapping is in a different class that does not extend `B`, so internal method lookups fail for it, as the methods are not accessible per Java rules.

But, at runtime, the enum class is effectively public, so I think it is possible to ignore the protected access rules and accept the method invocations while generatting the mapping code, which is what this patch is trying to do.

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

Commit messages:
 - 8178701: Compile error with switch statement on protected enum defined in parent inner class

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

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

From shade at openjdk.java.net  Mon Feb 28 07:37:53 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 28 Feb 2022 07:37:53 GMT
Subject: RFR: 8281507: Two javac tests have bad jtreg `@clean` tags [v2]
In-Reply-To: <E7fufqq_wWXAiY67VKyX2QqEkNbhffZuUW3s967fWtE=.35550f01-bc2d-4403-939f-2dc5b7937df4@github.com>
References: <BP2PZ4WTeQnNFmOKcRcdjWKZvv11DZr4sz1pScJYGl4=.630c487a-a7f1-485c-bdf7-95c1b80aab15@github.com>
 <E7fufqq_wWXAiY67VKyX2QqEkNbhffZuUW3s967fWtE=.35550f01-bc2d-4403-939f-2dc5b7937df4@github.com>
Message-ID: <NEsFAi_Ng0l1r_sUoxmqp27_uZFWrBw6kvMOOf7OKuQ=.521bdf68-1972-4657-a9be-a250e95250ed@github.com>

On Thu, 10 Feb 2022 07:09:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Apparently, jtreg does not support `*` globbing. It now throws errors for upcoming jtreg 7.
>> 
>> Additional testing:
>>  - [x] Affected tests still pass
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use clean * instead

Thank you.

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

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

From shade at openjdk.java.net  Mon Feb 28 07:37:53 2022
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 28 Feb 2022 07:37:53 GMT
Subject: Integrated: 8281507: Two javac tests have bad jtreg `@clean` tags
In-Reply-To: <BP2PZ4WTeQnNFmOKcRcdjWKZvv11DZr4sz1pScJYGl4=.630c487a-a7f1-485c-bdf7-95c1b80aab15@github.com>
References: <BP2PZ4WTeQnNFmOKcRcdjWKZvv11DZr4sz1pScJYGl4=.630c487a-a7f1-485c-bdf7-95c1b80aab15@github.com>
Message-ID: <23SYmnFFtPZEXhRzYjlj9pjuFYs67TizIeNaijtGJAI=.3e40d904-55fa-4683-8012-0aaa68cffb4d@github.com>

On Wed, 9 Feb 2022 06:44:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Apparently, jtreg does not support `*` globbing. It now throws errors for upcoming jtreg 7.
> 
> Additional testing:
>  - [x] Affected tests still pass

This pull request has now been integrated.

Changeset: 86723d48
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/86723d4892485651bcae735ed13545ea89b9bb22
Stats:     6 lines in 2 files changed: 0 ins; 0 del; 6 mod

8281507: Two javac tests have bad jtreg `@clean` tags

Reviewed-by: darcy

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

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

From darcy at openjdk.java.net  Mon Feb 28 22:06:52 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 28 Feb 2022 22:06:52 GMT
Subject: RFR: JDK-8282411: Add useful predicates to ElementKind
Message-ID: <yWddqvypCSGP3OHB0r9LAvvEs_HAZYgCMn6V60aav80=.3a567908-a9c7-4e8b-a5c7-b2916469fc2e@github.com>

Discussion from a recent review in javadoc, adding some more functionality to ElementKind predicates.

Please also review the CSR: https://bugs.openjdk.java.net/browse/JDK-8282461

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

Commit messages:
 - Add tests.
 - JDK-8282411: Add useful predicates to ElementKind

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

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

From darcy at openjdk.java.net  Mon Feb 28 22:09:44 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 28 Feb 2022 22:09:44 GMT
Subject: RFR: JDK-8282462: Remove unnecessary use of
 @SuppressWarnings("preview")
Message-ID: <3qAJCx1FBnD2Hc09kVhlIPUuAPF5UXz5QoT2dfMWoTk=.7e726fff-df48-4391-8e18-435bd5b607c9@github.com>

Remove unneeded @SuppressWarnings("preview") annotations now that records are final. I'll update copyrights if neededbefore pushing. Thanks.

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

Commit messages:
 - Update copyrights.
 - JDK-8282462: Remove unnecessary use of @SuppressWarnings("preview")

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

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

From vromero at openjdk.java.net  Mon Feb 28 22:09:44 2022
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 28 Feb 2022 22:09:44 GMT
Subject: RFR: JDK-8282462: Remove unnecessary use of
 @SuppressWarnings("preview")
In-Reply-To: <3qAJCx1FBnD2Hc09kVhlIPUuAPF5UXz5QoT2dfMWoTk=.7e726fff-df48-4391-8e18-435bd5b607c9@github.com>
References: <3qAJCx1FBnD2Hc09kVhlIPUuAPF5UXz5QoT2dfMWoTk=.7e726fff-df48-4391-8e18-435bd5b607c9@github.com>
Message-ID: <MsgPW5fUm5c2GvXFHtvS4L48Fsr5BCWzR6gu28E4ZdQ=.9a3db133-e3b7-4559-bed7-46588e887413@github.com>

On Mon, 28 Feb 2022 21:54:34 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Remove unneeded @SuppressWarnings("preview") annotations now that records are final. I'll update copyrights if neededbefore pushing. Thanks.

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From darcy at openjdk.java.net  Mon Feb 28 22:18:07 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 28 Feb 2022 22:18:07 GMT
Subject: Integrated: JDK-8282462: Remove unnecessary use of
 @SuppressWarnings("preview")
In-Reply-To: <3qAJCx1FBnD2Hc09kVhlIPUuAPF5UXz5QoT2dfMWoTk=.7e726fff-df48-4391-8e18-435bd5b607c9@github.com>
References: <3qAJCx1FBnD2Hc09kVhlIPUuAPF5UXz5QoT2dfMWoTk=.7e726fff-df48-4391-8e18-435bd5b607c9@github.com>
Message-ID: <XxRhtE1gRbU11ue--nQBIfeIuRbuPnk8T18AEsH-8pc=.f53f0d8f-7a76-49a5-9a19-46460a817921@github.com>

On Mon, 28 Feb 2022 21:54:34 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Remove unneeded @SuppressWarnings("preview") annotations now that records are final. I'll update copyrights if neededbefore pushing. Thanks.

This pull request has now been integrated.

Changeset: 9d9618a3
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9d9618a3dd29cb9328a7275375e04eca2af20a93
Stats:     9 lines in 4 files changed: 0 ins; 5 del; 4 mod

8282462: Remove unnecessary use of @SuppressWarnings("preview")

Reviewed-by: vromero

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

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

From darcy at openjdk.java.net  Mon Feb 28 23:14:36 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 28 Feb 2022 23:14:36 GMT
Subject: RFR: JDK-8282464: Remove author tags from java.compiler
Message-ID: <43oBy4ugSWo4ZTdqyLZpYdhoGXfnlv5hbpgq_UQDCQI=.022914ac-4c49-44ce-bc57-73b4bea5c58e@github.com>

To align with current coding conventions, the @author tags in the java.compiler module should be removed. The tags have not been maintained and updated in many years. These tags date back to the addition of JSRs 199 and 269 in JDK 6.

The authors at the time for these files were generally some nonempty subset of Scott Seligman, Peter von der Ah?, Jon Gibbons, Scott Seligman, and myself. The tag information will remain in the history of course.

I'll update the copyright years on the files before any push.

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

Commit messages:
 - JDK-8282464: Remove author tags from java.compiler

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

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

From jjg at openjdk.java.net  Mon Feb 28 23:23:03 2022
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 28 Feb 2022 23:23:03 GMT
Subject: RFR: JDK-8282464: Remove author tags from java.compiler
In-Reply-To: <43oBy4ugSWo4ZTdqyLZpYdhoGXfnlv5hbpgq_UQDCQI=.022914ac-4c49-44ce-bc57-73b4bea5c58e@github.com>
References: <43oBy4ugSWo4ZTdqyLZpYdhoGXfnlv5hbpgq_UQDCQI=.022914ac-4c49-44ce-bc57-73b4bea5c58e@github.com>
Message-ID: <X6VUNshQZhacT0ecDdmJCb5oprgZSszs9Ceu92gV9N4=.ac02167a-d9f2-4915-8776-5752db6dfc5c@github.com>

On Mon, 28 Feb 2022 23:08:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To align with current coding conventions, the @author tags in the java.compiler module should be removed. The tags have not been maintained and updated in many years. These tags date back to the addition of JSRs 199 and 269 in JDK 6.
> 
> The authors at the time for these files were generally some nonempty subset of Scott Seligman, Peter von der Ah?, Jon Gibbons, Scott Seligman, and myself. The tag information will remain in the history of course.
> 
> I'll update the copyright years on the files before any push.

While the reference to coding conventions may be controversial in itself, I note that it is the case that SCM metadata provides a better way of tracking contributions, especially for all contributions since the code was open-sourced. For example, `git shortlog`.

I note an appearance by Martin B, and somewhat surprising, an appearance by Neal Gafter, who had left before the file with his name on had been written.

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

Marked as reviewed by jjg (Reviewer).

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

From darcy at openjdk.java.net  Mon Feb 28 23:32:32 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 28 Feb 2022 23:32:32 GMT
Subject: RFR: JDK-8282464: Remove author tags from java.compiler [v2]
In-Reply-To: <43oBy4ugSWo4ZTdqyLZpYdhoGXfnlv5hbpgq_UQDCQI=.022914ac-4c49-44ce-bc57-73b4bea5c58e@github.com>
References: <43oBy4ugSWo4ZTdqyLZpYdhoGXfnlv5hbpgq_UQDCQI=.022914ac-4c49-44ce-bc57-73b4bea5c58e@github.com>
Message-ID: <97LVbAUXZX8QzVkCzYJ8S_91RxDMEgp6mQag5F9ydz0=.a6e3f3bc-e0eb-46d3-a82c-73e4aa86745a@github.com>

> To align with current coding conventions, the @author tags in the java.compiler module should be removed. The tags have not been maintained and updated in many years. These tags date back to the addition of JSRs 199 and 269 in JDK 6.
> 
> The authors at the time for these files were generally some nonempty subset of Scott Seligman, Peter von der Ah?, Jon Gibbons, Scott Seligman, and myself. The tag information will remain in the history of course.
> 
> I'll update the copyright years on the files before any push.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Update copyrights.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7639/files
  - new: https://git.openjdk.java.net/jdk/pull/7639/files/872f8371..cea2cd7f

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

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

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

From darcy at openjdk.java.net  Mon Feb 28 23:32:33 2022
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 28 Feb 2022 23:32:33 GMT
Subject: Integrated: JDK-8282464: Remove author tags from java.compiler
In-Reply-To: <43oBy4ugSWo4ZTdqyLZpYdhoGXfnlv5hbpgq_UQDCQI=.022914ac-4c49-44ce-bc57-73b4bea5c58e@github.com>
References: <43oBy4ugSWo4ZTdqyLZpYdhoGXfnlv5hbpgq_UQDCQI=.022914ac-4c49-44ce-bc57-73b4bea5c58e@github.com>
Message-ID: <ZqjopzOX5hZdbLrcTWJnwUaeQgaa6IhtAt68Rcc_QLU=.341f74e3-5011-42c5-8136-9743bc20643e@github.com>

On Mon, 28 Feb 2022 23:08:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> To align with current coding conventions, the @author tags in the java.compiler module should be removed. The tags have not been maintained and updated in many years. These tags date back to the addition of JSRs 199 and 269 in JDK 6.
> 
> The authors at the time for these files were generally some nonempty subset of Scott Seligman, Peter von der Ah?, Jon Gibbons, Scott Seligman, and myself. The tag information will remain in the history of course.
> 
> I'll update the copyright years on the files before any push.

This pull request has now been integrated.

Changeset: 1f89acd8
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1f89acd8498945e1d531b7845748bcee8194115b
Stats:     308 lines in 83 files changed: 0 ins; 229 del; 79 mod

8282464: Remove author tags from java.compiler

Reviewed-by: jjg

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

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