From mchung at openjdk.java.net  Tue Dec  1 00:39:55 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 1 Dec 2020 00:39:55 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <9cyMSNayyu63LkCt6r1Ltrzzv7TPvcsity5IYimZNa4=.f35daee0-3c52-4844-8354-d4b0507c57ff@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
 <Q0QluOtDa_O6rcytLjro7EoDTvIUBgGNaBrTWaibg8M=.15d28b63-7381-404b-8ea2-2d7cc4f178de@github.com>
 <9cyMSNayyu63LkCt6r1Ltrzzv7TPvcsity5IYimZNa4=.f35daee0-3c52-4844-8354-d4b0507c57ff@github.com>
Message-ID: <IA94IwqxqI3TWPZcvjlHjKcgCiWzx490-uQgJoq2tj0=.e581e7cc-ddfc-4379-8bfa-6177628ab4bf@github.com>

On Mon, 30 Nov 2020 20:57:32 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 4480:
>> 
>>> 4478:     }
>>> 4479: 
>>> 4480:     private native Class<?>[] getPermittedSubclasses0();
>> 
>> Does this JVM method return the permitted subclasses or subinterfaces with the following conditions enforced by JLS:
>> 
>>    - If a sealed class C belongs to a named module, then every class named in the permits clause of the declaration of C must belong to the same module as C
>>    - If a sealed class C belongs to an unnamed module, then every class named in the permits clause of the declaration of C must belong to the same package as C
>> 
>> I didn't check the VM implementation.
>> 
>> If the return array contains only classes as specified above, `checkPackageAccessForClasses` can be simplified.
>
> The JVM method that returns the permitted subclasses (and interfaces) does not weed out permitted subclasses based on the above module requirements.  It returns all the classes listed in the PermittedSubclasses attribute that it is able to load.

So it could also return a class listed in `PermittedSubclasses` attribute but not a subclass of this sealed class, right?

The specification of `Class::getPermittedSubclasses` says:

> Returns an array containing {@code Class} objects representing the direct subclasses or direct implementation classes permitted to extend or direct subinterfaces or subclasses permitted to extend or implement this class or interface if it is sealed. 

I expect that `Class::getPermittedSubclasses` should do more work and return only the subclasses or subinterfaces permitted at runtime.

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

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

From mchung at openjdk.java.net  Tue Dec  1 00:55:01 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 1 Dec 2020 00:55:01 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
Message-ID: <tcJB-G9Vyxk4Jv5Yqd5OQLFfVTXivhj20RvU986opPw=.0f2f961f-363d-4626-b9d3-7e5e35ec7b09@github.com>

On Mon, 30 Nov 2020 15:59:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>> 
>> From the original PR:
>> 
>>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>>> 
>>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>>> 
>>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>>> 
>>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>>> 
>>>     * adding code to make sure that annotations can't be sealed
>>> 
>>>     * improving some tests
>>> 
>>> 
>>> TIA
>>> 
>>> Related specs:
>>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
>> 
>> This PR strives to reflect the review comments from 1227:
>>  * adjustments to javadoc of j.l.Class methods
>>  * package access checks in Class.getPermittedSubclasses()
>>  * fixed to the narrowing conversion/castability as pointed out by Maurizio
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Improving getPermittedSubclasses javadoc.
>  - Merge branch 'master' into JDK-8246778
>  - Moving checkPackageAccess from getPermittedSubclasses to a separate method.
>  - Improving getPermittedSubclasses() javadoc.
>  - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules.
>  - Removing unnecessary file.
>  - Tweaking javadoc.
>  - Reflecting review comments w.r.t. narrowing conversion.
>  - Improving checks in getPermittedSubclasses()
>  - Merging master into JDK-8246778
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179

test/hotspot/jtreg/runtime/sealedClasses/GetPermittedSubclassesTest.java line 54:

> 52:     public static void testSealedInfo(Class<?> c, String[] expected) {
> 53:         Object[] permitted = c.getPermittedSubclasses();
> 54: 

Why `permitted` is not `Class<?>[]`?  or simply `var permitted = ...`

test/hotspot/jtreg/runtime/sealedClasses/GetPermittedSubclassesTest.java line 69:

> 67:             for (int i = 0; i < permitted.length; i++) {
> 68:                 permittedNames.add(((Class)permitted[i]).getName());
> 69:             }

This cast is not needed if `permitted` is `var` or `Class<?>[]` type.

test/jdk/java/lang/reflect/sealed_classes/TestSecurityManagerChecks.java line 3:

> 1: /*
> 2:  * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved.
> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

the copyright start year should be 2020.

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

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

From jjg at openjdk.java.net  Tue Dec  1 02:21:02 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 1 Dec 2020 02:21:02 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v3]
In-Reply-To: <ZfeGVwwoe17k0ccnpt1oCaxL_SQ2D9OmOXAHn_R7QfU=.dfbbefa0-abd6-4c82-a7d0-ee05706a48ec@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
 <ZfeGVwwoe17k0ccnpt1oCaxL_SQ2D9OmOXAHn_R7QfU=.dfbbefa0-abd6-4c82-a7d0-ee05706a48ec@github.com>
Message-ID: <OwDTR-tYF8NbG6X212Nxeps-8S11SxIEGvTql3GtEhw=.2801cf40-648b-4fd5-99bd-5eb9138c9ecb@github.com>

On Mon, 30 Nov 2020 14:27:11 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
>> -updating and moving tests into test/langtools, so that it is easier to run them.
>> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
>> -fixing the -Xprint annotation processor to print record component annotations.
>> 
>> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing tests on Windows - normalizing line endings.

Looks mostly OK; some minor comments inline.

test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTest.java line 110:

> 108:                                               "--add-exports", "jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED",
> 109:                                               "--add-exports", "jdk.javadoc/jdk.javadoc.internal.api=ALL-UNNAMED",
> 110:                                               "--add-exports", "jdk.javadoc/jdk.javadoc.internal.tool=ALL-UNNAMED",

I'm surprised CreateSymbolsTest needs access to javadoc internals; is it because you're adding all of toolbox in lines 93, 94? Would it be better to filter out the classes you don't want to compile, such as `JavadocTask` and `JavapTask` ?

test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 54:

> 52: import java.util.Enumeration;
> 53: import java.util.jar.JarEntry;
> 54: import java.util.jar.JarFile;

weird order of imports

test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 238:

> 236:                            "t.Visible",
> 237:                            "package t;\n\n" +
> 238: //                           "@java.lang.annotation.Retention(java.lang.annotation.RetentionPolicy.RUNTIME)\n" + //XXX

Is this line still supposed to be here?

test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 270:

> 268:                            "t.Visible",
> 269:                            "package t;\n\n" +
> 270: //                           "@java.lang.annotation.Retention(java.lang.annotation.RetentionPolicy.RUNTIME)\n" + //XXX

Is this line still supposed to be here?

test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 307:

> 305:     }
> 306: 
> 307: //    @Test XXX

Another XXX line

test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 513:

> 511:                              public java.util.List<java.lang.String> l();
> 512:                            }
> 513:                            """,

I don't understand why the lines with `\n` in a text block

test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTest.java line 69:

> 67:             System.err.println("Warning: cannot find CreateSymbols, skipping.");
> 68:             return ;
> 69:         }

I can believe this test is worth just a warning, because you're trying to reach into the `make` directory, but the subsequent checks for `CreateSymbolsTestImpl.java` and `toolbox.*` seem worthy of errors, not warnings. On the other hand, I accept that all of these checks are very unlikely to fail, so maybe it doesn't matter.

test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTest.java line 30:

> 28:  * @modules java.compiler
> 29:  *          jdk.compiler
> 30:  *          jdk.javadoc

See related comments in code ... seems strange to need `jdk.javadoc`.

test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTest.java line 121:

> 119:         }
> 120: 
> 121:         URLClassLoader cl = new URLClassLoader(new URL[] {testClasses.toUri().toURL(), compileDir.toUri().toURL()});

line 132: the name of the local variable `createSymbols` seems more specific than the method might imply!

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

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

From david.holmes at oracle.com  Tue Dec  1 02:40:42 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 1 Dec 2020 12:40:42 +1000
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <IA94IwqxqI3TWPZcvjlHjKcgCiWzx490-uQgJoq2tj0=.e581e7cc-ddfc-4379-8bfa-6177628ab4bf@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
 <Q0QluOtDa_O6rcytLjro7EoDTvIUBgGNaBrTWaibg8M=.15d28b63-7381-404b-8ea2-2d7cc4f178de@github.com>
 <9cyMSNayyu63LkCt6r1Ltrzzv7TPvcsity5IYimZNa4=.f35daee0-3c52-4844-8354-d4b0507c57ff@github.com>
 <IA94IwqxqI3TWPZcvjlHjKcgCiWzx490-uQgJoq2tj0=.e581e7cc-ddfc-4379-8bfa-6177628ab4bf@github.com>
Message-ID: <d65d7417-94f4-3db3-f6ad-31f94332d6b2@oracle.com>

On 1/12/2020 10:39 am, Mandy Chung wrote:
> On Mon, 30 Nov 2020 20:57:32 GMT, Harold Seigel <hseigel at openjdk.org> wrote:
> 
>>> src/java.base/share/classes/java/lang/Class.java line 4480:
>>>
>>>> 4478:     }
>>>> 4479:
>>>> 4480:     private native Class<?>[] getPermittedSubclasses0();
>>>
>>> Does this JVM method return the permitted subclasses or subinterfaces with the following conditions enforced by JLS:
>>>
>>>     - If a sealed class C belongs to a named module, then every class named in the permits clause of the declaration of C must belong to the same module as C
>>>     - If a sealed class C belongs to an unnamed module, then every class named in the permits clause of the declaration of C must belong to the same package as C
>>>
>>> I didn't check the VM implementation.
>>>
>>> If the return array contains only classes as specified above, `checkPackageAccessForClasses` can be simplified.
>>
>> The JVM method that returns the permitted subclasses (and interfaces) does not weed out permitted subclasses based on the above module requirements.  It returns all the classes listed in the PermittedSubclasses attribute that it is able to load.
> 
> So it could also return a class listed in `PermittedSubclasses` attribute but not a subclass of this sealed class, right?
> 
> The specification of `Class::getPermittedSubclasses` says:
> 
>> Returns an array containing {@code Class} objects representing the direct subclasses or direct implementation classes permitted to extend or direct subinterfaces or subclasses permitted to extend or implement this class or interface if it is sealed.
> 
> I expect that `Class::getPermittedSubclasses` should do more work and return only the subclasses or subinterfaces permitted at runtime.

These subtleties are what I was also getting at in the CSR discussion. 
If Foo lists Bar as a permitted subtype, but Bar does not extend Foo, is 
that an error? Should Bar not be returned by getPermittedSubclasses? The 
answer depends on exactly how you specify getPermittedSubclasses() and 
whether that aligns with reading the classfile attribute, or actually 
checking the runtime relationships.

David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1483
> 

From joe.darcy at oracle.com  Tue Dec  1 06:35:10 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 30 Nov 2020 22:35:10 -0800
Subject: CSR review review for start of JDK 17 changes, JDK-8257451 &
 JDK-8257453
Message-ID: <ff6bb040-cbba-72cc-e5ee-925ac106833f@oracle.com>

Hello,

Please review the start-of-JDK-17 CSRs for:

 ??? JDK-8257451: Add SourceVersion.RELEASE_17
 ??? https://bugs.openjdk.java.net/browse/JDK-8257452

 ??? JDK-8257453: Add source 17 and target 17 to javac
 ??? https://bugs.openjdk.java.net/browse/JDK-8257454

In-progress versions of these changes can be found in the draft PR

 ??? https://github.com/openjdk/jdk/pull/1531

Thanks,

-Joe


From jlahoda at openjdk.java.net  Tue Dec  1 11:18:11 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 1 Dec 2020 11:18:11 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v4]
In-Reply-To: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
Message-ID: <U3ej9FB3f8Wl4FUWDdoOfudJkzvCJHHMBAV0OllsQ0Y=.85f9098f-18aa-4911-8708-fd4790a87fcc@github.com>

> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
> -updating and moving tests into test/langtools, so that it is easier to run them.
> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
> -fixing the -Xprint annotation processor to print record component annotations.
> 
> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.

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

  Reflecting review comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1480/files
  - new: https://git.openjdk.java.net/jdk/pull/1480/files/a3f79aba..9ab7153a

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

  Stats: 28 lines in 2 files changed: 5 ins; 11 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1480.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1480/head:pull/1480

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

From jlahoda at openjdk.java.net  Tue Dec  1 12:08:58 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 1 Dec 2020 12:08:58 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v3]
In-Reply-To: <OwDTR-tYF8NbG6X212Nxeps-8S11SxIEGvTql3GtEhw=.2801cf40-648b-4fd5-99bd-5eb9138c9ecb@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
 <ZfeGVwwoe17k0ccnpt1oCaxL_SQ2D9OmOXAHn_R7QfU=.dfbbefa0-abd6-4c82-a7d0-ee05706a48ec@github.com>
 <OwDTR-tYF8NbG6X212Nxeps-8S11SxIEGvTql3GtEhw=.2801cf40-648b-4fd5-99bd-5eb9138c9ecb@github.com>
Message-ID: <AoKBfvbBw_pm22ChROZMWUw4rmQqD4PnzVwiUeB4Zqw=.b3e3d000-d189-4c82-b541-e511969e8a05@github.com>

On Tue, 1 Dec 2020 01:43:47 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing tests on Windows - normalizing line endings.
>
> test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 513:
> 
>> 511:                              public java.util.List<java.lang.String> l();
>> 512:                            }
>> 513:                            """,
> 
> I don't understand why the lines with `\n` in a text block

There is a combination of factors here:
-jcheck (AFAIK) does not allow trailing whitespaces, even not on otherwise empty lines inside textblocks
-textblocks only remove indentation that is common on all lines.

So, without having '\n', we would have to strip all the whitespace on the empty lines (to pass jcheck), which would mean the text block's content would no longer match the output. There are a few ways to solve this (almost surely an incomplete list):
-do some trick to have the common indent, but no trailing whitespace. '\n' is one of them.
-not indent the text block
-do some post-processing on the text block's value or the actual test output, to make them match
-not use textblocks

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

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

From jlahoda at openjdk.java.net  Tue Dec  1 12:13:56 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 1 Dec 2020 12:13:56 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v3]
In-Reply-To: <OwDTR-tYF8NbG6X212Nxeps-8S11SxIEGvTql3GtEhw=.2801cf40-648b-4fd5-99bd-5eb9138c9ecb@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
 <ZfeGVwwoe17k0ccnpt1oCaxL_SQ2D9OmOXAHn_R7QfU=.dfbbefa0-abd6-4c82-a7d0-ee05706a48ec@github.com>
 <OwDTR-tYF8NbG6X212Nxeps-8S11SxIEGvTql3GtEhw=.2801cf40-648b-4fd5-99bd-5eb9138c9ecb@github.com>
Message-ID: <ojnncDORSwm7P2PAdPgcQmUDW0IK7kb5L943h_aVo6o=.4c527c1c-4402-4fe6-94f3-678a0b843858@github.com>

On Tue, 1 Dec 2020 02:18:18 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing tests on Windows - normalizing line endings.
>
> Looks mostly OK; some minor comments inline.

Thanks for the comments Jon! I've tried to resolve them here:
https://github.com/openjdk/jdk/pull/1480/commits/9ab7153a4f301dc77c02dd1ffda247cf7cdeb5ea

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Dec  1 12:24:12 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 1 Dec 2020 12:24:12 GMT
Subject: RFR: 8257037: No javac warning when calling deprecated
 constructor with diamond [v3]
In-Reply-To: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
References: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
Message-ID: <KLBpBEBHPnq3e5TGBSm4KGHlLBoUgXYHKhAdy-DVYO8=.5621051e-5829-4a4e-99bf-a2264aa0af6c@github.com>

> Hi all,
> 
> When calling deprecated constructor with diamond, the compiler doesn't output warning.
> The test case is shown below.
> 
> GenericClass<Object> o2 = new GenericClass<>();
> 
> public class GenericClass<T> {
>     @Deprecated
>     public GenericClass() {}
> }
> 
> This patch solves the bug and adds corresponding test case.
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Check @Deprecated annotation in method Attr.checkIdInternal. Remove the redundant warning code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1490/files
  - new: https://git.openjdk.java.net/jdk/pull/1490/files/1d2a73c5..66671b02

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

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

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

From chegar at openjdk.java.net  Tue Dec  1 12:35:58 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 1 Dec 2020 12:35:58 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v4]
In-Reply-To: <U3ej9FB3f8Wl4FUWDdoOfudJkzvCJHHMBAV0OllsQ0Y=.85f9098f-18aa-4911-8708-fd4790a87fcc@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
 <U3ej9FB3f8Wl4FUWDdoOfudJkzvCJHHMBAV0OllsQ0Y=.85f9098f-18aa-4911-8708-fd4790a87fcc@github.com>
Message-ID: <LV5hG7uuNjTrASTJz8Csj7zajJ1aNFUtwZN3LxK4ilw=.fd64c5b0-3730-4713-a226-f1a92688c0ff@github.com>

On Tue, 1 Dec 2020 11:18:11 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
>> -updating and moving tests into test/langtools, so that it is easier to run them.
>> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
>> -fixing the -Xprint annotation processor to print record component annotations.
>> 
>> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comments.

Marked as reviewed by chegar (Reviewer).

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

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

From jlahoda at openjdk.java.net  Tue Dec  1 16:51:56 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 1 Dec 2020 16:51:56 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <IA94IwqxqI3TWPZcvjlHjKcgCiWzx490-uQgJoq2tj0=.e581e7cc-ddfc-4379-8bfa-6177628ab4bf@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
 <Q0QluOtDa_O6rcytLjro7EoDTvIUBgGNaBrTWaibg8M=.15d28b63-7381-404b-8ea2-2d7cc4f178de@github.com>
 <9cyMSNayyu63LkCt6r1Ltrzzv7TPvcsity5IYimZNa4=.f35daee0-3c52-4844-8354-d4b0507c57ff@github.com>
 <IA94IwqxqI3TWPZcvjlHjKcgCiWzx490-uQgJoq2tj0=.e581e7cc-ddfc-4379-8bfa-6177628ab4bf@github.com>
Message-ID: <yxngqSiOzbWQDFiyWkER5dRIIlbFgj9Jsf-Zkg8HH70=.03c06733-0af5-4049-aaca-9723905a44b1@github.com>

On Tue, 1 Dec 2020 00:36:54 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> The JVM method that returns the permitted subclasses (and interfaces) does not weed out permitted subclasses based on the above module requirements.  It returns all the classes listed in the PermittedSubclasses attribute that it is able to load.
>
> So it could also return a class listed in `PermittedSubclasses` attribute but not a subclass of this sealed class, right?
> 
> The specification of `Class::getPermittedSubclasses` says:
> 
>> Returns an array containing {@code Class} objects representing the direct subclasses or direct implementation classes permitted to extend or direct subinterfaces or subclasses permitted to extend or implement this class or interface if it is sealed. 
> 
> I expect that `Class::getPermittedSubclasses` should do more work and return only the subclasses or subinterfaces permitted at runtime.

I was investigating a little today. One thing to note is that there is a difference between the JLS and JVMS[1] restrictions - the JVMS restrictions only require the classes to be in the same module, but they can be in any package (even for an unnamed module).

Moreover, a lot of the constraints are checked automatically: e.g. consider class api.Api in module "a", which permits impl.Impl in module "b", subtyping Api. Loading of impl.Impl on behalf of getPermittedSubclasses() will fail (because the two classes are in different modules). So impl.Impl will not be included.

So far, it seems the only constraint that I think is not satisfied by this implicit loading is that the permitted subclass is really a direct subtype of the current class.

My proposal is to enhance the Java method with the direct subtype check (with a possible future cleanup task to move the check to native, as is done for getNestMembers()). 

[1] http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html#jvms-5.3.5

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

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

From prappo at openjdk.java.net  Tue Dec  1 17:11:55 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 1 Dec 2020 17:11:55 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations.
In-Reply-To: <uf_6tcbpe0dLHA39qxAIGEgXb_VYKnfAANdGOLZOvQs=.e96cefa3-4deb-4a5f-ac7f-975b91fd8a1e@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
 <uf_6tcbpe0dLHA39qxAIGEgXb_VYKnfAANdGOLZOvQs=.e96cefa3-4deb-4a5f-ac7f-975b91fd8a1e@github.com>
Message-ID: <CUEB3J-W10h-QXmNang8FidRvp86egN-p5N3V0P85Ks=.50cd30f4-7575-4837-b3db-c2ebe2cb4e08@github.com>

On Fri, 27 Nov 2020 16:33:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description.
>> 
>> The goal is to be able to simplify the following common pattern:
>> 
>>     /**
>>      * Returns the result. Optional additional text.
>>      * @return the result
>>      */
>>     int method() { 
>> 
>> by 
>> 
>>     /**
>>      * {@return the result} Optional additional text.
>>      */
>>     int method() { 
>> 
>> Note:
>> 
>> * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere.
>> * The expansion of the inline tag is `Returns " _content_ `.`  where _content_ is the content of the tag. 
>> * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description
>> * The inline tag can be inherited into overriding methods as if it was provided as a block tag.
>
> /**
>   * {@return the result} Optional additional text.
>   */
>  ```
> The java source looks a bit odd/unusual because the "first sentence" does not appear to end with a period.
> Though it seems like a convenience to include the '.' in the expansion, the source might be clearer if it did not, as in:
> /**
>   * {@return the result}. Optional additional text.
>   */ 
> Similarly, prepending the "Returns", forces the verb, which is conventional but always the most appropriate word.
> Changing the expansion to be only the contents of @ return would allow more flexible use.
> It would put more responsibility on the developer to form the first sentence. (With "Returns"... and the "." outside the tag.

@RogerRiggs ,

1. I agree on that the lack of `.` after `}` looks unnatural:

/**
 * {@return the result} Optional additional text.
 */
int method() { 

2. I disagree on allowing a flexible expansion. This enhancement aims to support a very particular case of redundancy in doc comments. I believe that the proportion of redundant doc comments that use some other verb (instead of "Return(s)") is smaller than it needs to be to support the increase in tag's complexity.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Dec  1 21:08:57 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 1 Dec 2020 21:08:57 GMT
Subject: Integrated: 8255968: Confusing error message for inaccessible
 constructor
In-Reply-To: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
References: <Gt2JaUvb7Hw-l2EZ6mDGbGGZRz7cyJT8CiLIp52Djek=.aa43f072-5391-461f-8ffa-8429f5ade554@github.com>
Message-ID: <EvpP5GJK3CV0LwtEbYTa8EA9N9d8zkTcGygNiIdjFTo=.c6c99bf6-7fe9-47fc-a5bf-f6f80b03aca2@github.com>

On Mon, 23 Nov 2020 15:22:26 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> When using inaccessible constructor, compiler would output some confusing error message occasionally. These confusing error message is related to the constructor order. See [JDK-8255968](https://bugs.openjdk.java.net/browse/JDK-8255968) for more information.
> This patch solves this bug, regardless of the construction order, compiler can always output expected message.
> Thank you for taking the time to review.
> 
> Best Regards.

This pull request has now been integrated.

Changeset: 29d90b95
Author:    Guoxiong Li <lgxbslgx at gmail.com>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/29d90b95
Stats:     715 lines in 31 files changed: 712 ins; 0 del; 3 mod

8255968: Confusing error message for inaccessible constructor

Reviewed-by: mcimadamore

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

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

From mcimadamore at openjdk.java.net  Tue Dec  1 21:10:55 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 1 Dec 2020 21:10:55 GMT
Subject: RFR: 8257037: No javac warning when calling deprecated
 constructor with diamond [v2]
In-Reply-To: <NqTbEGQXGYXlBxBC0_3Alw-IXhhputmHK1dUOVxLZjk=.45b3870a-85c4-4916-bf60-2a0650223b7d@github.com>
References: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
 <1U2EbJB1lDsbvdq9BmjwSmKaX0uXBapxvXC8ZiCkQj8=.f9a2cd1d-0870-488a-bf0d-7cedef2a3ec0@github.com>
 <zVIqNvzBoibgKiouyfuWtVVlKZ1QdVKwT3Ogcponqks=.5a22a17f-7a26-4826-9d80-27bc4c205fde@github.com>
 <NqTbEGQXGYXlBxBC0_3Alw-IXhhputmHK1dUOVxLZjk=.45b3870a-85c4-4916-bf60-2a0650223b7d@github.com>
Message-ID: <ke-vuOhulPGGdca1vg_kJK4wTSVBZKMLBFpw-8yVulE=.e22c36b3-fad5-473c-bf9f-6163e5c88e3c@github.com>

On Mon, 30 Nov 2020 16:00:42 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>  Is the code `newConstr.setAttributes(sym);` necessary in `Resolve.findDiamond`?

Sorry, that was a leftover from a previous experiment. That's not necessary. We'll run some more tests on our side and I'll let you know.

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

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

From mchung at openjdk.java.net  Tue Dec  1 23:21:56 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 1 Dec 2020 23:21:56 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
Message-ID: <fJl0fs6rLPbW9t5heBPN2tjIuJOe92pGvTkkgRYurZw=.4e0c983b-093d-4a5d-8f2d-3764db94af4f@github.com>

On Fri, 27 Nov 2020 16:57:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
> 
> From the original PR:
> 
>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>> 
>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>> 
>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>> 
>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>> 
>>     * adding code to make sure that annotations can't be sealed
>> 
>>     * improving some tests
>> 
>> 
>> TIA
>> 
>> Related specs:
>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
> 
> This PR strives to reflect the review comments from 1227:
>  * adjustments to javadoc of j.l.Class methods
>  * package access checks in Class.getPermittedSubclasses()
>  * fixed to the narrowing conversion/castability as pointed out by Maurizio

>From David's comment:

> These subtleties are what I was also getting at in the CSR discussion. If Foo lists Bar as a permitted subtype, but Bar does not extend Foo, is that an error? Should Bar not be returned by getPermittedSubclasses? The answer depends on exactly how you specify getPermittedSubclasses() and whether that aligns with reading the classfile attribute, or actually checking the runtime relationships. 

As I read the current spec of `Class::getPermittedSubclasses`, it intends to return the direct subclasses or subinterfaces permitted to extend or implement this class or interface if it's sealed.   If not, it should be clarified that it is the class file view.

`NestMembers` and `PermittedSubclasses` attributes are critical to correct interpretation of the class file by JVM.   Prior to these two attributes, the attributes inspected by core reflection APIs are all non-critical.  API like `Class::getDeclaringClass` reads `InnerClasses` attribute if present in order to determine its declaring class but the current spec does not specify the behavior on error cases (which I consider a spec bug - see JDK-8250226.)

IMO it is reasonable for `getPermittedSubclasses` (and `getNestMembers` and `getNestHost`) to return the runtime view as it returns `Class` objects since these attributes are critical to correct interpretation of the class file.  It would be confusing if it returns `Foo` that is not a permitted subtype at runtime.

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

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

From mchung at openjdk.java.net  Tue Dec  1 23:21:58 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 1 Dec 2020 23:21:58 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <yxngqSiOzbWQDFiyWkER5dRIIlbFgj9Jsf-Zkg8HH70=.03c06733-0af5-4049-aaca-9723905a44b1@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
 <Q0QluOtDa_O6rcytLjro7EoDTvIUBgGNaBrTWaibg8M=.15d28b63-7381-404b-8ea2-2d7cc4f178de@github.com>
 <9cyMSNayyu63LkCt6r1Ltrzzv7TPvcsity5IYimZNa4=.f35daee0-3c52-4844-8354-d4b0507c57ff@github.com>
 <IA94IwqxqI3TWPZcvjlHjKcgCiWzx490-uQgJoq2tj0=.e581e7cc-ddfc-4379-8bfa-6177628ab4bf@github.com>
 <yxngqSiOzbWQDFiyWkER5dRIIlbFgj9Jsf-Zkg8HH70=.03c06733-0af5-4049-aaca-9723905a44b1@github.com>
Message-ID: <wimsNlGGcUWUYbvNCSHWKHPsTw9FrvNsO9gy_vKWoVw=.44fa91e2-c86b-46c8-b8f5-d83fc212aca6@github.com>

On Tue, 1 Dec 2020 16:49:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> So it could also return a class listed in `PermittedSubclasses` attribute but not a subclass of this sealed class, right?
>> 
>> The specification of `Class::getPermittedSubclasses` says:
>> 
>>> Returns an array containing {@code Class} objects representing the direct subclasses or direct implementation classes permitted to extend or direct subinterfaces or subclasses permitted to extend or implement this class or interface if it is sealed. 
>> 
>> I expect that `Class::getPermittedSubclasses` should do more work and return only the subclasses or subinterfaces permitted at runtime.
>
> I was investigating a little today. One thing to note is that there is a difference between the JLS and JVMS[1] restrictions - the JVMS restrictions only require the classes to be in the same module, but they can be in any package (even for an unnamed module).
> 
> Moreover, a lot of the constraints are checked automatically: e.g. consider class api.Api in module "a", which permits impl.Impl in module "b", subtyping Api. Loading of impl.Impl on behalf of getPermittedSubclasses() will fail (because the two classes are in different modules). So impl.Impl will not be included.
> 
> So far, it seems the only constraint that I think is not satisfied by this implicit loading is that the permitted subclass is really a direct subtype of the current class.
> 
> My proposal is to enhance the Java method with the direct subtype check (with a possible future cleanup task to move the check to native, as is done for getNestMembers()). 
> 
> [1] http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html#jvms-5.3.5

@lahodaj  It is okay with me if `getPermittedSubclasses` returns the permitted subtypes matching the runtime view (that matches the current specification to me) and revisit this API as a follow up.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Wed Dec  2 05:15:11 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Wed, 2 Dec 2020 05:15:11 GMT
Subject: RFR: 8245956: JavaCompiler still uses files API instead of Path API
 in a specific case
Message-ID: <dQCLUalaPhBxjTKrvGIY6c4d9m5HBRQfRu0QuoMUokM=.de840fae-cf05-4f95-9cc3-edf7646046ed@github.com>

Hi all,

`JavacFileManager.getClassLoader` uses `getLocation` which causes exception in some situations.
This patch uses `getLocationAsPaths` instead of `getLocation` to solve it.
Thanks you for taking the time to review.

Best Regards.

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

Commit messages:
 - 8245956: JavaCompiler still uses files API instead of Path API in a specific case

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Wed Dec  2 07:32:54 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Wed, 2 Dec 2020 07:32:54 GMT
Subject: RFR: 8257037: No javac warning when calling deprecated
 constructor with diamond [v2]
In-Reply-To: <ke-vuOhulPGGdca1vg_kJK4wTSVBZKMLBFpw-8yVulE=.e22c36b3-fad5-473c-bf9f-6163e5c88e3c@github.com>
References: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
 <1U2EbJB1lDsbvdq9BmjwSmKaX0uXBapxvXC8ZiCkQj8=.f9a2cd1d-0870-488a-bf0d-7cedef2a3ec0@github.com>
 <zVIqNvzBoibgKiouyfuWtVVlKZ1QdVKwT3Ogcponqks=.5a22a17f-7a26-4826-9d80-27bc4c205fde@github.com>
 <NqTbEGQXGYXlBxBC0_3Alw-IXhhputmHK1dUOVxLZjk=.45b3870a-85c4-4916-bf60-2a0650223b7d@github.com>
 <ke-vuOhulPGGdca1vg_kJK4wTSVBZKMLBFpw-8yVulE=.e22c36b3-fad5-473c-bf9f-6163e5c88e3c@github.com>
Message-ID: <WR_QKJfV0sa3_ogol7r-FddlVPGNvwtZbAnYCAYuLpE=.c103480d-5aa8-4782-8922-2f1489860c19@github.com>

On Tue, 1 Dec 2020 21:08:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Thank you for the comment and suggestion.
>> 
>> I had seen and paid attention to the following code in `Attr.java` when being solved this bug.
>> 
>>             // (for constructors (but not for constructor references), the error
>>             // was given when the constructor was resolved)
>> 
>>             if (sym.name != names.init || tree.hasTag(REFERENCE)) {
>>                 chk.checkDeprecated(tree.pos(), env.info.scope.owner, sym);
>>                 chk.checkSunAPI(tree.pos(), sym);
>>                 chk.checkProfile(tree.pos(), sym);
>>                 chk.checkPreview(tree.pos(), sym);
>>             }
>> 
>> These code confused me. Because the comments `(for constructors, the error was given when the constructor was resolved)`  and the conditional expression `sym.name != names.init` were submitted at 2007(submit log: Initial load). And nobody raises suggestion to it over these years though this code snippet had been revised many times.
>> 
>> In order not to generate unknown issues, I chose not to revise these code when being solved this bug.
>> 
>> @mcimadamore  I test your patch locally by using the following command. All the tests passed.
>> 
>> make test TEST="jtreg:langtools/tools/javac" CONF=linux-x86_64-server-release
>> 
>> Your patch is a better solution if no any unknown regression occurs. But I have no idea about the unknown regressions now.
>> I would like to accept your suggestion and revise my code. **And we should think more situations which could generate regressions to avoid unknown issues occur.**
>> 
>> ----
>> Finally, I have a little question.
>> Is the code `newConstr.setAttributes(sym);` necessary in `Resolve.findDiamond`?
>> I delete it in your patch, and test locally by using  the following command. All the tests passed.
>> 
>> make test TEST="jtreg:langtools/tools/javac" CONF=linux-x86_64-server-release
>
>>  Is the code `newConstr.setAttributes(sym);` necessary in `Resolve.findDiamond`?
> 
> Sorry, that was a leftover from a previous experiment. That's not necessary. We'll run some more tests on our side and I'll let you know.

@mcimadamore Should I add you as a contributor of this patch? Does it need another reviewer to review if I add you as a contributor?

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

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

From alanb at openjdk.java.net  Wed Dec  2 12:10:54 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 2 Dec 2020 12:10:54 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <wimsNlGGcUWUYbvNCSHWKHPsTw9FrvNsO9gy_vKWoVw=.44fa91e2-c86b-46c8-b8f5-d83fc212aca6@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
 <Q0QluOtDa_O6rcytLjro7EoDTvIUBgGNaBrTWaibg8M=.15d28b63-7381-404b-8ea2-2d7cc4f178de@github.com>
 <9cyMSNayyu63LkCt6r1Ltrzzv7TPvcsity5IYimZNa4=.f35daee0-3c52-4844-8354-d4b0507c57ff@github.com>
 <IA94IwqxqI3TWPZcvjlHjKcgCiWzx490-uQgJoq2tj0=.e581e7cc-ddfc-4379-8bfa-6177628ab4bf@github.com>
 <yxngqSiOzbWQDFiyWkER5dRIIlbFgj9Jsf-Zkg8HH70=.03c06733-0af5-4049-aaca-9723905a44b1@github.com>
 <wimsNlGGcUWUYbvNCSHWKHPsTw9FrvNsO9gy_vKWoVw=.44fa91e2-c86b-46c8-b8f5-d83fc212aca6@github.com>
Message-ID: <E1Pr-73V62dkhLZeug-5Qv4Bh749ZZ0uXHkZqOc_WIE=.145b0d9a-fdf2-4cb1-a469-0d689cfbe625@github.com>

On Tue, 1 Dec 2020 23:19:41 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> I was investigating a little today. One thing to note is that there is a difference between the JLS and JVMS[1] restrictions - the JVMS restrictions only require the classes to be in the same module, but they can be in any package (even for an unnamed module).
>> 
>> Moreover, a lot of the constraints are checked automatically: e.g. consider class api.Api in module "a", which permits impl.Impl in module "b", subtyping Api. Loading of impl.Impl on behalf of getPermittedSubclasses() will fail (because the two classes are in different modules). So impl.Impl will not be included.
>> 
>> So far, it seems the only constraint that I think is not satisfied by this implicit loading is that the permitted subclass is really a direct subtype of the current class.
>> 
>> My proposal is to enhance the Java method with the direct subtype check (with a possible future cleanup task to move the check to native, as is done for getNestMembers()). 
>> 
>> [1] http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html#jvms-5.3.5
>
> @lahodaj  It is okay with me if `getPermittedSubclasses` returns the permitted subtypes matching the runtime view (that matches the current specification to me) and revisit this API as a follow up.

Yes, would be a surprise if getPermittedSubclasses returned Class objects for classes that are not subclasses. I think it should be okay to separate that out to a separate issue so that it can be further re-examined after JEP 397 goes in.

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

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

From jlahoda at openjdk.java.net  Wed Dec  2 12:13:54 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 2 Dec 2020 12:13:54 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <E1Pr-73V62dkhLZeug-5Qv4Bh749ZZ0uXHkZqOc_WIE=.145b0d9a-fdf2-4cb1-a469-0d689cfbe625@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
 <Q0QluOtDa_O6rcytLjro7EoDTvIUBgGNaBrTWaibg8M=.15d28b63-7381-404b-8ea2-2d7cc4f178de@github.com>
 <9cyMSNayyu63LkCt6r1Ltrzzv7TPvcsity5IYimZNa4=.f35daee0-3c52-4844-8354-d4b0507c57ff@github.com>
 <IA94IwqxqI3TWPZcvjlHjKcgCiWzx490-uQgJoq2tj0=.e581e7cc-ddfc-4379-8bfa-6177628ab4bf@github.com>
 <yxngqSiOzbWQDFiyWkER5dRIIlbFgj9Jsf-Zkg8HH70=.03c06733-0af5-4049-aaca-9723905a44b1@github.com>
 <wimsNlGGcUWUYbvNCSHWKHPsTw9FrvNsO9gy_vKWoVw=.44fa91e2-c86b-46c8-b8f5-d83fc212aca6@github.com>
 <E1Pr-73V62dkhLZeug-5Qv4Bh749ZZ0uXHkZqOc_WIE=.145b0d9a-fdf2-4cb1-a469-0d689cfbe625@github.com>
Message-ID: <EW835zxOB-kXVRrRDg5jrqLKlpEygniTtd2M7H1m_ZE=.032fd117-b0e3-4dec-acde-f323cf937248@github.com>

On Wed, 2 Dec 2020 12:08:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @lahodaj  It is okay with me if `getPermittedSubclasses` returns the permitted subtypes matching the runtime view (that matches the current specification to me) and revisit this API as a follow up.
>
> Yes, would be a surprise if getPermittedSubclasses returned Class objects for classes that are not subclasses. I think it should be okay to separate that out to a separate issue so that it can be further re-examined after JEP 397 goes in.

FWIW: I plan to change the method to not return such Class objects. It just will do the verification in Java, while for getNestMembers it is done in native. The follow up is for investigate the possibility of making the internal behavior consistent with how getNestMembers work.

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

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

From mcimadamore at openjdk.java.net  Wed Dec  2 12:17:55 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 2 Dec 2020 12:17:55 GMT
Subject: RFR: 8257037: No javac warning when calling deprecated
 constructor with diamond [v2]
In-Reply-To: <ke-vuOhulPGGdca1vg_kJK4wTSVBZKMLBFpw-8yVulE=.e22c36b3-fad5-473c-bf9f-6163e5c88e3c@github.com>
References: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
 <1U2EbJB1lDsbvdq9BmjwSmKaX0uXBapxvXC8ZiCkQj8=.f9a2cd1d-0870-488a-bf0d-7cedef2a3ec0@github.com>
 <zVIqNvzBoibgKiouyfuWtVVlKZ1QdVKwT3Ogcponqks=.5a22a17f-7a26-4826-9d80-27bc4c205fde@github.com>
 <NqTbEGQXGYXlBxBC0_3Alw-IXhhputmHK1dUOVxLZjk=.45b3870a-85c4-4916-bf60-2a0650223b7d@github.com>
 <ke-vuOhulPGGdca1vg_kJK4wTSVBZKMLBFpw-8yVulE=.e22c36b3-fad5-473c-bf9f-6163e5c88e3c@github.com>
Message-ID: <Crrqea3jLo_w2Ewqvv7dPRGdni2RaqduZQq1GC-pOHc=.bfd96ad5-a12d-43b0-9422-cf596461eda7@github.com>

On Tue, 1 Dec 2020 21:08:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Thank you for the comment and suggestion.
>> 
>> I had seen and paid attention to the following code in `Attr.java` when being solved this bug.
>> 
>>             // (for constructors (but not for constructor references), the error
>>             // was given when the constructor was resolved)
>> 
>>             if (sym.name != names.init || tree.hasTag(REFERENCE)) {
>>                 chk.checkDeprecated(tree.pos(), env.info.scope.owner, sym);
>>                 chk.checkSunAPI(tree.pos(), sym);
>>                 chk.checkProfile(tree.pos(), sym);
>>                 chk.checkPreview(tree.pos(), sym);
>>             }
>> 
>> These code confused me. Because the comments `(for constructors, the error was given when the constructor was resolved)`  and the conditional expression `sym.name != names.init` were submitted at 2007(submit log: Initial load). And nobody raises suggestion to it over these years though this code snippet had been revised many times.
>> 
>> In order not to generate unknown issues, I chose not to revise these code when being solved this bug.
>> 
>> @mcimadamore  I test your patch locally by using the following command. All the tests passed.
>> 
>> make test TEST="jtreg:langtools/tools/javac" CONF=linux-x86_64-server-release
>> 
>> Your patch is a better solution if no any unknown regression occurs. But I have no idea about the unknown regressions now.
>> I would like to accept your suggestion and revise my code. **And we should think more situations which could generate regressions to avoid unknown issues occur.**
>> 
>> ----
>> Finally, I have a little question.
>> Is the code `newConstr.setAttributes(sym);` necessary in `Resolve.findDiamond`?
>> I delete it in your patch, and test locally by using  the following command. All the tests passed.
>> 
>> make test TEST="jtreg:langtools/tools/javac" CONF=linux-x86_64-server-release
>
>>  Is the code `newConstr.setAttributes(sym);` necessary in `Resolve.findDiamond`?
> 
> Sorry, that was a leftover from a previous experiment. That's not necessary. We'll run some more tests on our side and I'll let you know.

> @mcimadamore Should I add you as a contributor of this patch? Does it need another reviewer to review if I add you as a contributor?

As you prefer - I don't mind either way. I don't think adding me as a contributor should prevent the integration, or me being able to sponsor, but I'm not 100% sure.

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

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

From chegar at openjdk.java.net  Wed Dec  2 12:39:59 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 2 Dec 2020 12:39:59 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <EW835zxOB-kXVRrRDg5jrqLKlpEygniTtd2M7H1m_ZE=.032fd117-b0e3-4dec-acde-f323cf937248@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
 <Q0QluOtDa_O6rcytLjro7EoDTvIUBgGNaBrTWaibg8M=.15d28b63-7381-404b-8ea2-2d7cc4f178de@github.com>
 <9cyMSNayyu63LkCt6r1Ltrzzv7TPvcsity5IYimZNa4=.f35daee0-3c52-4844-8354-d4b0507c57ff@github.com>
 <IA94IwqxqI3TWPZcvjlHjKcgCiWzx490-uQgJoq2tj0=.e581e7cc-ddfc-4379-8bfa-6177628ab4bf@github.com>
 <yxngqSiOzbWQDFiyWkER5dRIIlbFgj9Jsf-Zkg8HH70=.03c06733-0af5-4049-aaca-9723905a44b1@github.com>
 <wimsNlGGcUWUYbvNCSHWKHPsTw9FrvNsO9gy_vKWoVw=.44fa91e2-c86b-46c8-b8f5-d83fc212aca6@github.com>
 <E1Pr-73V62dkhLZeug-5Qv4Bh749ZZ0uXHkZqOc_WIE=.145b0d9a-fdf2-4cb1-a469-0d689cfbe625@github.com>
 <EW835zxOB-kXVRrRDg5jrqLKlpEygniTtd2M7H1m_ZE=.032fd117-b0e3-4dec-acde-f323cf937248@github.com>
Message-ID: <n1Oea5YSfcYc9CZG89WmqP6mYuTpUBVUPJAao29aL6g=.58f878e1-7e2d-46f2-bb68-7b8e927d9eb7@github.com>

On Wed, 2 Dec 2020 12:11:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Yes, would be a surprise if getPermittedSubclasses returned Class objects for classes that are not subclasses. I think it should be okay to separate that out to a separate issue so that it can be further re-examined after JEP 397 goes in.
>
> FWIW: I plan to change the method to not return such Class objects. It just will do the verification in Java, while for getNestMembers it is done in native. The follow up is for investigate the possibility of making the internal behavior consistent with how getNestMembers work.

For the record: similar/related questions/comments have been made on a-s-e [1][2]. The questions/comments were made in order to clarify the JVMS specification, so as to better inform what responsibilities are part Core Reflection versus what are part of the VM.

[1] https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-October/002626.html
[2] https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-November/002660.html

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

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

From joel.p.borggren-franck at oracle.com  Wed Dec  2 14:11:35 2020
From: joel.p.borggren-franck at oracle.com (=?UTF-8?Q?Joel_Borggr=c3=a9n-Franck?=)
Date: Wed, 2 Dec 2020 15:11:35 +0100
Subject: Spec clarification, where are annotations without @Target
 applicable?
In-Reply-To: <CAJYRO=4-ZwtO2RcdDN3Os_2g57oztaBOnwpEHzLtnJ8Ay-YLXA@mail.gmail.com>
References: <3fa4dbc0-cd73-b606-66a0-820852147bf3@oracle.com>
 <5741F31D-9589-4538-A0D8-9A27C929F194@oracle.com>
 <CAJYRO=4-ZwtO2RcdDN3Os_2g57oztaBOnwpEHzLtnJ8Ay-YLXA@mail.gmail.com>
Message-ID: <9ef2a980-6029-b551-ae2e-f5129af25e22@oracle.com>

Hi,

Thanks for the background Werner. I'm very sympathetic to the idea of 
not having to answer this kind of question again but it seems we are not 
yet there with two competing normative specifications and a reference 
implementation that implements neither.

Short term (Java 16) it makes sense to fix 
https://bugs.openjdk.java.net/browse/JDK-8254023 given that both 
competing specs agree for this case, it is a small fix, and externally 
found.

For Java 17 we should align both specs and the reference implementation 
one way or another.

cheers
/Joel

On 2020-10-19 15:11, Werner Dietl wrote:
> I think this is a relevant discussion:
>
> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-August/013666.html 
> <https://mail.openjdk.java.net/pipermail/compiler-dev/2019-August/013666.html> 
>
> https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013715.html 
> <https://mail.openjdk.java.net/pipermail/compiler-dev/2019-September/013715.html>
>
> cu, WMD.
>
> On Mon, Oct 19, 2020 at 6:34 AM Brian Goetz <brian.goetz at oracle.com 
> <mailto:brian.goetz at oracle.com>> wrote:
>
>     The JLS 13 text seems right to me.? The ambiguity between deco and
>     type contexts makes ?all contexts? problematic.? I don?t recall
>     this change as a ?decision?.
>
>     Sent from my iPad
>
>     > On Oct 19, 2020, at 5:49 AM, Joel Borggr?n-Franck
>     <joel.p.borggren-franck at oracle.com
>     <mailto:joel.p.borggren-franck at oracle.com>> wrote:
>     >
>     > ?Hello JLS experts,
>     >
>     > When reviewing the proposed fix for annotations not being
>     applicable to modules by default [3] I noticed that the Javadoc
>     [1] and JLS wording [2] for which annotation contexts are
>     applicable by default have diverged since Java 14. The javaoc for
>     j.l.a.Target keeps the old wording:
>     >
>     > "If an @Target meta-annotation is not present on an annotation
>     type T, then an annotation of type T may be written as a modifier
>     for any declaration except a type parameter declaration."
>     >
>     > While the JLS since 14 states:
>     >
>     > "If an annotation of type java.lang.annotation.Target is not
>     present on the declaration of an annotation type T, then T is
>     applicable in all nine declaration contexts and in all 16 type
>     contexts."
>     >
>     > vs JLS 13:
>     >
>     > "If an annotation of type java.lang.annotation.Target is not
>     present on the declaration of an annotation type T, then T is
>     applicable in all declaration contexts except type parameter
>     declarations, and in no type contexts.
>     >
>     > These contexts are the syntactic locations where annotations
>     were allowed in Java SE 7."
>     >
>     > I can't find any mention of this change in a CSR so it is not
>     yet clear to me if the Javadoc or the JLS needs to be updated.
>     >
>     > cheers
>     > /Joel
>     >
>     > [1]
>     https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/annotation/Target.html
>     <https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/annotation/Target.html>
>
>     > [2]
>     https://docs.oracle.com/javase/specs/jls/se15/html/jls-9.html#jls-9.6.4.1
>     <https://docs.oracle.com/javase/specs/jls/se15/html/jls-9.html#jls-9.6.4.1>
>     > [3] https://github.com/openjdk/jdk/pull/622
>     <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/622__;!!GqivPVa7Brio!P7C91ceDLayE0UpDfpsSkSoQHUnJnVUAxQ1Noo5KlOn6pXIFkpKOn6Ie5C9-MEFAtj5R7qRDFNk$>
>     >
>
>
>
> -- 
> https://ece.uwaterloo.ca/~wdietl/ 
> <https://urldefense.com/v3/__https://ece.uwaterloo.ca/*wdietl/__;fg!!GqivPVa7Brio!P7C91ceDLayE0UpDfpsSkSoQHUnJnVUAxQ1Noo5KlOn6pXIFkpKOn6Ie5C9-MEFAtj5RYyfhlAQ$>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20201202/18098880/attachment-0001.htm>

From hseigel at openjdk.java.net  Wed Dec  2 14:30:57 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 2 Dec 2020 14:30:57 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <fJl0fs6rLPbW9t5heBPN2tjIuJOe92pGvTkkgRYurZw=.4e0c983b-093d-4a5d-8f2d-3764db94af4f@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <fJl0fs6rLPbW9t5heBPN2tjIuJOe92pGvTkkgRYurZw=.4e0c983b-093d-4a5d-8f2d-3764db94af4f@github.com>
Message-ID: <REUL_ADWwZ43titpLPdYBc2NJkaO9xXt7QfwjVgYbTA=.7c4a4d5c-8fcb-49e0-92b5-e9bb23b04077@github.com>

On Tue, 1 Dec 2020 23:16:45 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>> 
>> From the original PR:
>> 
>>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>>> 
>>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>>> 
>>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>>> 
>>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>>> 
>>>     * adding code to make sure that annotations can't be sealed
>>> 
>>>     * improving some tests
>>> 
>>> 
>>> TIA
>>> 
>>> Related specs:
>>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
>> 
>> This PR strives to reflect the review comments from 1227:
>>  * adjustments to javadoc of j.l.Class methods
>>  * package access checks in Class.getPermittedSubclasses()
>>  * fixed to the narrowing conversion/castability as pointed out by Maurizio
>
> From David's comment:
> 
>> These subtleties are what I was also getting at in the CSR discussion. If Foo lists Bar as a permitted subtype, but Bar does not extend Foo, is that an error? Should Bar not be returned by getPermittedSubclasses? The answer depends on exactly how you specify getPermittedSubclasses() and whether that aligns with reading the classfile attribute, or actually checking the runtime relationships. 
> 
> As I read the current spec of `Class::getPermittedSubclasses`, it intends to return the direct subclasses or subinterfaces permitted to extend or implement this class or interface if it's sealed.   If not, it should be clarified that it is the class file view.
> 
> `NestMembers` and `PermittedSubclasses` attributes are critical to correct interpretation of the class file by JVM.   Prior to these two attributes, the attributes inspected by core reflection APIs are all non-critical.  API like `Class::getDeclaringClass` reads `InnerClasses` attribute if present in order to determine its declaring class but the current spec does not specify the behavior on error cases (which I consider a spec bug - see JDK-8250226.)
> 
> IMO it is reasonable for `getPermittedSubclasses` (and `getNestMembers` and `getNestHost`) to return the runtime view as it returns `Class` objects since these attributes are critical to correct interpretation of the class file.  It would be confusing if it returns `Foo` that is not a permitted subtype at runtime.

Additional changes may be needed to Class.permittedSubclasses() and/or Class.isSealed() as part of fixing bug JDK-8256867.  The JVM is being changed to treat classes with empty PermittedSubclasses attributes as sealed classes that cannot be extended (or implemented).

Current thinking is that Class.permittedSubclasses() will return an empty array for both non-sealed classes and for sealed classes with empty PermittedSubclasses attributes.  And, Class.isSealed() will return False in the former case and True in the latter.  This will require changing the implementation of Class.isSealed() to call the JVM directly instead of calling Class.permittedSubclasses().

Does this seem like a reasonable way to handle this corner case?

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

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

From jlahoda at openjdk.java.net  Wed Dec  2 14:40:15 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 2 Dec 2020 14:40:15 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v3]
In-Reply-To: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
Message-ID: <rrgKFdiirxeaXz3n3oGEZ2iz8J2G5PS8bGNQSuwC_h0=.a1e1d843-0835-45ee-b34d-175816132b99@github.com>

> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
> 
> From the original PR:
> 
>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>> 
>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>> 
>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>> 
>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>> 
>>     * adding code to make sure that annotations can't be sealed
>> 
>>     * improving some tests
>> 
>> 
>> TIA
>> 
>> Related specs:
>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
> 
> This PR strives to reflect the review comments from 1227:
>  * adjustments to javadoc of j.l.Class methods
>  * package access checks in Class.getPermittedSubclasses()
>  * fixed to the narrowing conversion/castability as pointed out by Maurizio

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

  Improving Class.getPermittedSubclasses to filter out permitted classes that are not a subtype of the current class, and other adjustments per the review feedback.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1483/files
  - new: https://git.openjdk.java.net/jdk/pull/1483/files/4d484179..ff1abf06

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

  Stats: 250 lines in 8 files changed: 217 ins; 14 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1483.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1483/head:pull/1483

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

From rriggs at openjdk.java.net  Wed Dec  2 15:42:54 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 2 Dec 2020 15:42:54 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations.
In-Reply-To: <CUEB3J-W10h-QXmNang8FidRvp86egN-p5N3V0P85Ks=.50cd30f4-7575-4837-b3db-c2ebe2cb4e08@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
 <uf_6tcbpe0dLHA39qxAIGEgXb_VYKnfAANdGOLZOvQs=.e96cefa3-4deb-4a5f-ac7f-975b91fd8a1e@github.com>
 <CUEB3J-W10h-QXmNang8FidRvp86egN-p5N3V0P85Ks=.50cd30f4-7575-4837-b3db-c2ebe2cb4e08@github.com>
Message-ID: <7FdWCF7I1N4ax_xlTUi9Edbr8C-C5pHdpFFI3uSokMg=.d8097e28-2d47-40b9-ac21-8d41f66ecfc6@github.com>

On Tue, 1 Dec 2020 17:09:25 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> /**
>>   * {@return the result} Optional additional text.
>>   */
>>  ```
>> The java source looks a bit odd/unusual because the "first sentence" does not appear to end with a period.
>> Though it seems like a convenience to include the '.' in the expansion, the source might be clearer if it did not, as in:
>> /**
>>   * {@return the result}. Optional additional text.
>>   */ 
>> Similarly, prepending the "Returns", forces the verb, which is conventional but always the most appropriate word.
>> Changing the expansion to be only the contents of @ return would allow more flexible use.
>> It would put more responsibility on the developer to form the first sentence. (With "Returns"... and the "." outside the tag.
>
> @RogerRiggs ,
> 
> 1. I agree on that the lack of `.` after `}` looks unnatural:
> 
> /**
>  * {@return the result} Optional additional text.
>  */
> int method() { 
> 
> 2. I disagree on allowing a flexible expansion. This enhancement aims to support a very particular case of redundancy in doc comments. I believe that the proportion of redundant doc comments that use some other verb (instead of "Return(s)") is smaller than it needs to be to support the increase in tag's complexity.

There is lots of other duplication/repetition in most javadoc. I'd rather see some kind of text macro that would allow a single definition of a string that can be repeated.  The source would be a bit less readable, but it would be lower maintenance when the same phrase or sentence is repeated to make the javadoc more locally complete and easier to read in isolation. Now many times do you have to say "throws NullPointerException when the reference is null" or similar assertion.

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

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

From prappo at openjdk.java.net  Wed Dec  2 15:48:53 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 2 Dec 2020 15:48:53 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations.
In-Reply-To: <7FdWCF7I1N4ax_xlTUi9Edbr8C-C5pHdpFFI3uSokMg=.d8097e28-2d47-40b9-ac21-8d41f66ecfc6@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
 <uf_6tcbpe0dLHA39qxAIGEgXb_VYKnfAANdGOLZOvQs=.e96cefa3-4deb-4a5f-ac7f-975b91fd8a1e@github.com>
 <CUEB3J-W10h-QXmNang8FidRvp86egN-p5N3V0P85Ks=.50cd30f4-7575-4837-b3db-c2ebe2cb4e08@github.com>
 <7FdWCF7I1N4ax_xlTUi9Edbr8C-C5pHdpFFI3uSokMg=.d8097e28-2d47-40b9-ac21-8d41f66ecfc6@github.com>
Message-ID: <tuzR4-NnTC_-2GRoJxPiZT1SY7E5YVUNMfnPwlH6APo=.e481d268-acb1-4b98-8379-1608ad48186c@github.com>

On Wed, 2 Dec 2020 15:39:56 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> @RogerRiggs ,
>> 
>> 1. I agree on that the lack of `.` after `}` looks unnatural:
>> 
>> /**
>>  * {@return the result} Optional additional text.
>>  */
>> int method() { 
>> 
>> 2. I disagree on allowing a flexible expansion. This enhancement aims to support a very particular case of redundancy in doc comments. I believe that the proportion of redundant doc comments that use some other verb (instead of "Return(s)") is smaller than it needs to be to support the increase in tag's complexity.
>
> There is lots of other duplication/repetition in most javadoc. I'd rather see some kind of text macro that would allow a single definition of a string that can be repeated.  The source would be a bit less readable, but it would be lower maintenance when the same phrase or sentence is repeated to make the javadoc more locally complete and easier to read in isolation. Now many times do you have to say "throws NullPointerException when the reference is null" or similar assertion.

@RogerRiggs,

Here are some more thoughts on flexible expansion (i.e. not forcing a particular verb). To understand the nature and estimate the prevalence of cases where "Return(s)" was inappropriate as the first word of an internally repetitive doc comment, I conducted the following experiment in JDK.

I searched for doc comments whose first sentence was at least 90% similar to the contents of `@ return` tag. My program ignored differences in markup and compared contents as strings using normalized Levenshtein similarity; I got 3432 results. Then I modified the program to ignore those doc comments whose first sentence case-insensitively started with "return"; I got 194 results.

While more analysis might be required, I can preliminary see that we are talking about 5% of the cases. Which is not much, if you ask me. Here are a few findings made by the modified program:


/**
 * Cleaner for use within system modules.
 ...
 * @return a Cleaner for use within system modules
 */
public static Cleaner cleaner() {

/**
 * Get the localization resource bundle
 ...
 * @return the localization resource bundle
 */
public ResourceBundle getResourceBundle() {

/**
 * Obtains a line that is available for use and that matches the description
 * in the specified {@code Line.Info} object.
 ...
 * @return a line that is available for use and that matches the description
 *         in the specified {@code Line.Info} object
 ...
 */
Line getLine(Line.Info info) throws LineUnavailableException;

/**
 * The description of this filter. For example: "JPG and GIF Images."
 *
 * @return the description of this filter
 */
public String getDescription() {

/**
 * Fetch the object representing the layout state of
 * of the child at the given index.
 ...
 * @return the object representing the layout state of
 * of the child at the given index
 */
protected ChildState getChildState(int index) {

/**
 * Creates a new instance of the {@code DatatypeFactory} {@linkplain
 * #DATATYPEFACTORY_IMPLEMENTATION_CLASS builtin system-default
 * implementation}.
 *
 * @return A new instance of the {@code DatatypeFactory} builtin
 *         system-default implementation.
 ...
 */
public static DatatypeFactory newDefaultInstance() {

/**
 * True if this iterator has a reversed axis.
 *
 * @return <code>true</code> if this iterator is a reversed axis.
 */
public boolean isReverse() {

/**
 * Check if the annotation contains an array of annotation as a value. This
 * check is to verify if a repeatable type annotation is present or not.
 ...
 * @return true if the annotation contains an array of annotation as a value.
 */
private boolean isAnnotationArray(Map<? extends ExecutableElement, ? extends AnnotationValue> pairs) {

...

The most frequent first word in those 194 results was "Get(s)".

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

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

From jlahoda at openjdk.java.net  Wed Dec  2 17:42:58 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 2 Dec 2020 17:42:58 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <REUL_ADWwZ43titpLPdYBc2NJkaO9xXt7QfwjVgYbTA=.7c4a4d5c-8fcb-49e0-92b5-e9bb23b04077@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <fJl0fs6rLPbW9t5heBPN2tjIuJOe92pGvTkkgRYurZw=.4e0c983b-093d-4a5d-8f2d-3764db94af4f@github.com>
 <REUL_ADWwZ43titpLPdYBc2NJkaO9xXt7QfwjVgYbTA=.7c4a4d5c-8fcb-49e0-92b5-e9bb23b04077@github.com>
Message-ID: <nN6s72sqJl7UsaY-QYV6wYhBTTBFHQgwS0WhV09XXJw=.f2cd9935-e7fd-44bc-8480-bbc54dacb0a3@github.com>

On Wed, 2 Dec 2020 14:28:00 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Additional changes may be needed to Class.permittedSubclasses() and/or Class.isSealed() as part of fixing bug JDK-8256867. The JVM is being changed to treat classes with empty PermittedSubclasses attributes as sealed classes that cannot be extended (or implemented).
> 
> Current thinking is that Class.permittedSubclasses() will return an empty array for both non-sealed classes and for sealed classes with empty PermittedSubclasses attributes. And, Class.isSealed() will return False in the former case and True in the latter. This will require changing the implementation of Class.isSealed() to call the JVM directly instead of calling Class.permittedSubclasses().
> 
> Does this seem like a reasonable way to handle this corner case?

Uh, I just realized it may be necessary to implement `Class.isSealed()` differently. Consider:
sealed class Sealed permits Unknown {}

Where `Unknown` does not exist at runtime. So getPermittedSubclasses0() returns an empty array(?). But isSealed should return `true`, right? (Possibly, we could leave this from the first integration, but seems like something that should be done. Note that in the previous/JDK 15 implementation, isSealed() would return true in this case.)

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

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

From chegar at openjdk.java.net  Wed Dec  2 17:48:57 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 2 Dec 2020 17:48:57 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <nN6s72sqJl7UsaY-QYV6wYhBTTBFHQgwS0WhV09XXJw=.f2cd9935-e7fd-44bc-8480-bbc54dacb0a3@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <fJl0fs6rLPbW9t5heBPN2tjIuJOe92pGvTkkgRYurZw=.4e0c983b-093d-4a5d-8f2d-3764db94af4f@github.com>
 <REUL_ADWwZ43titpLPdYBc2NJkaO9xXt7QfwjVgYbTA=.7c4a4d5c-8fcb-49e0-92b5-e9bb23b04077@github.com>
 <nN6s72sqJl7UsaY-QYV6wYhBTTBFHQgwS0WhV09XXJw=.f2cd9935-e7fd-44bc-8480-bbc54dacb0a3@github.com>
Message-ID: <3TxnaMFicwJfi4HebVySfGtUpBjMR2zEG22gyWDvc1g=.55e08627-ba5c-4e76-9025-ef8c5e6331f3@github.com>

On Wed, 2 Dec 2020 17:39:59 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> ...
> Uh, I just realized it may be necessary to implement `Class.isSealed()` differently. Consider:
> 
> ```
> sealed class Sealed permits Unknown {}
> ```
> 
> Where `Unknown` does not exist at runtime. So getPermittedSubclasses0() returns an empty array(?). But isSealed should return `true`, right? (Possibly, we could leave this from the first integration, but seems like something that should be done. Note that in the previous/JDK 15 implementation, isSealed() would return true in this case.)

@lahodaj  I raised this issue here: https://mail.openjdk.java.net/pipermail/amber-spec-experts/2020-October/002626.html

Relevant comment inline:
> The recent change (proposed on this list) to Class::getPermittedSubclasses, means that it will no longer be possible to reflectively return permitted subclasses that are not loaded, or more specifically ?loadable" - the classes must exist somewhere. Currently, in JDK 15, permittedSubclasses will return class descriptors for non-loadable classes. I think that this is ok, we just need to ensure that it fits into the other rules here.

Yep. I think this is a good change, and I think there's nothing wrong with the reflection API either ignoring some entries or reporting class loading errors. Best to do whatever the NestMembers query does.

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

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

From mchung at openjdk.java.net  Wed Dec  2 17:59:56 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 2 Dec 2020 17:59:56 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <nN6s72sqJl7UsaY-QYV6wYhBTTBFHQgwS0WhV09XXJw=.f2cd9935-e7fd-44bc-8480-bbc54dacb0a3@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <fJl0fs6rLPbW9t5heBPN2tjIuJOe92pGvTkkgRYurZw=.4e0c983b-093d-4a5d-8f2d-3764db94af4f@github.com>
 <REUL_ADWwZ43titpLPdYBc2NJkaO9xXt7QfwjVgYbTA=.7c4a4d5c-8fcb-49e0-92b5-e9bb23b04077@github.com>
 <nN6s72sqJl7UsaY-QYV6wYhBTTBFHQgwS0WhV09XXJw=.f2cd9935-e7fd-44bc-8480-bbc54dacb0a3@github.com>
Message-ID: <TB3qLpDsH8W64hlI-b_ncBRtybUMmgDGMa98g1IFHw0=.98b3caf9-9a78-4720-aa73-d3e87965cedf@github.com>

On Wed, 2 Dec 2020 17:39:59 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Additional changes may be needed to Class.permittedSubclasses() and/or Class.isSealed() as part of fixing bug JDK-8256867. The JVM is being changed to treat classes with empty PermittedSubclasses attributes as sealed classes that cannot be extended (or implemented).
> 
> Current thinking is that Class.permittedSubclasses() will return an empty array for both non-sealed classes and for sealed classes with empty PermittedSubclasses attributes. And, Class.isSealed() will return False in the former case and True in the latter. This will require changing the implementation of Class.isSealed() to call the JVM directly instead of calling Class.permittedSubclasses().
> 
> Does this seem like a reasonable way to handle this corner case?

I suggest `Class::getPermittedSubclasses` to return a `non-null` array if this `Class` is sealed, i.e. this class is derived from a `class` file with the presence of `PermittedSubclasses` attribute regardless of its content (the attribute could be empty or contains zero or more entries which is a properly loaded permitted subtype.

If this `Class` is not sealed, `Class::getPermittedSubclasses` returns null.

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

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

From dlsmith at openjdk.java.net  Wed Dec  2 19:34:59 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Wed, 2 Dec 2020 19:34:59 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <TB3qLpDsH8W64hlI-b_ncBRtybUMmgDGMa98g1IFHw0=.98b3caf9-9a78-4720-aa73-d3e87965cedf@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <fJl0fs6rLPbW9t5heBPN2tjIuJOe92pGvTkkgRYurZw=.4e0c983b-093d-4a5d-8f2d-3764db94af4f@github.com>
 <REUL_ADWwZ43titpLPdYBc2NJkaO9xXt7QfwjVgYbTA=.7c4a4d5c-8fcb-49e0-92b5-e9bb23b04077@github.com>
 <nN6s72sqJl7UsaY-QYV6wYhBTTBFHQgwS0WhV09XXJw=.f2cd9935-e7fd-44bc-8480-bbc54dacb0a3@github.com>
 <TB3qLpDsH8W64hlI-b_ncBRtybUMmgDGMa98g1IFHw0=.98b3caf9-9a78-4720-aa73-d3e87965cedf@github.com>
Message-ID: <bdXVKS7ktrsPdSYY4fmY1xPszzW6a7nD9yK-zBnfKkU=.6ee24f4f-72a7-4ead-9217-eb0efba10c24@github.com>

On Wed, 2 Dec 2020 17:57:22 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> I suggest `Class::getPermittedSubclasses` to return a `non-null` array if this `Class` is sealed, i.e. this class is derived from a `class` file with the presence of `PermittedSubclasses` attribute regardless of its content (the attribute could be empty or contains zero or more entries which is a properly loaded permitted subtype.
> 
> If this `Class` is not sealed, `Class::getPermittedSubclasses` returns null (see `Class::getRecordComponents` and some other reflection APIs as precedence).

Agree, that seems reasonable. Often, methods in `Class` with an array return type default to an empty array, but `getRecordComponents` is a good example of returning `null` when an empty array is meaningful.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Dec  3 08:19:16 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 3 Dec 2020 08:19:16 GMT
Subject: RFR: 8254023: A module declaration is not allowed to be a target
 of an annotation that lacks an @Target meta-annotation [v2]
In-Reply-To: <wFdu9AyyNU2SB0nWx9mq_2syF2XyQIB0z6Rmc-r1fNc=.369439d1-385e-4fd1-aac1-72e48ac246e8@github.com>
References: <wFdu9AyyNU2SB0nWx9mq_2syF2XyQIB0z6Rmc-r1fNc=.369439d1-385e-4fd1-aac1-72e48ac246e8@github.com>
Message-ID: <G9Mqf-qMJMfPYvlSIt3IFI1yMBmuLrnjdrdkwUNhPEY=.9e58704e-37c7-4381-96e1-a2b22ec3bef5@github.com>

> Hi all,
> 
> The Java Language Specifications(JLS), from 8 to 13 included, state it as below:
> 
>> If an annotation of type java.lang.annotation.Target is not present on the
> declaration of an annotation type T , then T is applicable in all declaration contexts
> except type parameter declarations, and in no type contexts.
> These contexts are the syntactic locations where annotations were allowed in Java SE 7.
> 
> The JLS 14 and 15 state it as below:
> 
>>If an annotation of type java.lang.annotation.Target is not present on the
> declaration of an annotation type T , then T is applicable in all nine declaration
> contexts and in all 16 type contexts.
> 
> This patch adds `names.MODULE, names.TYPE_PARAMETER, names.TYPE_USE` to `com.sun.tools.javac.comp.Check.dfltTargetMeta` to fix this issue.
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Remove TYPE_PARAMETER and TYPE_USE

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/622/files
  - new: https://git.openjdk.java.net/jdk/pull/622/files/8bb0c5d6..5ff3e252

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

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Dec  3 08:22:56 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 3 Dec 2020 08:22:56 GMT
Subject: RFR: 8254023: A module declaration is not allowed to be a target
 of an annotation that lacks an @Target meta-annotation
In-Reply-To: <5_HZhCK8rd2yWcf4XzGa_N50I1Xl3CMmUXSugfoJIUk=.379b61e3-e4a3-4509-ac7b-940a25ae4609@github.com>
References: <wFdu9AyyNU2SB0nWx9mq_2syF2XyQIB0z6Rmc-r1fNc=.369439d1-385e-4fd1-aac1-72e48ac246e8@github.com>
 <pqSfmocPi4AJGQJEJl4j6UgITEL0f62TKSVpxwOer6w=.49e74a9b-ecb0-4a13-9dfc-93c27fd5149a@github.com>
 <5_HZhCK8rd2yWcf4XzGa_N50I1Xl3CMmUXSugfoJIUk=.379b61e3-e4a3-4509-ac7b-940a25ae4609@github.com>
Message-ID: <6VDsNZKAYnkmm_YsLRjClBhqPMPPqy4d3TrWLcElkOU=.3f9b9d49-4e49-4574-a07c-6f72acefcfd2@github.com>

On Tue, 20 Oct 2020 05:38:27 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hello,
>> 
>> Thank you for the contribution.
>> 
>> As you can see from the @Target javadoc ( https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/annotation/Target.html ) there is some ambiguity here. I have rased a separate discussion on compiler-dev, depending on the outcome of that discussion this patch will need to be revised.
>
> Thanks for focusing on this patch. I will continue to follow the discussion and revise my patch based on the outcome of the discussion.

> Short term (Java 16) it makes sense to fix https://bugs.openjdk.java.net/browse/JDK-8254023 given that both competing specs agree for this case, it is a small fix, and externally found.
>
>For Java 17 we should align both specs and the reference implementation one way or another.

@jbf According to your comments, I revise my code to only fix JDK-8254023.
The rest of the work, ambiguity of the specifications, will be clarified and fixed in Java 17.
Thank you for taking the time to review.

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

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

From jlahoda at openjdk.java.net  Thu Dec  3 09:22:18 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 3 Dec 2020 09:22:18 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v5]
In-Reply-To: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
Message-ID: <bG8PpoaqCnD_mWq0sKWSkOgOmiEyvsrpbn9v5hRTWuM=.a4206e56-1a5b-493e-9e47-7156166c74fa@github.com>

> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
> -updating and moving tests into test/langtools, so that it is easier to run them.
> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
> -fixing the -Xprint annotation processor to print record component annotations.
> 
> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.

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

  Blank lines do not count for the text block indentation, removing them.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1480/files
  - new: https://git.openjdk.java.net/jdk/pull/1480/files/9ab7153a..3aaaf28c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=03-04

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

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

From jlahoda at openjdk.java.net  Thu Dec  3 09:39:57 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 3 Dec 2020 09:39:57 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v3]
In-Reply-To: <AoKBfvbBw_pm22ChROZMWUw4rmQqD4PnzVwiUeB4Zqw=.b3e3d000-d189-4c82-b541-e511969e8a05@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
 <ZfeGVwwoe17k0ccnpt1oCaxL_SQ2D9OmOXAHn_R7QfU=.dfbbefa0-abd6-4c82-a7d0-ee05706a48ec@github.com>
 <OwDTR-tYF8NbG6X212Nxeps-8S11SxIEGvTql3GtEhw=.2801cf40-648b-4fd5-99bd-5eb9138c9ecb@github.com>
 <AoKBfvbBw_pm22ChROZMWUw4rmQqD4PnzVwiUeB4Zqw=.b3e3d000-d189-4c82-b541-e511969e8a05@github.com>
Message-ID: <xOMtcIuGAh5GjnRpur2DBvpFfpO9gMlL6EG_CNzuCNo=.b7e25569-1e26-4029-98f3-be2c998675f4@github.com>

On Tue, 1 Dec 2020 12:06:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> test/langtools/tools/javac/platform/createsymbols/CreateSymbolsTestImpl.java line 513:
>> 
>>> 511:                              public java.util.List<java.lang.String> l();
>>> 512:                            }
>>> 513:                            """,
>> 
>> I don't understand why the lines with `\n` in a text block
>
> There is a combination of factors here:
> -jcheck (AFAIK) does not allow trailing whitespaces, even not on otherwise empty lines inside textblocks
> -textblocks only remove indentation that is common on all lines.
> 
> So, without having '\n', we would have to strip all the whitespace on the empty lines (to pass jcheck), which would mean the text block's content would no longer match the output. There are a few ways to solve this (almost surely an incomplete list):
> -do some trick to have the common indent, but no trailing whitespace. '\n' is one of them.
> -not indent the text block
> -do some post-processing on the text block's value or the actual test output, to make them match
> -not use textblocks

I stand corrected here - blank lines do not count when the common indent is computed. Removed here:
https://github.com/openjdk/jdk/pull/1480/commits/3aaaf28c23ddda71c77ca9923e02e5f3502cde3b

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

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

From jlahoda at openjdk.java.net  Thu Dec  3 14:09:10 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 3 Dec 2020 14:09:10 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v4]
In-Reply-To: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
Message-ID: <pqQgs3uxiNof3UfZo0sScTV6Y18w1l3sqTwN6Vj1shw=.5f5eb04a-2b5c-4b1e-a1c9-6185cbd18b27@github.com>

> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
> 
> From the original PR:
> 
>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>> 
>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>> 
>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>> 
>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>> 
>>     * adding code to make sure that annotations can't be sealed
>> 
>>     * improving some tests
>> 
>> 
>> TIA
>> 
>> Related specs:
>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
> 
> This PR strives to reflect the review comments from 1227:
>  * adjustments to javadoc of j.l.Class methods
>  * package access checks in Class.getPermittedSubclasses()
>  * fixed to the narrowing conversion/castability as pointed out by Maurizio

Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:

 - Fixing tests.
 - getPermittedSubclasses to return null for non-sealed classes, as requested.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1483/files
  - new: https://git.openjdk.java.net/jdk/pull/1483/files/ff1abf06..537e267f

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

  Stats: 117 lines in 6 files changed: 94 ins; 5 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1483.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1483/head:pull/1483

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

From jlahoda at openjdk.java.net  Thu Dec  3 14:11:57 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 3 Dec 2020 14:11:57 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <bdXVKS7ktrsPdSYY4fmY1xPszzW6a7nD9yK-zBnfKkU=.6ee24f4f-72a7-4ead-9217-eb0efba10c24@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <fJl0fs6rLPbW9t5heBPN2tjIuJOe92pGvTkkgRYurZw=.4e0c983b-093d-4a5d-8f2d-3764db94af4f@github.com>
 <REUL_ADWwZ43titpLPdYBc2NJkaO9xXt7QfwjVgYbTA=.7c4a4d5c-8fcb-49e0-92b5-e9bb23b04077@github.com>
 <nN6s72sqJl7UsaY-QYV6wYhBTTBFHQgwS0WhV09XXJw=.f2cd9935-e7fd-44bc-8480-bbc54dacb0a3@github.com>
 <TB3qLpDsH8W64hlI-b_ncBRtybUMmgDGMa98g1IFHw0=.98b3caf9-9a78-4720-aa73-d3e87965cedf@github.com>
 <bdXVKS7ktrsPdSYY4fmY1xPszzW6a7nD9yK-zBnfKkU=.6ee24f4f-72a7-4ead-9217-eb0efba10c24@github.com>
Message-ID: <SEofYeulqWm9WJSSPr-sh1vpa24kTHgmzMeFZJP8pPU=.5ffc2b6a-3679-4d86-9eac-c260a98d6da4@github.com>

On Wed, 2 Dec 2020 19:31:59 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

>>> Additional changes may be needed to Class.permittedSubclasses() and/or Class.isSealed() as part of fixing bug JDK-8256867. The JVM is being changed to treat classes with empty PermittedSubclasses attributes as sealed classes that cannot be extended (or implemented).
>>> 
>>> Current thinking is that Class.permittedSubclasses() will return an empty array for both non-sealed classes and for sealed classes with empty PermittedSubclasses attributes. And, Class.isSealed() will return False in the former case and True in the latter. This will require changing the implementation of Class.isSealed() to call the JVM directly instead of calling Class.permittedSubclasses().
>>> 
>>> Does this seem like a reasonable way to handle this corner case?
>> 
>> I suggest `Class::getPermittedSubclasses` to return a `non-null` array if this `Class` is sealed, i.e. this class is derived from a `class` file with the presence of `PermittedSubclasses` attribute regardless of its content (the attribute could be empty or contains zero or more entries which is a properly loaded permitted subtype.
>> 
>> If this `Class` is not sealed, `Class::getPermittedSubclasses` returns null (see `Class::getRecordComponents` and some other reflection APIs as precedence).
>
>> I suggest `Class::getPermittedSubclasses` to return a `non-null` array if this `Class` is sealed, i.e. this class is derived from a `class` file with the presence of `PermittedSubclasses` attribute regardless of its content (the attribute could be empty or contains zero or more entries which is a properly loaded permitted subtype.
>> 
>> If this `Class` is not sealed, `Class::getPermittedSubclasses` returns null (see `Class::getRecordComponents` and some other reflection APIs as precedence).
> 
> Agree, that seems reasonable. Often, methods in `Class` with an array return type default to an empty array, but `getRecordComponents` is a good example of returning `null` when an empty array is meaningful.

I've changed Class.getPermittedSubclasses to return null for classes that are not sealed here:
https://github.com/openjdk/jdk/pull/1483/commits/7056143822ff62dfbb1d294c67352ed3892317c2
with follow-up changes to tests here:
https://github.com/openjdk/jdk/pull/1483/commits/537e267fb6802ab5cf38bf26978039383cc6309a

How does this look?

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

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

From jlahoda at openjdk.java.net  Thu Dec  3 14:40:55 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 3 Dec 2020 14:40:55 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <SEofYeulqWm9WJSSPr-sh1vpa24kTHgmzMeFZJP8pPU=.5ffc2b6a-3679-4d86-9eac-c260a98d6da4@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <fJl0fs6rLPbW9t5heBPN2tjIuJOe92pGvTkkgRYurZw=.4e0c983b-093d-4a5d-8f2d-3764db94af4f@github.com>
 <REUL_ADWwZ43titpLPdYBc2NJkaO9xXt7QfwjVgYbTA=.7c4a4d5c-8fcb-49e0-92b5-e9bb23b04077@github.com>
 <nN6s72sqJl7UsaY-QYV6wYhBTTBFHQgwS0WhV09XXJw=.f2cd9935-e7fd-44bc-8480-bbc54dacb0a3@github.com>
 <TB3qLpDsH8W64hlI-b_ncBRtybUMmgDGMa98g1IFHw0=.98b3caf9-9a78-4720-aa73-d3e87965cedf@github.com>
 <bdXVKS7ktrsPdSYY4fmY1xPszzW6a7nD9yK-zBnfKkU=.6ee24f4f-72a7-4ead-9217-eb0efba10c24@github.com>
 <SEofYeulqWm9WJSSPr-sh1vpa24kTHgmzMeFZJP8pPU=.5ffc2b6a-3679-4d86-9eac-c260a98d6da4@github.com>
Message-ID: <xziOI6R0SaqZwM_JKp9P-BvKqFqawRSJmU9_CTuCHNM=.6591d619-2d45-4912-ba1d-4451392d0b10@github.com>

On Thu, 3 Dec 2020 14:08:48 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>>> I suggest `Class::getPermittedSubclasses` to return a `non-null` array if this `Class` is sealed, i.e. this class is derived from a `class` file with the presence of `PermittedSubclasses` attribute regardless of its content (the attribute could be empty or contains zero or more entries which is a properly loaded permitted subtype.
>>> 
>>> If this `Class` is not sealed, `Class::getPermittedSubclasses` returns null (see `Class::getRecordComponents` and some other reflection APIs as precedence).
>> 
>> Agree, that seems reasonable. Often, methods in `Class` with an array return type default to an empty array, but `getRecordComponents` is a good example of returning `null` when an empty array is meaningful.
>
> I've changed Class.getPermittedSubclasses to return null for classes that are not sealed here:
> https://github.com/openjdk/jdk/pull/1483/commits/7056143822ff62dfbb1d294c67352ed3892317c2
> with follow-up changes to tests here:
> https://github.com/openjdk/jdk/pull/1483/commits/537e267fb6802ab5cf38bf26978039383cc6309a
> 
> How does this look?

After a discussion with Harold, I've reverted the patch where Class.getPermittedSubclasses returns null. Harold will do that separatelly under JDK-8256867, unless there are objections.

The changes that were reverted are still available here:
https://openjdk.github.io/cr/?repo=jdk&pr=1483&range=02-03

Please let me know if there are any issues.

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

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

From lfoltan at openjdk.java.net  Thu Dec  3 16:09:57 2020
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Thu, 3 Dec 2020 16:09:57 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v3]
In-Reply-To: <rrgKFdiirxeaXz3n3oGEZ2iz8J2G5PS8bGNQSuwC_h0=.a1e1d843-0835-45ee-b34d-175816132b99@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <rrgKFdiirxeaXz3n3oGEZ2iz8J2G5PS8bGNQSuwC_h0=.a1e1d843-0835-45ee-b34d-175816132b99@github.com>
Message-ID: <KJHaBirJ-p9dtnYe0HgiK4Cfh2WDcUvGM7Z6o1vmbrk=.e972e843-88f9-4769-9db0-0c7d147c6216@github.com>

On Wed, 2 Dec 2020 14:40:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>> 
>> From the original PR:
>> 
>>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>>> 
>>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>>> 
>>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>>> 
>>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>>> 
>>>     * adding code to make sure that annotations can't be sealed
>>> 
>>>     * improving some tests
>>> 
>>> 
>>> TIA
>>> 
>>> Related specs:
>>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
>> 
>> This PR strives to reflect the review comments from 1227:
>>  * adjustments to javadoc of j.l.Class methods
>>  * package access checks in Class.getPermittedSubclasses()
>>  * fixed to the narrowing conversion/castability as pointed out by Maurizio
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improving Class.getPermittedSubclasses to filter out permitted classes that are not a subtype of the current class, and other adjustments per the review feedback.

I reviewed the hotspot changes and they hotspot look good.
Thanks,
Lois

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

Marked as reviewed by lfoltan (Reviewer).

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

From mchung at openjdk.java.net  Thu Dec  3 17:26:57 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 3 Dec 2020 17:26:57 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v3]
In-Reply-To: <KJHaBirJ-p9dtnYe0HgiK4Cfh2WDcUvGM7Z6o1vmbrk=.e972e843-88f9-4769-9db0-0c7d147c6216@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <rrgKFdiirxeaXz3n3oGEZ2iz8J2G5PS8bGNQSuwC_h0=.a1e1d843-0835-45ee-b34d-175816132b99@github.com>
 <KJHaBirJ-p9dtnYe0HgiK4Cfh2WDcUvGM7Z6o1vmbrk=.e972e843-88f9-4769-9db0-0c7d147c6216@github.com>
Message-ID: <EnwsMj1bs3C0n6d-gUNbUfchZNYoTjHD-BlM00XS68M=.f2ce99c1-f82c-43a5-a4ea-2128aa151602@github.com>

On Thu, 3 Dec 2020 16:07:28 GMT, Lois Foltan <lfoltan at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improving Class.getPermittedSubclasses to filter out permitted classes that are not a subtype of the current class, and other adjustments per the review feedback.
>
> I have reviewed the hotspot changes and they look good.
> Thanks,
> Lois

> After a discussion with Harold, I've reverted the patch where Class.getPermittedSubclasses returns null. Harold will do that separatelly under JDK-8256867, unless there are objections.

No objection.   Keeping `Class::getPermittedSubclasses` as specified in the CSR is right thing to do so that this work can be integrated and resolve JDK-8256867 separately.

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

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

From mchung at openjdk.java.net  Thu Dec  3 18:21:00 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 3 Dec 2020 18:21:00 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v3]
In-Reply-To: <rrgKFdiirxeaXz3n3oGEZ2iz8J2G5PS8bGNQSuwC_h0=.a1e1d843-0835-45ee-b34d-175816132b99@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <rrgKFdiirxeaXz3n3oGEZ2iz8J2G5PS8bGNQSuwC_h0=.a1e1d843-0835-45ee-b34d-175816132b99@github.com>
Message-ID: <Mr6EpjM5-OWRu0LShwdNAeDJbFFoEtrtZ9Sx97ONyUY=.58591f2a-286e-4589-9a4b-0a6301e1b227@github.com>

On Wed, 2 Dec 2020 14:40:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>> 
>> From the original PR:
>> 
>>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>>> 
>>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>>> 
>>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>>> 
>>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>>> 
>>>     * adding code to make sure that annotations can't be sealed
>>> 
>>>     * improving some tests
>>> 
>>> 
>>> TIA
>>> 
>>> Related specs:
>>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
>> 
>> This PR strives to reflect the review comments from 1227:
>>  * adjustments to javadoc of j.l.Class methods
>>  * package access checks in Class.getPermittedSubclasses()
>>  * fixed to the narrowing conversion/castability as pointed out by Maurizio
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improving Class.getPermittedSubclasses to filter out permitted classes that are not a subtype of the current class, and other adjustments per the review feedback.

I approve this version of `Class::getPermittedSubclasses` implementation for this PR.    We need to follow up the specification of `Class::getPermittedSubclasses` w.r.t. what it should return e.g. the classes whatever in `PermittedSubclasses` attribute vs the classes that are permitted subtypes at runtime and return null if this class is not sealed. 

I reviewed hotspot and java.base changes (not langtools) with a couple minor comments.

test/jdk/java/lang/reflect/sealed_classes/TestSecurityManagerChecks.java line 51:

> 49: public class TestSecurityManagerChecks {
> 50: 
> 51:     private static final ClassLoader OBJECT_CL = Object.class.getClassLoader();

This is `null` - the bootstrap class loader.   An alternative to the static variable we can simply use null.

test/jdk/java/lang/reflect/sealed_classes/TestSecurityManagerChecks.java line 66:

> 64:                                                     .getProtectionDomain()
> 65:                                                     .getCodeSource()
> 66:                                                     .getLocation();

This is essentially the classpath.   An alternative way to get the location through `System.getProperty("test.class.path")`.

test/jdk/java/lang/reflect/sealed_classes/TestSecurityManagerChecks.java line 86:

> 84: 
> 85:         // First get hold of the target classes before we enable security
> 86:         Class<?> sealed = testLayer.findLoader("test").loadClass("test.Base");

I would recommend to use `Class::forName` instead of `ClassLoader::loadClass`  even though this is just a test (for security reason for example avoid type confusion).   If you want to load a class from a specific module, you can use `Class.forName(String cn, Module m)`

test/jdk/java/lang/reflect/sealed_classes/TestSecurityManagerChecks.java line 91:

> 89:         Class<?>[] subclasses = sealed.getPermittedSubclasses();
> 90: 
> 91:         if (subclasses.length != 3) {

I suggest to check against the expected list of permitted subclasses here and also the validation in the subsequent calls to `getPermittedSubclasses` with security manager enabled.   That would help the readers easier to understand this test.

test/jdk/java/lang/reflect/sealed_classes/TestSecurityManagerChecks.java line 120:

> 118: 
> 119:         //should pass - does not return a class from package "test":
> 120:         sealed.getPermittedSubclasses();

Adding a check to the expected returned value would make this clear (no permitted subclasses of package `test`).

src/java.base/share/classes/java/lang/Class.java line 3035:

> 3033:      */
> 3034:     private static void checkPackageAccessForPermittedSubclasses(SecurityManager sm,
> 3035:                                     final ClassLoader ccl, boolean checkProxyInterfaces,

`checkProxyInterfaces` parameter is not needed.  It can be removed.

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

Marked as reviewed by mchung (Reviewer).

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

From jjg at openjdk.java.net  Thu Dec  3 19:44:17 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 3 Dec 2020 19:44:17 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations. [v5]
In-Reply-To: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
Message-ID: <GjHF5xdbl6KH9h_GF9ZVLh5mUrsqvRoBQ6sAk5hS-bs=.e8c8bd3d-c17e-4bcd-87ca-88c5c1a51c50@github.com>

> This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description.
> 
> The goal is to be able to simplify the following common pattern:
> 
>     /**
>      * Returns the result. Optional additional text.
>      * @return the result
>      */
>     int method() { 
> 
> by 
> 
>     /**
>      * {@return the result} Optional additional text.
>      */
>     int method() { 
> 
> Note:
> 
> * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere.
> * The expansion of the inline tag is `Returns " _content_ `.`  where _content_ is the content of the tag. 
> * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description
> * The inline tag can be inherited into overriding methods as if it was provided as a block tag.

Jonathan Gibbons 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 11 additional commits since the last revision:

 - Update JShell to handle inline `{@return}`
 - Merge remote-tracking branch 'upstream/master' into new-return
 - fix test
 - Update for new `@return` tag
 - Merge remote-tracking branch 'upstream/master' into new-return
 - Update DocCommentParser to permit nested inline tags in specified cases: @return
 - Add default impl for new method
 - Fix test failure
 - Fix trailing whitespace in test
 - Merge master
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/4de14b11...60ff9839

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1355/files
  - new: https://git.openjdk.java.net/jdk/pull/1355/files/5703d83b..60ff9839

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1355&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1355&range=03-04

  Stats: 5899 lines in 160 files changed: 4319 ins; 407 del; 1173 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1355.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1355/head:pull/1355

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

From darcy at openjdk.java.net  Thu Dec  3 21:21:55 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 3 Dec 2020 21:21:55 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations.
In-Reply-To: <7FdWCF7I1N4ax_xlTUi9Edbr8C-C5pHdpFFI3uSokMg=.d8097e28-2d47-40b9-ac21-8d41f66ecfc6@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
 <uf_6tcbpe0dLHA39qxAIGEgXb_VYKnfAANdGOLZOvQs=.e96cefa3-4deb-4a5f-ac7f-975b91fd8a1e@github.com>
 <CUEB3J-W10h-QXmNang8FidRvp86egN-p5N3V0P85Ks=.50cd30f4-7575-4837-b3db-c2ebe2cb4e08@github.com>
 <7FdWCF7I1N4ax_xlTUi9Edbr8C-C5pHdpFFI3uSokMg=.d8097e28-2d47-40b9-ac21-8d41f66ecfc6@github.com>
Message-ID: <uRJn3oaeSimBRXejywlSizOPGJtHNzsQyVlEPC51PpA=.dbf0afde-8926-4653-a6c1-ab4d623c951e@github.com>

On Wed, 2 Dec 2020 15:39:56 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> 
> 
> There is lots of other duplication/repetition in most javadoc. I'd rather see some kind of text macro that would allow a single definition of a string that can be repeated. The source would be a bit less readable, but it would be lower maintenance when the same phrase or sentence is repeated to make the javadoc more locally complete and easier to read in isolation. Now many times do you have to say "throws NullPointerException when the reference is null" or similar assertion.

IMO this is a case to avoid the perfect being the enemy of the good. There are many structural cases of repeated or nearly repeated return information in the first sentence and @return tag. Therefore, I think it is reasonable for don't-repeat-yourself purposes to have dedicated support for this usage pattern.

Separately, I agree it would be helpful to have a more general facility to allow structured placement of repeated text blocks.

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

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

From darcy at openjdk.java.net  Thu Dec  3 21:21:54 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 3 Dec 2020 21:21:54 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations.
In-Reply-To: <uf_6tcbpe0dLHA39qxAIGEgXb_VYKnfAANdGOLZOvQs=.e96cefa3-4deb-4a5f-ac7f-975b91fd8a1e@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
 <uf_6tcbpe0dLHA39qxAIGEgXb_VYKnfAANdGOLZOvQs=.e96cefa3-4deb-4a5f-ac7f-975b91fd8a1e@github.com>
Message-ID: <4j63ORDSQ307ihTZ5qnTrun-P9QdgWDne_y7SuNgFGY=.37115171-05b4-4f79-804c-7fa998f9fd5b@github.com>

On Fri, 27 Nov 2020 16:33:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> 
> 
> ```
> /**
>   * {@return the result} Optional additional text.
>   */
> ```
> 
> The java source looks a bit odd/unusual because the "first sentence" does not appear to end with a period.
> Though it seems like a convenience to include the '.' in the expansion, the source might be clearer if it did not, as in:
> 
> ```
> /**
>   * {@return the result}. Optional additional text.
>   */ 
> ```
> 
> Similarly, prepending the "Returns", forces the verb, which is conventional but always the most appropriate word.
> Changing the expansion to be only the contents of @ return would allow more flexible use.
> It would put more responsibility on the developer to form the first sentence. (With "Returns"... and the "." outside the tag.

I've done a trial use of this feature in the java.compiler API. While initially I found the lack of a period after "{@return ...}" odd, I quickly adapted to this usage.

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

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

From jjg at openjdk.java.net  Thu Dec  3 21:31:55 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 3 Dec 2020 21:31:55 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations.
In-Reply-To: <uRJn3oaeSimBRXejywlSizOPGJtHNzsQyVlEPC51PpA=.dbf0afde-8926-4653-a6c1-ab4d623c951e@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
 <uf_6tcbpe0dLHA39qxAIGEgXb_VYKnfAANdGOLZOvQs=.e96cefa3-4deb-4a5f-ac7f-975b91fd8a1e@github.com>
 <CUEB3J-W10h-QXmNang8FidRvp86egN-p5N3V0P85Ks=.50cd30f4-7575-4837-b3db-c2ebe2cb4e08@github.com>
 <7FdWCF7I1N4ax_xlTUi9Edbr8C-C5pHdpFFI3uSokMg=.d8097e28-2d47-40b9-ac21-8d41f66ecfc6@github.com>
 <uRJn3oaeSimBRXejywlSizOPGJtHNzsQyVlEPC51PpA=.dbf0afde-8926-4653-a6c1-ab4d623c951e@github.com>
Message-ID: <5Ialjqp4jrEQ9QTm_19pujYWByiYqi6ldiVRtdqyiCo=.9d03a49e-151b-4be4-8cb3-329730cbd7d9@github.com>

On Thu, 3 Dec 2020 21:19:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> There is lots of other duplication/repetition in most javadoc. I'd rather see some kind of text macro that would allow a single definition of a string that can be repeated.  The source would be a bit less readable, but it would be lower maintenance when the same phrase or sentence is repeated to make the javadoc more locally complete and easier to read in isolation. Now many times do you have to say "throws NullPointerException when the reference is null" or similar assertion.
>
>> 
>> 
>> There is lots of other duplication/repetition in most javadoc. I'd rather see some kind of text macro that would allow a single definition of a string that can be repeated. The source would be a bit less readable, but it would be lower maintenance when the same phrase or sentence is repeated to make the javadoc more locally complete and easier to read in isolation. Now many times do you have to say "throws NullPointerException when the reference is null" or similar assertion.
> 
> IMO this is a case to avoid the perfect being the enemy of the good. There are many structural cases of repeated or nearly repeated return information in the first sentence and @return tag. Therefore, I think it is reasonable for don't-repeat-yourself purposes to have dedicated support for this usage pattern.
> 
> Separately, I agree it would be helpful to have a more general facility to allow structured placement of repeated text blocks.

Yes, there are two patterns being discussed here.

1. The pattern being directly addressed here, which is the local 
pairwise repetition of
 ???? Returns the result.
 ???? @return the result
 ??? where the repetition is unlikely to occur elsewhere

2. "Disjoint repetition", such as repeated occurrences of
 ???? @throws IOException if something occurrs
 ??? which will be found at most once per method, but may appear on many 
methods

We can (separately) discuss #2, preferably in the context of a different 
JBS issue, and wearing sticky rubber shoes to avoid falling down the 
cliff of a general macro-substitution language.

-- Jon

On 12/3/20 1:19 PM, Joe Darcy wrote:
>
>     There is lots of other duplication/repetition in most javadoc. I'd
>     rather see some kind of text macro that would allow a single
>     definition of a string that can be repeated. The source would be a
>     bit less readable, but it would be lower maintenance when the same
>     phrase or sentence is repeated to make the javadoc more locally
>     complete and easier to read in isolation. Now many times do you
>     have to say "throws NullPointerException when the reference is
>     null" or similar assertion.
>
> IMO this is a case to avoid the perfect being the enemy of the good. 
> There are many structural cases of repeated or nearly repeated return 
> information in the first sentence and @return 
> <https://urldefense.com/v3/__https://github.com/return__;!!GqivPVa7Brio!IUSEgZPlNh-w3R__hVpDuJiQuNZLQOKs4VXEe9tW9B3d2Aem9DM3WVH-17FJKDhTvrReYw$> 
> tag. Therefore, I think it is reasonable for don't-repeat-yourself 
> purposes to have dedicated support for this usage pattern.
>
> Separately, I agree it would be helpful to have a more general 
> facility to allow structured placement of repeated text blocks.
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/1355*issuecomment-738325017__;Iw!!GqivPVa7Brio!IUSEgZPlNh-w3R__hVpDuJiQuNZLQOKs4VXEe9tW9B3d2Aem9DM3WVH-17FJKDh4e-tvuw$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRT2VKB4GPG5D2FQJBDSS76HVANCNFSM4T5BHLXA__;!!GqivPVa7Brio!IUSEgZPlNh-w3R__hVpDuJiQuNZLQOKs4VXEe9tW9B3d2Aem9DM3WVH-17FJKDjzD260_w$>.
>

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

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

From ihse at openjdk.java.net  Fri Dec  4 10:28:30 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 10:28:30 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective module
Message-ID: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>

A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 

These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 

This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.

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

Commit messages:
 - Update references in test
 - Step 2: Update references
 - First stage, move actual data files

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

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

From ihse at openjdk.java.net  Fri Dec  4 10:32:11 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 10:32:11 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>

On Thu, 3 Dec 2020 23:44:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.

To facilitate review, here is a list on how the different directories under make/data has moved.

**To java.base:**
* blacklistedcertsconverter
* cacerts
* characterdata
* charsetmapping
* cldr
* currency
* lsrdata
* publicsuffixlist
* tzdata
* unicodedata

**To java.desktop:**
* dtdbuilder
* fontconfig
* macosxicons
* x11wrappergen

**To jdk.compiler:**
* symbols

**To jdk.jdi:**
* jdwp

**Remaining in make:**
* bundle
* docs-resources
* macosxsigning
* mainmanifest

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

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

From alanb at openjdk.java.net  Fri Dec  4 11:17:12 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 4 Dec 2020 11:17:12 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
Message-ID: <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>

On Fri, 4 Dec 2020 10:29:48 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>
> To facilitate review, here is a list on how the different directories under make/data has moved.
> 
> **To java.base:**
> * blacklistedcertsconverter
> * cacerts
> * characterdata
> * charsetmapping
> * cldr
> * currency
> * lsrdata
> * publicsuffixlist
> * tzdata
> * unicodedata
> 
> **To java.desktop:**
> * dtdbuilder
> * fontconfig
> * macosxicons
> * x11wrappergen
> 
> **To jdk.compiler:**
> * symbols
> 
> **To jdk.jdi:**
> * jdwp
> 
> **Remaining in make:**
> * bundle
> * docs-resources
> * macosxsigning
> * mainmanifest

Are you proposing any text or guidelines to be added to JEP 201 as part of this?

I think the location of jdwp.spec and its location in the build tree may need to be looked at again. It was convenient to have it in the make tree, from which the protocol spec, and source code for the front end (module jdk.jdi) and a header file for the back end (module jdk.jdwp.agent) are created. Given that the JDWP protocol is standard (not JDK-specific) then there may be an argument to put it in src/java.se instead of a JDK-specific module.

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

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

From ihse at openjdk.java.net  Fri Dec  4 11:42:15 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 11:42:15 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
Message-ID: <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>

On Fri, 4 Dec 2020 11:37:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Are you proposing any text or guidelines to be added to JEP 201 as part of this?
>> 
>> I think the location of jdwp.spec and its location in the build tree may need to be looked at again. It was convenient to have it in the make tree, from which the protocol spec, and source code for the front end (module jdk.jdi) and a header file for the back end (module jdk.jdwp.agent) are created. Given that the JDWP protocol is standard (not JDK-specific) then there may be an argument to put it in src/java.se instead of a JDK-specific module.
>
> @AlanBateman Well, I don't know about updating JEP 201. Do you mean that `data` should be added to the list `classes`, `native`, `conf`, `legal` as presented under the heading "New scheme"? That list does not seem to have been kept up to date anyway. A quick glance also shows that we now have at least `man` and `lib` as well in this place. So either we say there's precedence for not updating the list, in which case I will do nothing. Or we should bring JEP 201 up-to-date with current practices, which then of course should include `data` but also all other new directories that has been added since JEP 201 was written.
> 
> I really don't care either way, but my personal opinion is that JEP 201 presented a view on how the plan was to re-organize things, given the knowledge and state of affairs at that time, but how we keep the source code organized and structured from there on, is a living, day-to-day engineering effort that is just hampered by having to update a formal document, that serves little purpose now that it has been implemented.

And I can certainly move jdwp.spec to java.base instead. That's the reason I need input on this: All I know is that is definitely not the responsibility of the Build Group to maintain that document, and I made my best guess at where to place it.

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

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

From ihse at openjdk.java.net  Fri Dec  4 11:42:15 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 11:42:15 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
Message-ID: <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>

On Fri, 4 Dec 2020 11:14:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> To facilitate review, here is a list on how the different directories under make/data has moved.
>> 
>> **To java.base:**
>> * blacklistedcertsconverter
>> * cacerts
>> * characterdata
>> * charsetmapping
>> * cldr
>> * currency
>> * lsrdata
>> * publicsuffixlist
>> * tzdata
>> * unicodedata
>> 
>> **To java.desktop:**
>> * dtdbuilder
>> * fontconfig
>> * macosxicons
>> * x11wrappergen
>> 
>> **To jdk.compiler:**
>> * symbols
>> 
>> **To jdk.jdi:**
>> * jdwp
>> 
>> **Remaining in make:**
>> * bundle
>> * docs-resources
>> * macosxsigning
>> * mainmanifest
>
> Are you proposing any text or guidelines to be added to JEP 201 as part of this?
> 
> I think the location of jdwp.spec and its location in the build tree may need to be looked at again. It was convenient to have it in the make tree, from which the protocol spec, and source code for the front end (module jdk.jdi) and a header file for the back end (module jdk.jdwp.agent) are created. Given that the JDWP protocol is standard (not JDK-specific) then there may be an argument to put it in src/java.se instead of a JDK-specific module.

@AlanBateman Well, I don't know about updating JEP 201. Do you mean that `data` should be added to the list `classes`, `native`, `conf`, `legal` as presented under the heading "New scheme"? That list does not seem to have been kept up to date anyway. A quick glance also shows that we now have at least `man` and `lib` as well in this place. So either we say there's precedence for not updating the list, in which case I will do nothing. Or we should bring JEP 201 up-to-date with current practices, which then of course should include `data` but also all other new directories that has been added since JEP 201 was written.

I really don't care either way, but my personal opinion is that JEP 201 presented a view on how the plan was to re-organize things, given the knowledge and state of affairs at that time, but how we keep the source code organized and structured from there on, is a living, day-to-day engineering effort that is just hampered by having to update a formal document, that serves little purpose now that it has been implemented.

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

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

From alanb at openjdk.java.net  Fri Dec  4 12:33:15 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 4 Dec 2020 12:33:15 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
Message-ID: <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>

On Fri, 4 Dec 2020 11:38:51 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> And I can certainly move jdwp.spec to java.base instead. 

If jdwp.spec has to move to the src tree then src/java.se is probably the most suitable home because Java SE specifies JDWP as an optional interface. So nothing to do with java.base and the build will need to continue to generate the sources for the front-end (jdk.jdi) and back-end (jdk.jdwp.agent) as they implement the protocol.

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

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

From jlahoda at openjdk.java.net  Fri Dec  4 13:12:27 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 4 Dec 2020 13:12:27 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v5]
In-Reply-To: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
Message-ID: <LUcxVrYfFDegMxVEhbpB2dN6MfLiDl_DrzAR3GiZ9nI=.c8b1293d-2c5f-4775-8b33-5d954080586a@github.com>

> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
> 
> From the original PR:
> 
>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>> 
>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>> 
>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>> 
>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>> 
>>     * adding code to make sure that annotations can't be sealed
>> 
>>     * improving some tests
>> 
>> 
>> TIA
>> 
>> Related specs:
>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
> 
> This PR strives to reflect the review comments from 1227:
>  * adjustments to javadoc of j.l.Class methods
>  * package access checks in Class.getPermittedSubclasses()
>  * fixed to the narrowing conversion/castability as pointed out by Maurizio

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

  Cleanup as suggested on the review.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1483/files
  - new: https://git.openjdk.java.net/jdk/pull/1483/files/537e267f..09e0c186

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1483&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1483&range=03-04

  Stats: 187 lines in 7 files changed: 38 ins; 114 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1483.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1483/head:pull/1483

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

From alanb at openjdk.java.net  Fri Dec  4 13:29:18 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 4 Dec 2020 13:29:18 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v5]
In-Reply-To: <LUcxVrYfFDegMxVEhbpB2dN6MfLiDl_DrzAR3GiZ9nI=.c8b1293d-2c5f-4775-8b33-5d954080586a@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <LUcxVrYfFDegMxVEhbpB2dN6MfLiDl_DrzAR3GiZ9nI=.c8b1293d-2c5f-4775-8b33-5d954080586a@github.com>
Message-ID: <WbHrZ_giclHB1trM5DJsbGpRnO0md8m7G_6GXMpR-TY=.b763baa2-810d-41d4-aa5b-c313e7ed06b9@github.com>

On Fri, 4 Dec 2020 13:12:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>> 
>> From the original PR:
>> 
>>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>>> 
>>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>>> 
>>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>>> 
>>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>>> 
>>>     * adding code to make sure that annotations can't be sealed
>>> 
>>>     * improving some tests
>>> 
>>> 
>>> TIA
>>> 
>>> Related specs:
>>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
>> 
>> This PR strives to reflect the review comments from 1227:
>>  * adjustments to javadoc of j.l.Class methods
>>  * package access checks in Class.getPermittedSubclasses()
>>  * fixed to the narrowing conversion/castability as pointed out by Maurizio
>
> Jan Lahoda has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/java/lang/Class.java line 3043:

> 3041:             for (Class<?> c : subClasses) {
> 3042:                 if (Proxy.isProxyClass(c))
> 3043:                         throw new InternalError("a permitted subclass should not be a proxy class: " + c);

Minor nit but I think the indentation may be messed up here.

src/java.base/share/classes/java/lang/Class.java line 4394:

> 4392:      * implement this class or interface if it is sealed. The order of such elements
> 4393:      * is unspecified. If this {@code Class} object represents a primitive type,
> 4394:      * {@code void}, an array type, or a class or interface that is not sealed,

Did you mean {@code Void} here?

src/java.base/share/classes/java/lang/Class.java line 4403:

> 4401:      * loader} of the current {@code Class} object).
> 4402:      * The {@code Class} objects which can be obtained using this procedure,
> 4403:      * and which are direct subinterfaces or subclasses of this class or interface,

Minor suggestion is to drop "using this procedure" from this sentence.

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

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

From erikj at openjdk.java.net  Fri Dec  4 14:08:13 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 4 Dec 2020 14:08:13 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
 <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
Message-ID: <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>

On Fri, 4 Dec 2020 12:30:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> And I can certainly move jdwp.spec to java.base instead. That's the reason I need input on this: All I know is that is definitely not the responsibility of the Build Group to maintain that document, and I made my best guess at where to place it.
>
>> And I can certainly move jdwp.spec to java.base instead. 
> 
> If jdwp.spec has to move to the src tree then src/java.se is probably the most suitable home because Java SE specifies JDWP as an optional interface. So nothing to do with java.base and the build will need to continue to generate the sources for the front-end (jdk.jdi) and back-end (jdk.jdwp.agent) as they implement the protocol.

My understanding of JEPs is that they should be viewed as living documents. In this case, I think it's perfectly valid to update JEP 201 with additional source code layout. Both for this and for the other missing dirs.

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

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

From erikj at openjdk.java.net  Fri Dec  4 14:08:13 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 4 Dec 2020 14:08:13 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
 <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
 <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>
Message-ID: <OSoR2xzJPwFPcdNySvft80baeIKW_uQhLLfpacsvqlU=.3892243b-69f5-458d-b63c-eb101e96860f@github.com>

On Fri, 4 Dec 2020 14:03:08 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>>> And I can certainly move jdwp.spec to java.base instead. 
>> 
>> If jdwp.spec has to move to the src tree then src/java.se is probably the most suitable home because Java SE specifies JDWP as an optional interface. So nothing to do with java.base and the build will need to continue to generate the sources for the front-end (jdk.jdi) and back-end (jdk.jdwp.agent) as they implement the protocol.
>
> My understanding of JEPs is that they should be viewed as living documents. In this case, I think it's perfectly valid to update JEP 201 with additional source code layout. Both for this and for the other missing dirs.

Regarding the chosen layout. Did you consider following the existing pattern of src/<module>/{share,<OS>}/data?

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

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

From mcimadamore at openjdk.java.net  Fri Dec  4 15:10:12 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 4 Dec 2020 15:10:12 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v5]
In-Reply-To: <LUcxVrYfFDegMxVEhbpB2dN6MfLiDl_DrzAR3GiZ9nI=.c8b1293d-2c5f-4775-8b33-5d954080586a@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <LUcxVrYfFDegMxVEhbpB2dN6MfLiDl_DrzAR3GiZ9nI=.c8b1293d-2c5f-4775-8b33-5d954080586a@github.com>
Message-ID: <7mxDajR7S_ajQQLny222__jY2QXcUbKksdcK67jjir4=.fa29bd7f-24f3-4e3f-8aea-3979699ba3a5@github.com>

On Fri, 4 Dec 2020 13:12:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>> 
>> From the original PR:
>> 
>>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>>> 
>>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>>> 
>>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>>> 
>>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>>> 
>>>     * adding code to make sure that annotations can't be sealed
>>> 
>>>     * improving some tests
>>> 
>>> 
>>> TIA
>>> 
>>> Related specs:
>>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
>> 
>> This PR strives to reflect the review comments from 1227:
>>  * adjustments to javadoc of j.l.Class methods
>>  * package access checks in Class.getPermittedSubclasses()
>>  * fixed to the narrowing conversion/castability as pointed out by Maurizio
>
> Jan Lahoda has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Compiler changes look good to me

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

Marked as reviewed by mcimadamore (Reviewer).

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

From ihse at openjdk.java.net  Fri Dec  4 15:20:14 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Fri, 4 Dec 2020 15:20:14 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <OSoR2xzJPwFPcdNySvft80baeIKW_uQhLLfpacsvqlU=.3892243b-69f5-458d-b63c-eb101e96860f@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
 <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
 <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>
 <OSoR2xzJPwFPcdNySvft80baeIKW_uQhLLfpacsvqlU=.3892243b-69f5-458d-b63c-eb101e96860f@github.com>
Message-ID: <z45KICeqOUoy0FjsoQ-eraI48oEz0usWhcSlj7xPjhk=.b2100840-eecd-4f70-b0b7-eb78144d3f0e@github.com>

On Fri, 4 Dec 2020 14:05:54 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> My understanding of JEPs is that they should be viewed as living documents. In this case, I think it's perfectly valid to update JEP 201 with additional source code layout. Both for this and for the other missing dirs.
>
> Regarding the chosen layout. Did you consider following the existing pattern of src/<module>/{share,<OS>}/data?

@erikj79 Good point, that makes much more sense.

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

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

From jlahoda at openjdk.java.net  Fri Dec  4 16:22:28 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 4 Dec 2020 16:22:28 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v6]
In-Reply-To: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
Message-ID: <DaZ55MT-Ov2HMHOdfz_JAbfrfoSJaVHVhOuaQyBOa88=.0888af56-f57f-4180-87ac-539ce126333d@github.com>

> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
> 
> From the original PR:
> 
>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>> 
>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>> 
>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>> 
>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>> 
>>     * adding code to make sure that annotations can't be sealed
>> 
>>     * improving some tests
>> 
>> 
>> TIA
>> 
>> Related specs:
>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
> 
> This PR strives to reflect the review comments from 1227:
>  * adjustments to javadoc of j.l.Class methods
>  * package access checks in Class.getPermittedSubclasses()
>  * fixed to the narrowing conversion/castability as pointed out by Maurizio

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

  Cleanup as suggested on the review.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1483/files
  - new: https://git.openjdk.java.net/jdk/pull/1483/files/09e0c186..b5304057

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1483&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1483&range=04-05

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

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

From jlahoda at openjdk.java.net  Fri Dec  4 16:25:15 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 4 Dec 2020 16:25:15 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v5]
In-Reply-To: <WbHrZ_giclHB1trM5DJsbGpRnO0md8m7G_6GXMpR-TY=.b763baa2-810d-41d4-aa5b-c313e7ed06b9@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <LUcxVrYfFDegMxVEhbpB2dN6MfLiDl_DrzAR3GiZ9nI=.c8b1293d-2c5f-4775-8b33-5d954080586a@github.com>
 <WbHrZ_giclHB1trM5DJsbGpRnO0md8m7G_6GXMpR-TY=.b763baa2-810d-41d4-aa5b-c313e7ed06b9@github.com>
Message-ID: <-NIy_0DQvgBZJOTV-nOL86tfgrG8nDsDwG1JUHFxJcQ=.928907ab-f273-4ab5-aaf8-645f32bb3da4@github.com>

On Fri, 4 Dec 2020 13:25:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> src/java.base/share/classes/java/lang/Class.java line 4394:
> 
>> 4392:      * implement this class or interface if it is sealed. The order of such elements
>> 4393:      * is unspecified. If this {@code Class} object represents a primitive type,
>> 4394:      * {@code void}, an array type, or a class or interface that is not sealed,
> 
> Did you mean {@code Void} here?

I think this means `void.class`. `void.class` is a little special (as are the Class objects for primitive types, like `int.class`), but Void.class or Integer.class are not so much special.

I've updated the patch based on the other comments - thanks!

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Fri Dec  4 16:27:24 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Fri, 4 Dec 2020 16:27:24 GMT
Subject: RFR: 8231622: SuppressWarning("serial") ignored on field
 serialVersionUID
Message-ID: <_2Z8RhLQo1F6ddk2cZS5J_hoRMPLCe5ssVMeyyscFnc=.d267dddd-12d6-4968-a32d-6bd3510daf45@github.com>

Hi all,

Currently, a warning is generated when compiling the following code by using the option `-Xlint`.

import java.io.Serializable;
class B implements Serializable {
    @SuppressWarnings("serial")
    private static final byte serialVersionUID = 5;
}

output:
A.java:10: warning: [serial] serialVersionUID must be of type long in class B
    private static final byte serialVersionUID = 5;
                              ^
1 warning

The annotation `@SuppressWarnings("serial")` on  field serialVersionUID is ignored by the compiler.
This patch fixes it and adds some tests.
Thank you for taking the time to review.

Best Regards.

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

Commit messages:
 - 8231622: SuppressWarning(serial) ignored on field serialVersionUID

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

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

From chegar at openjdk.java.net  Fri Dec  4 16:37:16 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 4 Dec 2020 16:37:16 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v6]
In-Reply-To: <DaZ55MT-Ov2HMHOdfz_JAbfrfoSJaVHVhOuaQyBOa88=.0888af56-f57f-4180-87ac-539ce126333d@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <DaZ55MT-Ov2HMHOdfz_JAbfrfoSJaVHVhOuaQyBOa88=.0888af56-f57f-4180-87ac-539ce126333d@github.com>
Message-ID: <VXlOs7pR8sYRDehzuf4JftBQfgPwtPOgVhSkhqCoFzU=.2374d3d1-898b-4cff-add0-881a57e1d5de@github.com>

On Fri, 4 Dec 2020 16:22:28 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>> 
>> From the original PR:
>> 
>>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>>> 
>>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>>> 
>>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>>> 
>>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>>> 
>>>     * adding code to make sure that annotations can't be sealed
>>> 
>>>     * improving some tests
>>> 
>>> 
>>> TIA
>>> 
>>> Related specs:
>>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
>> 
>> This PR strives to reflect the review comments from 1227:
>>  * adjustments to javadoc of j.l.Class methods
>>  * package access checks in Class.getPermittedSubclasses()
>>  * fixed to the narrowing conversion/castability as pointed out by Maurizio
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup as suggested on the review.

Marked as reviewed by chegar (Reviewer).

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

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

From jjg at openjdk.java.net  Fri Dec  4 17:27:16 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 4 Dec 2020 17:27:16 GMT
Subject: RFR: 8231622: SuppressWarning("serial") ignored on field
 serialVersionUID
In-Reply-To: <_2Z8RhLQo1F6ddk2cZS5J_hoRMPLCe5ssVMeyyscFnc=.d267dddd-12d6-4968-a32d-6bd3510daf45@github.com>
References: <_2Z8RhLQo1F6ddk2cZS5J_hoRMPLCe5ssVMeyyscFnc=.d267dddd-12d6-4968-a32d-6bd3510daf45@github.com>
Message-ID: <7pKHc5G19_52b3VTxU-iAj1aLwWzAKYaK2fI57AmiSw=.c2c52e2d-b8aa-470f-9acd-0a2890b7dcda@github.com>

On Fri, 4 Dec 2020 16:21:28 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> Currently, a warning is generated when compiling the following code by using the option `-Xlint`.
> 
> import java.io.Serializable;
> class B implements Serializable {
>     @SuppressWarnings("serial")
>     private static final byte serialVersionUID = 5;
> }
> 
> output:
> B.java:4: warning: [serial] serialVersionUID must be of type long in class B
>     private static final byte serialVersionUID = 5;
>                               ^
> 1 warning
> 
> The annotation `@SuppressWarnings("serial")` on  field serialVersionUID is ignored by the compiler.
> This patch fixes it and adds some tests.
> Thank you for taking the time to review.
> 
> Best Regards.

For tests that use `/ref=file` `-XDrawDiagnostics` the conventions are:

1. Omit the complete legal header, including the copyright and license
2. After `@test` add the text `/nodynamiccopyright/`

#1 protects the file against any future changes in the length of the legal header, that might affect line numbers, and #2 is for use by automated scripts that may check for the presence of the legal header.

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

Changes requested by jjg (Reviewer).

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

From mchung at openjdk.java.net  Fri Dec  4 18:00:16 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 4 Dec 2020 18:00:16 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v6]
In-Reply-To: <DaZ55MT-Ov2HMHOdfz_JAbfrfoSJaVHVhOuaQyBOa88=.0888af56-f57f-4180-87ac-539ce126333d@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <DaZ55MT-Ov2HMHOdfz_JAbfrfoSJaVHVhOuaQyBOa88=.0888af56-f57f-4180-87ac-539ce126333d@github.com>
Message-ID: <EOo8pINh1tJ1FTwpi1LOfaL9p8Vw-dkSH03UPF3oOf0=.af50f10d-8421-4541-bd87-c85c7d8abb37@github.com>

On Fri, 4 Dec 2020 16:22:28 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>> 
>> From the original PR:
>> 
>>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>>> 
>>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>>> 
>>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>>> 
>>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>>> 
>>>     * adding code to make sure that annotations can't be sealed
>>> 
>>>     * improving some tests
>>> 
>>> 
>>> TIA
>>> 
>>> Related specs:
>>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
>> 
>> This PR strives to reflect the review comments from 1227:
>>  * adjustments to javadoc of j.l.Class methods
>>  * package access checks in Class.getPermittedSubclasses()
>>  * fixed to the narrowing conversion/castability as pointed out by Maurizio
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup as suggested on the review.

Marked as reviewed by mchung (Reviewer).

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Fri Dec  4 18:26:36 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Fri, 4 Dec 2020 18:26:36 GMT
Subject: RFR: 8231622: SuppressWarning("serial") ignored on field
 serialVersionUID [v2]
In-Reply-To: <_2Z8RhLQo1F6ddk2cZS5J_hoRMPLCe5ssVMeyyscFnc=.d267dddd-12d6-4968-a32d-6bd3510daf45@github.com>
References: <_2Z8RhLQo1F6ddk2cZS5J_hoRMPLCe5ssVMeyyscFnc=.d267dddd-12d6-4968-a32d-6bd3510daf45@github.com>
Message-ID: <EFt3JG5qibOriEpCuxCta2jxN-VSGYfkveexxYo9E0Q=.0a706fd2-62ca-4ff9-ae0d-69ed8c5edd28@github.com>

> Hi all,
> 
> Currently, a warning is generated when compiling the following code by using the option `-Xlint`.
> 
> import java.io.Serializable;
> class B implements Serializable {
>     @SuppressWarnings("serial")
>     private static final byte serialVersionUID = 5;
> }
> 
> output:
> B.java:4: warning: [serial] serialVersionUID must be of type long in class B
>     private static final byte serialVersionUID = 5;
>                               ^
> 1 warning
> 
> The annotation `@SuppressWarnings("serial")` on  field serialVersionUID is ignored by the compiler.
> This patch fixes it and adds some tests.
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Revise test cases. Remove legal header and add /nodynamiccopyright/

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1626/files
  - new: https://git.openjdk.java.net/jdk/pull/1626/files/877e4b82..16eeaa56

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

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Fri Dec  4 18:38:13 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Fri, 4 Dec 2020 18:38:13 GMT
Subject: RFR: 8231622: SuppressWarning("serial") ignored on field
 serialVersionUID [v2]
In-Reply-To: <7pKHc5G19_52b3VTxU-iAj1aLwWzAKYaK2fI57AmiSw=.c2c52e2d-b8aa-470f-9acd-0a2890b7dcda@github.com>
References: <_2Z8RhLQo1F6ddk2cZS5J_hoRMPLCe5ssVMeyyscFnc=.d267dddd-12d6-4968-a32d-6bd3510daf45@github.com>
 <7pKHc5G19_52b3VTxU-iAj1aLwWzAKYaK2fI57AmiSw=.c2c52e2d-b8aa-470f-9acd-0a2890b7dcda@github.com>
Message-ID: <4goARqQD66tV2vjOvFDNRKH4qTNdcMEcvcEQ0pemyTE=.b361dcd5-5438-4bc8-97f3-2189aaa2782c@github.com>

On Fri, 4 Dec 2020 17:24:39 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revise test cases. Remove legal header and add /nodynamiccopyright/
>
> For tests that use `/ref=file` `-XDrawDiagnostics` the conventions are:
> 
> 1. Omit the complete legal header, including the copyright and license
> 2. After `@test` add the text `/nodynamiccopyright/`
> 
> #1 protects the file against any future changes in the length of the legal header, that might affect line numbers, and #2 is for use by automated scripts that may check for the presence of the legal header.

Thank you for your comment. I revise my code according to your suggestion.

And I found some previous tests use the wrong style which are like this patch. I want to modify them so that these tests won't mislead other developers, especially the new developers. Could I get your help to open a new issue about it in the bug tracker? Thanks a lot.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Fri Dec  4 19:10:26 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Fri, 4 Dec 2020 19:10:26 GMT
Subject: RFR: 8257037: No javac warning when calling deprecated
 constructor with diamond [v4]
In-Reply-To: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
References: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
Message-ID: <D1mNa7jauVM8XUPOJw953-X3cU6NDTJmHDDnOQT44u4=.eebf3b1d-31c5-4bb6-826e-c67f8527cb40@github.com>

> Hi all,
> 
> When calling deprecated constructor with diamond, the compiler doesn't output warning.
> The test case is shown below.
> 
> GenericClass<Object> o2 = new GenericClass<>();
> 
> public class GenericClass<T> {
>     @Deprecated
>     public GenericClass() {}
> }
> 
> This patch solves the bug and adds corresponding test case.
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Revise test. Remove legal header and add /nodynamiccopyright/.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1490/files
  - new: https://git.openjdk.java.net/jdk/pull/1490/files/66671b02..1d06ad1c

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

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Fri Dec  4 19:14:17 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Fri, 4 Dec 2020 19:14:17 GMT
Subject: RFR: 8257037: No javac warning when calling deprecated
 constructor with diamond [v2]
In-Reply-To: <Crrqea3jLo_w2Ewqvv7dPRGdni2RaqduZQq1GC-pOHc=.bfd96ad5-a12d-43b0-9422-cf596461eda7@github.com>
References: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
 <1U2EbJB1lDsbvdq9BmjwSmKaX0uXBapxvXC8ZiCkQj8=.f9a2cd1d-0870-488a-bf0d-7cedef2a3ec0@github.com>
 <zVIqNvzBoibgKiouyfuWtVVlKZ1QdVKwT3Ogcponqks=.5a22a17f-7a26-4826-9d80-27bc4c205fde@github.com>
 <NqTbEGQXGYXlBxBC0_3Alw-IXhhputmHK1dUOVxLZjk=.45b3870a-85c4-4916-bf60-2a0650223b7d@github.com>
 <ke-vuOhulPGGdca1vg_kJK4wTSVBZKMLBFpw-8yVulE=.e22c36b3-fad5-473c-bf9f-6163e5c88e3c@github.com>
 <Crrqea3jLo_w2Ewqvv7dPRGdni2RaqduZQq1GC-pOHc=.bfd96ad5-a12d-43b0-9422-cf596461eda7@github.com>
Message-ID: <ElFhPSiZ-la4Mw8wGHwwY2MyTubIsKoOzCtMD6ryjH8=.7c59caac-6e7f-4fc8-b267-08eb0b20e915@github.com>

On Wed, 2 Dec 2020 12:15:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>>  Is the code `newConstr.setAttributes(sym);` necessary in `Resolve.findDiamond`?
>> 
>> Sorry, that was a leftover from a previous experiment. That's not necessary. We'll run some more tests on our side and I'll let you know.
>
>> @mcimadamore Should I add you as a contributor of this patch? Does it need another reviewer to review if I add you as a contributor?
> 
> As you prefer - I don't mind either way. I don't think adding me as a contributor should prevent the integration, or me being able to sponsor, but I'm not 100% sure.

I revise the test code based on the comment[1] written by Jonathan Gibbons in JDK-8231622[2].

> For tests that use /ref=file -XDrawDiagnostics the conventions are:
>
>   1. Omit the complete legal header, including the copyright and license
>   2. After `@test` add the text `/nodynamiccopyright/`
>
> #1 protects the file against any future changes in the length of the legal header, that might affect line numbers, and #2 is for use by automated scripts that may check for the presence of the legal header.

[1] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015542.html
[2] https://github.com/openjdk/jdk/pull/1626

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

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

From dholmes at openjdk.java.net  Fri Dec  4 21:18:25 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 4 Dec 2020 21:18:25 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <CTnFzbQhHf79FoMWvRAR8ud8dGNC9xMI2gSyTcBzCgg=.4147b8c4-7019-42f3-8d2c-bb4a133c8010@github.com>

On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Start of JDK 17 updates.

Looks good - 99% sym stuff :)

Doesn't look like the hotspot deprecated flag test will need updating this time, as no newly deprecated flags marked for obsoletion in 17.

src/hotspot/share/opto/type.cpp line 827:

> 825:     tty->print("this meet t = ");  mt->dump(); tty->cr();
> 826:     fatal("meet not commutative");
> 827:   }

Merge issue??

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 226:

> 224:         REIFIABLE_TYPES_INSTANCEOF(JDK16, Fragments.FeatureReifiableTypesInstanceof, DiagKind.PLURAL),
> 225:         RECORDS(JDK16, Fragments.FeatureRecords, DiagKind.PLURAL),
> 226:         SEALED_CLASSES(JDK17, Fragments.FeatureSealedClasses, DiagKind.PLURAL),

Is this changed because it is still preview?

test/hotspot/gtest/aarch64/test_assembler_aarch64.cpp line 27:

> 25: #include "precompiled.hpp"
> 26: 
> 27: #if defined(AARCH64) && !defined(ZERO)

Another merge issue.

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

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

From darcy at openjdk.java.net  Fri Dec  4 21:18:24 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 4 Dec 2020 21:18:24 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17
Message-ID: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>

Start of JDK 17 updates.

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

Commit messages:
 - Update tests.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - JDK-8257450
 - JDK-8257450
 - JDK-8257450

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

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

From darcy at openjdk.java.net  Fri Dec  4 21:18:26 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 4 Dec 2020 21:18:26 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17
In-Reply-To: <CTnFzbQhHf79FoMWvRAR8ud8dGNC9xMI2gSyTcBzCgg=.4147b8c4-7019-42f3-8d2c-bb4a133c8010@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <CTnFzbQhHf79FoMWvRAR8ud8dGNC9xMI2gSyTcBzCgg=.4147b8c4-7019-42f3-8d2c-bb4a133c8010@github.com>
Message-ID: <RS0Rrb2Y9eXAkmTK329-XMjyges2w0ZgdTC_SZ1wsUU=.56a864c4-eb3b-4377-9e50-cacba75bb09e@github.com>

On Tue, 1 Dec 2020 07:33:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Start of JDK 17 updates.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 226:
> 
>> 224:         REIFIABLE_TYPES_INSTANCEOF(JDK16, Fragments.FeatureReifiableTypesInstanceof, DiagKind.PLURAL),
>> 225:         RECORDS(JDK16, Fragments.FeatureRecords, DiagKind.PLURAL),
>> 226:         SEALED_CLASSES(JDK17, Fragments.FeatureSealedClasses, DiagKind.PLURAL),
> 
> Is this changed because it is still preview?

Right; JEP 397: "Sealed Classes (Second Preview)" is PTT for JDk 16.

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

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

From darcy at openjdk.java.net  Fri Dec  4 21:23:18 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 4 Dec 2020 21:23:18 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17
In-Reply-To: <CTnFzbQhHf79FoMWvRAR8ud8dGNC9xMI2gSyTcBzCgg=.4147b8c4-7019-42f3-8d2c-bb4a133c8010@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <CTnFzbQhHf79FoMWvRAR8ud8dGNC9xMI2gSyTcBzCgg=.4147b8c4-7019-42f3-8d2c-bb4a133c8010@github.com>
Message-ID: <aEIXWZVOaU_jBt6s_VlfTERREpWRy9qZsg_m6GOiimI=.961d6ffd-b55f-46a9-96ab-61b9c781ebdd@github.com>

On Tue, 1 Dec 2020 07:38:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Start of JDK 17 updates.
>
> Looks good - 99% sym stuff :)
> 
> Doesn't look like the hotspot deprecated flag test will need updating this time, as no newly deprecated flags marked for obsoletion in 17.

Usual start of release update:

* Expected version number updates in the make system
* New set of data files to support --release 16 in javac
* Update to various version-related langtools APIs and tests
* Minor N -> N+1 updates in vm and vm tests

One javadoc test that failed under the new version was fixed before this PR was sent out.

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

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

From erikj at openjdk.java.net  Fri Dec  4 21:38:11 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 4 Dec 2020 21:38:11 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <5-1l9r81KZj0_g84xfhxSzfzrjggP8SzM1dpOkk5r_Q=.a8e26b00-c810-4458-abd7-131c92aeee02@github.com>

On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Start of JDK 17 updates.

Build changes look good and I'm happy there are so few of them!

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

Marked as reviewed by erikj (Reviewer).

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

From iris at openjdk.java.net  Sat Dec  5 01:37:14 2020
From: iris at openjdk.java.net (Iris Clark)
Date: Sat, 5 Dec 2020 01:37:14 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <Qm7rFfBjXUwEryKrvSlMVO8ojj1onPhfGGGo9kVze14=.6ffd9c05-f2c9-406f-a004-a549e7591437@github.com>

On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Start of JDK 17 updates.

Marked as reviewed by iris (Reviewer).

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

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

From dlsmith at openjdk.java.net  Sat Dec  5 01:52:21 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Sat, 5 Dec 2020 01:52:21 GMT
Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for
 removal
Message-ID: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>

Integration of JEP 390, addressing the following issues:

8252180: [JEP 390] Deprecate wrapper class constructors for removal
8254047: [JEP 390] Revise "value-based class" & apply to wrappers
8252181: [JEP 390] Define & apply annotation jdk.internal.ValueBased
8252183: [JEP 390] Add 'lint' warning for @ValueBased classes
8257027: [JEP 390] Diagnose synchronization on @ValueBased classes

See https://github.com/openjdk/valhalla/tree/jep390 for development history.

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

Commit messages:
 - Merge
 - 8257776: [valhalla:jep390] Add disclaimer about future changes to value-based classes
 - 8254275: [valhalla/jep390] Revise "value-based class" & apply to wrappers
 - 8252182: [JEP 390] Diagnose synchronization on @ValueBased classes
 - Merge
 - 8256663: [test] Deprecated use of new Double in jshell ImportTest
 - 8253962: Add @ValueBased to unmodifable Collection implementation classes
 - 8256002: Cleanup of Wrapper changes
 - Merge
 - 8254271: Development to deprecate wrapper class constructors for removal
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/93b6ab56...7c5e5bfe

Changes: https://git.openjdk.java.net/jdk/pull/1636/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1636&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8252180
  Stats: 902 lines in 114 files changed: 489 ins; 121 del; 292 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1636.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1636/head:pull/1636

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

From dlsmith at openjdk.java.net  Sat Dec  5 03:07:11 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Sat, 5 Dec 2020 03:07:11 GMT
Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for
 removal
In-Reply-To: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>
References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>
Message-ID: <ame4i0yLoLSpT6rwqcO20lQzYRBLR9FiyD7EKHAKltA=.b12c8d8b-e470-45df-bb0c-1f7330be9545@github.com>

On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100).
> 
> Development has been broken into 5 tasks, each with its own JBS issue:
> - Deprecate wrapper class constructors for removal
> - Revise "value-based class" & apply to wrappers
> - Define & apply annotation jdk.internal.ValueBased
> - Add 'lint' warning for @ValueBased classes
> - Diagnose synchronization on @ValueBased classes
> 
> All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.)
> 
> CSRs have also been completed or are nearly complete:
> 
> - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation
> - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class"
> - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings
> 
> Here's an overview of the files changed:
> 
> - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes.
> 
> - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance.
> 
> - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation.
> 
> - `src/java.management.rmi`: removing uses of wrapper class constructors.
> 
> - `src/java.xml`: removing uses of wrapper class constructors.
> 
> - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`.
> 
> - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.)
> 
> - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests
> 
> - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics
> 
> - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`.

I've updated the description to provide an overview for those unfamiliar with this work. Reviewers are welcome, including those who have previously reviewed a subset of these changes.

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

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

From mikael at openjdk.java.net  Sat Dec  5 03:20:12 2020
From: mikael at openjdk.java.net (Mikael Vidstedt)
Date: Sat, 5 Dec 2020 03:20:12 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <EhQCAhIxxXIe8jvHvDQb_htw5IT66wq3F0axf02LquQ=.cff6c11e-e8e0-4f80-9213-e4c3ef0d64a8@github.com>

On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Start of JDK 17 updates.

Marked as reviewed by mikael (Reviewer).

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

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

From darcy at openjdk.java.net  Sat Dec  5 21:42:17 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 5 Dec 2020 21:42:17 GMT
Subject: RFR: 8257799: Update JLS cross-references in java.compiler
Message-ID: <X3bitfIhnWvSPBcNfBtVwarzCAXz5DK38ZWPM0pZ68Y=.def190bd-b039-42b0-84bc-912fbcf4a0c7@github.com>

A few of the @jls tags in the java.compiler module don't make the corresponding JLS section anymore; the null literal section and constant expression sections were renumbered.

This change makes corrects the mismatches.

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

Commit messages:
 - JDK-8257799

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Sun Dec  6 08:22:27 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sun, 6 Dec 2020 08:22:27 GMT
Subject: RFR: 8257740: Compiler crash when compiling type annotation on
 multicatch inside lambda
Message-ID: <yeW8wp7bMvNPXB4EdURtsvz_uvCtn2Szdcj2vBAgno8=.70964bd5-a6eb-4665-a6c8-2d1b61c1b91d@github.com>

Hi all,

When translating a lambda expression to method, the method `LambdaToMethod.LambdaAnalyzerPreprocessor.LambdaTranslationContext.translate(final Symbol sym, LambdaSymbolKind skind)` creates new VarSymbol(s) according to the old VarSymbol(s). But this `translate` method doesn't set the field `data`  of the new VarSymbol. Maybe it is because the field `data` is unused in later phase.

Unfortunately, `com.sun.tools.javac.jvm.Code.fillExceptionParameterPositions` and `com.sun.tools.javac.jvm.Code.fillLocalVarPosition` would use the field `data` if the `data` is `ElementKind.EXCEPTION_PARAMETER`.

It causes the exception_index won't be set in `fillExceptionParameterPositions`. Later, if the exception_index is used, the compiler will crash with error `java.lang.AssertionError: exception_index is not set`.

This patch fixes it and adds corresponding test cases.
In my patch, I only set the field ` data`  if  the `data` is `ElementKind.EXCEPTION_PARAMETER`. Because I don't see another situation that the field `data` would be used.

Thank your for taking the time to review.

Best Regards.

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

Commit messages:
 - 8257740: Compiler crash when compiling type annotation on multicatch inside lambda

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

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

From jlahoda at openjdk.java.net  Mon Dec  7 09:05:36 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 7 Dec 2020 09:05:36 GMT
Subject: RFR: 8256266: Declaration annotations don't work properly for
 binding variables [v2]
In-Reply-To: <7B3tW3Nouyc_OKLm9Be1H8VbeXVBL1WiRt8-V2ZwO2o=.02134c7e-2cc8-449f-a40d-bd6101150d0a@github.com>
References: <7B3tW3Nouyc_OKLm9Be1H8VbeXVBL1WiRt8-V2ZwO2o=.02134c7e-2cc8-449f-a40d-bd6101150d0a@github.com>
Message-ID: <sLZiKas6rvFwPNqz-kcLkalFjPgs0anCstFkIk5P-w8=.f8dc39b0-fe0d-4a20-96fc-f4d058157a70@github.com>

> Basically, javac does not handle code like this properly:
> 
> import java.lang.annotation.*;
> 
> public class B {
>      public void test(Object o) {
>          if (o instanceof @A String s) {}
>      }
> }
> 
> @Target(ElementType.LOCAL_VARIABLE)
> @interface A {}
> 
> The parser needs to allow declaration annotations on binding variables, see:
> http://cr.openjdk.java.net/~gbierman/jep394/jep394-20201012/specs/patterns-instanceof-jls.html#jls-14.30.1.1

Jan Lahoda 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 five additional commits since the last revision:

 - Merge branch 'JDK-8256266' of https://github.com/lahodaj/jdk into JDK-8256266
 - Removing an extra whitespace.
 - The 'final' modifier should be allowed on binding variables.
 - Merge branch 'master' into JDK-8256266
 - 8256266: Declaration annotations don't work properly for binding variables

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1192/files
  - new: https://git.openjdk.java.net/jdk/pull/1192/files/09bba916..f1551ef1

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

  Stats: 242691 lines in 2055 files changed: 158164 ins; 59697 del; 24830 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1192.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1192/head:pull/1192

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

From mcimadamore at openjdk.java.net  Mon Dec  7 10:43:14 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 7 Dec 2020 10:43:14 GMT
Subject: RFR: 8257037: No javac warning when calling deprecated
 constructor with diamond [v2]
In-Reply-To: <ElFhPSiZ-la4Mw8wGHwwY2MyTubIsKoOzCtMD6ryjH8=.7c59caac-6e7f-4fc8-b267-08eb0b20e915@github.com>
References: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
 <1U2EbJB1lDsbvdq9BmjwSmKaX0uXBapxvXC8ZiCkQj8=.f9a2cd1d-0870-488a-bf0d-7cedef2a3ec0@github.com>
 <zVIqNvzBoibgKiouyfuWtVVlKZ1QdVKwT3Ogcponqks=.5a22a17f-7a26-4826-9d80-27bc4c205fde@github.com>
 <NqTbEGQXGYXlBxBC0_3Alw-IXhhputmHK1dUOVxLZjk=.45b3870a-85c4-4916-bf60-2a0650223b7d@github.com>
 <ke-vuOhulPGGdca1vg_kJK4wTSVBZKMLBFpw-8yVulE=.e22c36b3-fad5-473c-bf9f-6163e5c88e3c@github.com>
 <Crrqea3jLo_w2Ewqvv7dPRGdni2RaqduZQq1GC-pOHc=.bfd96ad5-a12d-43b0-9422-cf596461eda7@github.com>
 <ElFhPSiZ-la4Mw8wGHwwY2MyTubIsKoOzCtMD6ryjH8=.7c59caac-6e7f-4fc8-b267-08eb0b20e915@github.com>
Message-ID: <884cBn_kkcWSHB2HjtfoWY4F-XULGMewTCUYytr8Bi4=.9c50d1e4-7d77-4704-b3f8-4fe1ce6a3efa@github.com>

On Fri, 4 Dec 2020 19:11:01 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>>> @mcimadamore Should I add you as a contributor of this patch? Does it need another reviewer to review if I add you as a contributor?
>> 
>> As you prefer - I don't mind either way. I don't think adding me as a contributor should prevent the integration, or me being able to sponsor, but I'm not 100% sure.
>
> I revise the test code based on the comment[1] written by Jonathan Gibbons in JDK-8231622[2].
> 
>> For tests that use /ref=file -XDrawDiagnostics the conventions are:
>>
>>   1. Omit the complete legal header, including the copyright and license
>>   2. After `@test` add the text `/nodynamiccopyright/`
>>
>> #1 protects the file against any future changes in the length of the legal header, that might affect line numbers, and #2 is for use by automated scripts that may check for the presence of the legal header.
> 
> [1] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015542.html
> [2] https://github.com/openjdk/jdk/pull/1626

The extensive testing revealed at least 10 cases where the compiler is issuing a new, resolution-related error when it wasn't doing so before - (the errors seem to have to do with `abstract` methods). As a result I think it's best to go with your first conservative approach, to avoid troubles. I'll try to investigate further and come up with a reduced test case for the failing condition - but that doesn't have to hold up this fix. Thanks!

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

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

From jlahoda at openjdk.java.net  Mon Dec  7 11:14:14 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 7 Dec 2020 11:14:14 GMT
Subject: Integrated: 8246778: Compiler implementation for Sealed Classes
 (Second Preview)
In-Reply-To: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
Message-ID: <IIbcipW3PTRUNHfMJDCGwU33wsBJDzYkDoq9KlNsHFY=.ced58b25-d630-447c-b2f6-cb1a82651a1b@github.com>

On Fri, 27 Nov 2020 16:57:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
> 
> From the original PR:
> 
>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>> 
>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>> 
>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>> 
>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>> 
>>     * adding code to make sure that annotations can't be sealed
>> 
>>     * improving some tests
>> 
>> 
>> TIA
>> 
>> Related specs:
>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
> 
> This PR strives to reflect the review comments from 1227:
>  * adjustments to javadoc of j.l.Class methods
>  * package access checks in Class.getPermittedSubclasses()
>  * fixed to the narrowing conversion/castability as pointed out by Maurizio

This pull request has now been integrated.

Changeset: 637b0c64
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/637b0c64
Stats:     1138 lines in 16 files changed: 1055 ins; 11 del; 72 mod

8246778: Compiler implementation for Sealed Classes (Second Preview)

Co-authored-by: Vicente Romero <vromero at openjdk.org>
Co-authored-by: Harold Seigel <hseigel at openjdk.org>
Reviewed-by: lfoltan, mchung, alanb, mcimadamore, chegar

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

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

From jlahoda at openjdk.java.net  Mon Dec  7 11:21:26 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 7 Dec 2020 11:21:26 GMT
Subject: RFR: 8256266: Binding variables don't correct support declaration
 annotations and the final modifier [v3]
In-Reply-To: <7B3tW3Nouyc_OKLm9Be1H8VbeXVBL1WiRt8-V2ZwO2o=.02134c7e-2cc8-449f-a40d-bd6101150d0a@github.com>
References: <7B3tW3Nouyc_OKLm9Be1H8VbeXVBL1WiRt8-V2ZwO2o=.02134c7e-2cc8-449f-a40d-bd6101150d0a@github.com>
Message-ID: <CFeLFJmVUPu9toG1Nh-v1AL7sW-DujZwceK75UEUAbY=.339ff994-bdd3-4f11-ab4b-4ed22d97e78d@github.com>

> Basically, javac does not handle code like this properly:
> 
> import java.lang.annotation.*;
> 
> public class B {
>      public void test(Object o) {
>          if (o instanceof @A String s) {}
>      }
> }
> 
> @Target(ElementType.LOCAL_VARIABLE)
> @interface A {}
> 
> The parser needs to allow declaration annotations on binding variables, see:
> http://cr.openjdk.java.net/~gbierman/jep394/jep394-20201012/specs/patterns-instanceof-jls.html#jls-14.30.1.1

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

  Fixing tests.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1192/files
  - new: https://git.openjdk.java.net/jdk/pull/1192/files/f1551ef1..fd6a79fe

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

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Mon Dec  7 12:00:29 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Mon, 7 Dec 2020 12:00:29 GMT
Subject: RFR: 8257037: No javac warning when calling deprecated
 constructor with diamond [v5]
In-Reply-To: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
References: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
Message-ID: <yt9VLoW9f94C0xd_h3XzwP-jXZko6h82ByRz7VvOJdM=.69670e3c-7e8f-414e-b65f-15b04ba89342@github.com>

> Hi all,
> 
> When calling deprecated constructor with diamond, the compiler doesn't output warning.
> The test case is shown below.
> 
> GenericClass<Object> o2 = new GenericClass<>();
> 
> public class GenericClass<T> {
>     @Deprecated
>     public GenericClass() {}
> }
> 
> This patch solves the bug and adds corresponding test case.
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Fall back to the previos version.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1490/files
  - new: https://git.openjdk.java.net/jdk/pull/1490/files/1d06ad1c..c4de5fa5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1490&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1490&range=03-04

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Mon Dec  7 12:00:29 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Mon, 7 Dec 2020 12:00:29 GMT
Subject: RFR: 8257037: No javac warning when calling deprecated
 constructor with diamond [v2]
In-Reply-To: <884cBn_kkcWSHB2HjtfoWY4F-XULGMewTCUYytr8Bi4=.9c50d1e4-7d77-4704-b3f8-4fe1ce6a3efa@github.com>
References: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
 <1U2EbJB1lDsbvdq9BmjwSmKaX0uXBapxvXC8ZiCkQj8=.f9a2cd1d-0870-488a-bf0d-7cedef2a3ec0@github.com>
 <zVIqNvzBoibgKiouyfuWtVVlKZ1QdVKwT3Ogcponqks=.5a22a17f-7a26-4826-9d80-27bc4c205fde@github.com>
 <NqTbEGQXGYXlBxBC0_3Alw-IXhhputmHK1dUOVxLZjk=.45b3870a-85c4-4916-bf60-2a0650223b7d@github.com>
 <ke-vuOhulPGGdca1vg_kJK4wTSVBZKMLBFpw-8yVulE=.e22c36b3-fad5-473c-bf9f-6163e5c88e3c@github.com>
 <Crrqea3jLo_w2Ewqvv7dPRGdni2RaqduZQq1GC-pOHc=.bfd96ad5-a12d-43b0-9422-cf596461eda7@github.com>
 <ElFhPSiZ-la4Mw8wGHwwY2MyTubIsKoOzCtMD6ryjH8=.7c59caac-6e7f-4fc8-b267-08eb0b20e915@github.com>
 <884cBn_kkcWSHB2HjtfoWY4F-XULGMewTCUYytr8Bi4=.9c50d1e4-7d77-4704-b3f8-4fe1ce6a3efa@github.com>
Message-ID: <IS3uZLoTJMSEJNXWPJ-wK0Lot3XvhHVYGnmZ47r3w4U=.0e25943b-e3ed-43ab-b3e6-613b094b41a9@github.com>

On Mon, 7 Dec 2020 10:40:05 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I revise the test code based on the comment[1] written by Jonathan Gibbons in JDK-8231622[2].
>> 
>>> For tests that use /ref=file -XDrawDiagnostics the conventions are:
>>>
>>>   1. Omit the complete legal header, including the copyright and license
>>>   2. After `@test` add the text `/nodynamiccopyright/`
>>>
>>> #1 protects the file against any future changes in the length of the legal header, that might affect line numbers, and #2 is for use by automated scripts that may check for the presence of the legal header.
>> 
>> [1] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015542.html
>> [2] https://github.com/openjdk/jdk/pull/1626
>
> The extensive testing revealed at least 10 cases where the compiler is issuing a new, resolution-related error when it wasn't doing so before - (the errors seem to have to do with `abstract` methods). As a result I think it's best to go with your first conservative approach, to avoid troubles. I'll try to investigate further and come up with a reduced test case for the failing condition - but that doesn't have to hold up this fix. Thanks!

It is a good news that the trouble is found before the integration instead of after the release of JDK16.
I revise the code to previous version.
Thank your for the review.

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

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

From mcimadamore at openjdk.java.net  Mon Dec  7 12:18:15 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 7 Dec 2020 12:18:15 GMT
Subject: RFR: 8257037: No javac warning when calling deprecated
 constructor with diamond [v5]
In-Reply-To: <yt9VLoW9f94C0xd_h3XzwP-jXZko6h82ByRz7VvOJdM=.69670e3c-7e8f-414e-b65f-15b04ba89342@github.com>
References: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
 <yt9VLoW9f94C0xd_h3XzwP-jXZko6h82ByRz7VvOJdM=.69670e3c-7e8f-414e-b65f-15b04ba89342@github.com>
Message-ID: <76nHSJF7T5kTSYSfZQsIH6evOKN5lK188IPH_yfyXCQ=.ed050853-9714-4667-9843-70676896fff7@github.com>

On Mon, 7 Dec 2020 12:00:29 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi all,
>> 
>> When calling deprecated constructor with diamond, the compiler doesn't output warning.
>> The test case is shown below.
>> 
>> GenericClass<Object> o2 = new GenericClass<>();
>> 
>> public class GenericClass<T> {
>>     @Deprecated
>>     public GenericClass() {}
>> }
>> 
>> This patch solves the bug and adds corresponding test case.
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fall back to the previos version.

Looks good to go

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

Marked as reviewed by mcimadamore (Reviewer).

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

From mcimadamore at openjdk.java.net  Mon Dec  7 12:18:16 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 7 Dec 2020 12:18:16 GMT
Subject: RFR: 8257037: No javac warning when calling deprecated
 constructor with diamond [v2]
In-Reply-To: <IS3uZLoTJMSEJNXWPJ-wK0Lot3XvhHVYGnmZ47r3w4U=.0e25943b-e3ed-43ab-b3e6-613b094b41a9@github.com>
References: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
 <1U2EbJB1lDsbvdq9BmjwSmKaX0uXBapxvXC8ZiCkQj8=.f9a2cd1d-0870-488a-bf0d-7cedef2a3ec0@github.com>
 <zVIqNvzBoibgKiouyfuWtVVlKZ1QdVKwT3Ogcponqks=.5a22a17f-7a26-4826-9d80-27bc4c205fde@github.com>
 <NqTbEGQXGYXlBxBC0_3Alw-IXhhputmHK1dUOVxLZjk=.45b3870a-85c4-4916-bf60-2a0650223b7d@github.com>
 <ke-vuOhulPGGdca1vg_kJK4wTSVBZKMLBFpw-8yVulE=.e22c36b3-fad5-473c-bf9f-6163e5c88e3c@github.com>
 <Crrqea3jLo_w2Ewqvv7dPRGdni2RaqduZQq1GC-pOHc=.bfd96ad5-a12d-43b0-9422-cf596461eda7@github.com>
 <ElFhPSiZ-la4Mw8wGHwwY2MyTubIsKoOzCtMD6ryjH8=.7c59caac-6e7f-4fc8-b267-08eb0b20e915@github.com>
 <884cBn_kkcWSHB2HjtfoWY4F-XULGMewTCUYytr8Bi4=.9c50d1e4-7d77-4704-b3f8-4fe1ce6a3efa@github.com>
 <IS3uZLoTJMSEJNXWPJ-wK0Lot3XvhHVYGnmZ47r3w4U=.0e25943b-e3ed-43ab-b3e6-613b094b41a9@github.com>
Message-ID: <i0stJ1bsHUa1VmxbFdkpQ1zcRiUT2siTww0ddhKQvSY=.62f2fff5-90b8-4563-8818-be77de14a83c@github.com>

On Mon, 7 Dec 2020 11:54:08 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> The extensive testing revealed at least 10 cases where the compiler is issuing a new, resolution-related error when it wasn't doing so before - (the errors seem to have to do with `abstract` methods). As a result I think it's best to go with your first conservative approach, to avoid troubles. I'll try to investigate further and come up with a reduced test case for the failing condition - but that doesn't have to hold up this fix. Thanks!
>
> It is a good news that the trouble is found before the integration instead of after the release of JDK16.
> I revise the code to previous version.
> Thank your for the review.

Actually, after some more analysis, I discovered that many of the errors were unrelated with your fix - and had to do instead with the addition of a new default method on Stream, which is causing overload resolution changes in code that has static imports on Collectors.

Only one issue remains to be fully triaged - but, being annotation related, I think it's unlikely caused by your patch. In other words, I believe both patches are likely to be safe. I'm obviously ok with you going ahead with the more conservative fix, since you already reverted the code to that version.

I apologize for the back and forth!

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

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

From forax at univ-mlv.fr  Mon Dec  7 12:44:47 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 7 Dec 2020 13:44:47 +0100 (CET)
Subject: RFR: 8257037: No javac warning when calling deprecated
 constructor with diamond [v2]
In-Reply-To: <i0stJ1bsHUa1VmxbFdkpQ1zcRiUT2siTww0ddhKQvSY=.62f2fff5-90b8-4563-8818-be77de14a83c@github.com>
References: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
 <NqTbEGQXGYXlBxBC0_3Alw-IXhhputmHK1dUOVxLZjk=.45b3870a-85c4-4916-bf60-2a0650223b7d@github.com>
 <ke-vuOhulPGGdca1vg_kJK4wTSVBZKMLBFpw-8yVulE=.e22c36b3-fad5-473c-bf9f-6163e5c88e3c@github.com>
 <Crrqea3jLo_w2Ewqvv7dPRGdni2RaqduZQq1GC-pOHc=.bfd96ad5-a12d-43b0-9422-cf596461eda7@github.com>
 <ElFhPSiZ-la4Mw8wGHwwY2MyTubIsKoOzCtMD6ryjH8=.7c59caac-6e7f-4fc8-b267-08eb0b20e915@github.com>
 <884cBn_kkcWSHB2HjtfoWY4F-XULGMewTCUYytr8Bi4=.9c50d1e4-7d77-4704-b3f8-4fe1ce6a3efa@github.com>
 <IS3uZLoTJMSEJNXWPJ-wK0Lot3XvhHVYGnmZ47r3w4U=.0e25943b-e3ed-43ab-b3e6-613b094b41a9@github.com>
 <i0stJ1bsHUa1VmxbFdkpQ1zcRiUT2siTww0ddhKQvSY=.62f2fff5-90b8-4563-8818-be77de14a83c@github.com>
Message-ID: <564804790.352450.1607345087514.JavaMail.zimbra@u-pem.fr>

oops,
you mean Collectors.toList() vs Stream.toList()

R?mi

----- Mail original -----
> De: "Maurizio Cimadamore" <mcimadamore at openjdk.java.net>
> ?: "compiler-dev" <compiler-dev at openjdk.java.net>
> Envoy?: Lundi 7 D?cembre 2020 13:18:16
> Objet: Re: RFR: 8257037: No javac warning when calling deprecated constructor with diamond [v2]

> On Mon, 7 Dec 2020 11:54:08 GMT, Guoxiong Li
> <github.com+13688759+lgxbslgx at openjdk.org> wrote:
> 
>>> The extensive testing revealed at least 10 cases where the compiler is issuing a
>>> new, resolution-related error when it wasn't doing so before - (the errors seem
>>> to have to do with `abstract` methods). As a result I think it's best to go
>>> with your first conservative approach, to avoid troubles. I'll try to
>>> investigate further and come up with a reduced test case for the failing
>>> condition - but that doesn't have to hold up this fix. Thanks!
>>
>> It is a good news that the trouble is found before the integration instead of
>> after the release of JDK16.
>> I revise the code to previous version.
>> Thank your for the review.
> 
> Actually, after some more analysis, I discovered that many of the errors were
> unrelated with your fix - and had to do instead with the addition of a new
> default method on Stream, which is causing overload resolution changes in code
> that has static imports on Collectors.
> 
> Only one issue remains to be fully triaged - but, being annotation related, I
> think it's unlikely caused by your patch. In other words, I believe both
> patches are likely to be safe. I'm obviously ok with you going ahead with the
> more conservative fix, since you already reverted the code to that version.
> 
> I apologize for the back and forth!
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1490

From mcimadamore at openjdk.java.net  Mon Dec  7 13:51:15 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 7 Dec 2020 13:51:15 GMT
Subject: RFR: 8256266: Binding variables don't correct support declaration
 annotations and the final modifier [v3]
In-Reply-To: <CFeLFJmVUPu9toG1Nh-v1AL7sW-DujZwceK75UEUAbY=.339ff994-bdd3-4f11-ab4b-4ed22d97e78d@github.com>
References: <7B3tW3Nouyc_OKLm9Be1H8VbeXVBL1WiRt8-V2ZwO2o=.02134c7e-2cc8-449f-a40d-bd6101150d0a@github.com>
 <CFeLFJmVUPu9toG1Nh-v1AL7sW-DujZwceK75UEUAbY=.339ff994-bdd3-4f11-ab4b-4ed22d97e78d@github.com>
Message-ID: <O4albWTA_QfRRBu1_mBcaMAL00a3uZifjMl9YrFWsjI=.505b7109-9a86-418e-9494-c1669a35ad94@github.com>

On Mon, 7 Dec 2020 11:21:26 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Basically, javac does not handle code like this properly:
>> 
>> import java.lang.annotation.*;
>> 
>> public class B {
>>      public void test(Object o) {
>>          if (o instanceof @A String s) {}
>>      }
>> }
>> 
>> @Target(ElementType.LOCAL_VARIABLE)
>> @interface A {}
>> 
>> The parser needs to allow declaration annotations on binding variables, see:
>> http://cr.openjdk.java.net/~gbierman/jep394/jep394-20201012/specs/patterns-instanceof-jls.html#jls-14.30.1.1
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing tests.

Changes look good - I just have a question on the parser code

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 946:

> 944:                     TreeInfo.getStartPos(pattern);
> 945:                 } else {
> 946:                     if (mods.annotations.nonEmpty()) {

We don't seem to check for the source level here? E.g. is it possible that `instanceof @Foo Bar` will not issue the usual error if compiled with source != 16?

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

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

From mcimadamore at openjdk.java.net  Mon Dec  7 13:54:13 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 7 Dec 2020 13:54:13 GMT
Subject: RFR: 8257037: No javac warning when calling deprecated
 constructor with diamond [v5]
In-Reply-To: <76nHSJF7T5kTSYSfZQsIH6evOKN5lK188IPH_yfyXCQ=.ed050853-9714-4667-9843-70676896fff7@github.com>
References: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
 <yt9VLoW9f94C0xd_h3XzwP-jXZko6h82ByRz7VvOJdM=.69670e3c-7e8f-414e-b65f-15b04ba89342@github.com>
 <76nHSJF7T5kTSYSfZQsIH6evOKN5lK188IPH_yfyXCQ=.ed050853-9714-4667-9843-70676896fff7@github.com>
Message-ID: <5d7-EtD-dNxnPRmgD5FoVEBVz2uMnbJSg-sm7tZDSPw=.5099938d-f1d2-4838-b3a5-6aa44196492b@github.com>

On Mon, 7 Dec 2020 12:15:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fall back to the previos version.
>
> Looks good to go

>  you mean Collectors.toList() vs Stream.toList()

yes - precisely

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Mon Dec  7 13:54:14 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Mon, 7 Dec 2020 13:54:14 GMT
Subject: Integrated: 8257037: No javac warning when calling deprecated
 constructor with diamond
In-Reply-To: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
References: <VtXPVaYof4e7__igmEPFnHi9tsbONHqHbnI3cN6lTkg=.8e7d2e26-49d4-4737-8fb3-b1fbee650bbf@github.com>
Message-ID: <P3p5Q7J25KGYmfVsCcQQK6EWPhUfDp11bNpV9P4arJg=.bc45c258-24a6-40ad-8ec6-7c82561b60a7@github.com>

On Sat, 28 Nov 2020 09:46:06 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> When calling deprecated constructor with diamond, the compiler doesn't output warning.
> The test case is shown below.
> 
> GenericClass<Object> o2 = new GenericClass<>();
> 
> public class GenericClass<T> {
>     @Deprecated
>     public GenericClass() {}
> }
> 
> This patch solves the bug and adds corresponding test case.
> Thank you for taking the time to review.
> 
> Best Regards.

This pull request has now been integrated.

Changeset: 2c04fc02
Author:    Guoxiong Li <lgxbslgx at gmail.com>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2c04fc02
Stats:     41 lines in 3 files changed: 40 ins; 0 del; 1 mod

8257037: No javac warning when calling deprecated constructor with diamond

Reviewed-by: mcimadamore

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

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

From ihse at openjdk.java.net  Mon Dec  7 14:27:45 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 7 Dec 2020 14:27:45 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Move to share/data, and move jdwp.spec to java.se

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/8e775e40..f0047704

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

  Stats: 56 lines in 1565 files changed: 1 ins; 0 del; 55 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

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

From ihse at openjdk.java.net  Mon Dec  7 14:28:06 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 7 Dec 2020 14:28:06 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <aC3Bw55H-cn2Joo_JmMj81xRhJzOK0yEo49mrED-vXA=.26362910-2140-4934-888b-aed801df4a0d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
 <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
 <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>
 <OSoR2xzJPwFPcdNySvft80baeIKW_uQhLLfpacsvqlU=.3892243b-69f5-458d-b63c-eb101e96860f@github.com>
 <z45KICeqOUoy0FjsoQ-eraI48oEz0usWhcSlj7xPjhk=.b2100840-eecd-4f70-b0b7-eb78144d3f0e@github.com>
 <aC3Bw55H-cn2Joo_JmMj81xRhJzOK0yEo49mrED-vXA=.26362910-2140-4934-888b-aed801df4a0d@github.com>
Message-ID: <kxhbRD192TEhTH1lD3HBgly5Z1cKWEwKwyQLH88LCQc=.527bba0f-bf8c-4a11-a95d-228d628f5d91@github.com>

On Mon, 7 Dec 2020 14:20:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> @erikj79 Good point, that makes much more sense.
>
> I'm not sure about the formal process for suggesting changes to a delivered JEP, but this is the text I suggest should replace the current definition of the new scheme:
> 
>     src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java
>                             native/include/*.{h,hpp}
>                                    $LIBRARY/*.{c,cpp}
>                             conf/*
>                             legal/*
>                             data/*
>                             man/*
>                             lib/*
> 
> where:
> 
>   - $MODULE is a module name (_e.g._, `java.base`);
> 
>   - The `share` directory contains shared, cross-platform code, as
>     before;
> 
>   - The `$OS` directory contains operating-system-specific code, as
>     before, where `$OS` is one of `unix`, `windows`, _etc._;
> 
>   - The `classes` directory contains Java source files and resource files
>     organized into a directory tree reflecting their API `$PACKAGE`
>     hierarchy, as before;
> 
>   - The `native` directory contains C or C++ source files, as before but
>     organized differently:
> 
>     - The `include` directory contains C or C++ header files intended to
>       be exported for external use (_e.g._, `jni.h`);
> 
>     - C or C++ source files are placed in a `$LIBRARY` directory, whose
>       name is that of the shared library or DLL into which the compiled
>       code will be linked (_e.g._, `libjava` or `libawt`); and, finally,
> 
>   - The `conf` directory contains configuration files meant to be edited
>     by end users (_e.g._, `net.properties`).
> 
>   - The `legal` directory contains legal notices.
> 
>   - The `data` directory contains data files needed for building the module.
> 
>   - The `man` directory contains man pages in nroff or markdown format.
> 
>   - The `lib` directory contains configuration files not meant to be edited
>     by end users.
> 
> Rendered as markdown, it would look somewhat like this:
> 
>     src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java
>                             native/include/*.{h,hpp}
>                                    $LIBRARY/*.{c,cpp}
>                             conf/*
>                             legal/*
>                             data/*
>                             man/*
>                             lib/*
> 
> where:
> 
>   - $MODULE is a module name (_e.g._, `java.base`);
> 
>   - The `share` directory contains shared, cross-platform code, as
>     before;
> 
>   - The `$OS` directory contains operating-system-specific code, as
>     before, where `$OS` is one of `unix`, `windows`, _etc._;
> 
>   - The `classes` directory contains Java source files and resource files
>     organized into a directory tree reflecting their API `$PACKAGE`
>     hierarchy, as before;
> 
>   - The `native` directory contains C or C++ source files, as before but
>     organized differently:
> 
>     - The `include` directory contains C or C++ header files intended to
>       be exported for external use (_e.g._, `jni.h`);
> 
>     - C or C++ source files are placed in a `$LIBRARY` directory, whose
>       name is that of the shared library or DLL into which the compiled
>       code will be linked (_e.g._, `libjava` or `libawt`); and, finally,
> 
>   - The `conf` directory contains configuration files meant to be edited
>     by end users (_e.g._, `net.properties`).
> 
>   - The `legal` directory contains legal notices.
> 
>   - The `data` directory contains data files needed for building the module.
> 
>   - The `man` directory contains man pages in nroff or markdown format.
> 
>   - The `lib` directory contains configuration files not meant to be edited
>     by end users.

I hope I understood the purpose of the `lib` directory correctly. Our only instance of this is for `java.base/*/lib/security/default.policy`.

I also noted that jdk.hotspot.agent violates this scheme by having a top-level `test` and `doc` directories, apart from `share` and the OS directories. The purposes of these two directories are not clear to me. The tests in `test` are definitely never executed. I don't know if this is an omission, or if they should be removed. The documentation in `doc` is not exported to the end product, nor is it references in any developer documentation. That too should either be removed, or moved to a more suitable home.

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

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

From ihse at openjdk.java.net  Mon Dec  7 14:28:05 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 7 Dec 2020 14:28:05 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module
In-Reply-To: <z45KICeqOUoy0FjsoQ-eraI48oEz0usWhcSlj7xPjhk=.b2100840-eecd-4f70-b0b7-eb78144d3f0e@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <YCBMvW4izXxTqG14Hj2hklItAO9YjwfvYPXZouXU56w=.0d8dea68-a835-46c2-8033-5f6cc8765286@github.com>
 <ZXoQ7AF_529n2DLWgYzrCEIp9ILFLjoYKDOTDtpXMJM=.a30272fc-9681-423f-8c1b-5f23ab6c1fe2@github.com>
 <6Xos38Butvxz7sBGvR26EfT7mJrTXt_AvEj3tQcUnXA=.581f1b5c-a4f5-457c-bbee-5c2badd48ec5@github.com>
 <ghGrz4mp8OgOmfqLBrtgorjcnx6zVitz3qfMjWD-vgY=.532c4887-a4f4-4595-adb3-e98c4a87c1b8@github.com>
 <QISQ17_Ln-p25oZ1P7y2JewB2y6Bt2AAwap_2i2nuww=.e613e515-8c72-4231-b030-9ab043b3fbe0@github.com>
 <Lb4WUXc4JAzuQOG_w9Gm-2VYMc674D73jwVwMT6F6LQ=.112acc30-9648-4ec3-a3fb-9edeab56b5b7@github.com>
 <OSoR2xzJPwFPcdNySvft80baeIKW_uQhLLfpacsvqlU=.3892243b-69f5-458d-b63c-eb101e96860f@github.com>
 <z45KICeqOUoy0FjsoQ-eraI48oEz0usWhcSlj7xPjhk=.b2100840-eecd-4f70-b0b7-eb78144d3f0e@github.com>
Message-ID: <aC3Bw55H-cn2Joo_JmMj81xRhJzOK0yEo49mrED-vXA=.26362910-2140-4934-888b-aed801df4a0d@github.com>

On Fri, 4 Dec 2020 15:17:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Regarding the chosen layout. Did you consider following the existing pattern of src/<module>/{share,<OS>}/data?
>
> @erikj79 Good point, that makes much more sense.

I'm not sure about the formal process for suggesting changes to a delivered JEP, but this is the text I suggest should replace the current definition of the new scheme:

    src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java
                            native/include/*.{h,hpp}
                                   $LIBRARY/*.{c,cpp}
                            conf/*
                            legal/*
                            data/*
                            man/*
                            lib/*

where:

  - $MODULE is a module name (_e.g._, `java.base`);

  - The `share` directory contains shared, cross-platform code, as
    before;

  - The `$OS` directory contains operating-system-specific code, as
    before, where `$OS` is one of `unix`, `windows`, _etc._;

  - The `classes` directory contains Java source files and resource files
    organized into a directory tree reflecting their API `$PACKAGE`
    hierarchy, as before;

  - The `native` directory contains C or C++ source files, as before but
    organized differently:

    - The `include` directory contains C or C++ header files intended to
      be exported for external use (_e.g._, `jni.h`);

    - C or C++ source files are placed in a `$LIBRARY` directory, whose
      name is that of the shared library or DLL into which the compiled
      code will be linked (_e.g._, `libjava` or `libawt`); and, finally,

  - The `conf` directory contains configuration files meant to be edited
    by end users (_e.g._, `net.properties`).

  - The `legal` directory contains legal notices.

  - The `data` directory contains data files needed for building the module.

  - The `man` directory contains man pages in nroff or markdown format.

  - The `lib` directory contains configuration files not meant to be edited
    by end users.

Rendered as markdown, it would look somewhat like this:

    src/$MODULE/{share,$OS}/classes/$PACKAGE/*.java
                            native/include/*.{h,hpp}
                                   $LIBRARY/*.{c,cpp}
                            conf/*
                            legal/*
                            data/*
                            man/*
                            lib/*

where:

  - $MODULE is a module name (_e.g._, `java.base`);

  - The `share` directory contains shared, cross-platform code, as
    before;

  - The `$OS` directory contains operating-system-specific code, as
    before, where `$OS` is one of `unix`, `windows`, _etc._;

  - The `classes` directory contains Java source files and resource files
    organized into a directory tree reflecting their API `$PACKAGE`
    hierarchy, as before;

  - The `native` directory contains C or C++ source files, as before but
    organized differently:

    - The `include` directory contains C or C++ header files intended to
      be exported for external use (_e.g._, `jni.h`);

    - C or C++ source files are placed in a `$LIBRARY` directory, whose
      name is that of the shared library or DLL into which the compiled
      code will be linked (_e.g._, `libjava` or `libawt`); and, finally,

  - The `conf` directory contains configuration files meant to be edited
    by end users (_e.g._, `net.properties`).

  - The `legal` directory contains legal notices.

  - The `data` directory contains data files needed for building the module.

  - The `man` directory contains man pages in nroff or markdown format.

  - The `lib` directory contains configuration files not meant to be edited
    by end users.

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

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

From rriggs at openjdk.java.net  Mon Dec  7 15:08:12 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 7 Dec 2020 15:08:12 GMT
Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for
 removal
In-Reply-To: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>
References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>
Message-ID: <Fl-cWTaz17dK2mrEvx318D5ScjkL-up3gtWVzo9x9d4=.83b8febf-1f03-43f6-b836-b44c648e5801@github.com>

On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100).
> 
> Development has been broken into 5 tasks, each with its own JBS issue:
> - Deprecate wrapper class constructors for removal (rriggs)
> - Revise "value-based class" & apply to wrappers (dlsmith)
> - Define & apply annotation jdk.internal.ValueBased (rriggs)
> - Add 'lint' warning for @ValueBased classes (sadayapalam)
> - Diagnose synchronization on @ValueBased classes (lfoltan)
> 
> All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.)
> 
> CSRs have also been completed or are nearly complete:
> 
> - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation
> - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class"
> - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings
> 
> Here's an overview of the files changed:
> 
> - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes.
> 
> - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance.
> 
> - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation.
> 
> - `src/java.management.rmi`: removing uses of wrapper class constructors.
> 
> - `src/java.xml`: removing uses of wrapper class constructors.
> 
> - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`.
> 
> - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.)
> 
> - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests
> 
> - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics
> 
> - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`.

For the core libraries parts looks ok.

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

Marked as reviewed by rriggs (Reviewer).

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

From hseigel at openjdk.java.net  Mon Dec  7 15:53:14 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 7 Dec 2020 15:53:14 GMT
Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for
 removal
In-Reply-To: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>
References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>
Message-ID: <DBXljSbfnxVvTWaB3vWYuroiHOTlz8ZVqocZR4JffNw=.1fbca489-56da-4190-ad5a-2fd42512ff59@github.com>

On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100).
> 
> Development has been broken into 5 tasks, each with its own JBS issue:
> - Deprecate wrapper class constructors for removal (rriggs)
> - Revise "value-based class" & apply to wrappers (dlsmith)
> - Define & apply annotation jdk.internal.ValueBased (rriggs)
> - Add 'lint' warning for @ValueBased classes (sadayapalam)
> - Diagnose synchronization on @ValueBased classes (lfoltan)
> 
> All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.)
> 
> CSRs have also been completed or are nearly complete:
> 
> - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation
> - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class"
> - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings
> 
> Here's an overview of the files changed:
> 
> - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes.
> 
> - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance.
> 
> - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation.
> 
> - `src/java.management.rmi`: removing uses of wrapper class constructors.
> 
> - `src/java.xml`: removing uses of wrapper class constructors.
> 
> - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`.
> 
> - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.)
> 
> - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests
> 
> - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics
> 
> - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`.

The hotspot changes look good.  In a future change, could you add additional classes, such as ProcessHandle to test TestSyncOnValueBasedClassEvent.  Currently, it only tests primitive classes.

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

Marked as reviewed by hseigel (Reviewer).

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

From vromero at openjdk.java.net  Mon Dec  7 15:55:19 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 7 Dec 2020 15:55:19 GMT
Subject: RFR: 8254023: A module declaration is not allowed to be a target
 of an annotation that lacks an @Target meta-annotation
In-Reply-To: <6VDsNZKAYnkmm_YsLRjClBhqPMPPqy4d3TrWLcElkOU=.3f9b9d49-4e49-4574-a07c-6f72acefcfd2@github.com>
References: <wFdu9AyyNU2SB0nWx9mq_2syF2XyQIB0z6Rmc-r1fNc=.369439d1-385e-4fd1-aac1-72e48ac246e8@github.com>
 <pqSfmocPi4AJGQJEJl4j6UgITEL0f62TKSVpxwOer6w=.49e74a9b-ecb0-4a13-9dfc-93c27fd5149a@github.com>
 <5_HZhCK8rd2yWcf4XzGa_N50I1Xl3CMmUXSugfoJIUk=.379b61e3-e4a3-4509-ac7b-940a25ae4609@github.com>
 <6VDsNZKAYnkmm_YsLRjClBhqPMPPqy4d3TrWLcElkOU=.3f9b9d49-4e49-4574-a07c-6f72acefcfd2@github.com>
Message-ID: <tBB2q0ATDEr8k86St14cqLVTAwy2CH34WolOWfPH1bw=.e9a456ad-28c8-4e36-9eb4-62024a96c0e4@github.com>

On Thu, 3 Dec 2020 08:20:13 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Thanks for focusing on this patch. I will continue to follow the discussion and revise my patch based on the outcome of the discussion.
>
>> Short term (Java 16) it makes sense to fix https://bugs.openjdk.java.net/browse/JDK-8254023 given that both competing specs agree for this case, it is a small fix, and externally found.
>>
>>For Java 17 we should align both specs and the reference implementation one way or another.
> 
> @jbf According to your comments, I revise my code to only fix JDK-8254023.
> The rest of the work, ambiguity of the specifications, will be clarified and fixed in Java 17.
> Thank you for taking the time to review.

the change looks good but I'm surprised that no other tests are failing and need changes, in particular tests like:  `test/langtools/tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java`

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

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

From jlahoda at openjdk.java.net  Mon Dec  7 16:13:13 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 7 Dec 2020 16:13:13 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17
In-Reply-To: <EhQCAhIxxXIe8jvHvDQb_htw5IT66wq3F0axf02LquQ=.cff6c11e-e8e0-4f80-9213-e4c3ef0d64a8@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <EhQCAhIxxXIe8jvHvDQb_htw5IT66wq3F0axf02LquQ=.cff6c11e-e8e0-4f80-9213-e4c3ef0d64a8@github.com>
Message-ID: <2bAC_zX5mRvINljUBg3fBvHY3t-KQX46HpxP-0vPNnw=.e37efaa6-021f-412a-b52b-fb13718e019a@github.com>

On Sat, 5 Dec 2020 03:17:56 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> Start of JDK 17 updates.
>
> Marked as reviewed by mikael (Reviewer).

The langtools changes look fine to me. There were additions/changes to jcod files under `test/hotspot/jtreg/runtime/sealedClasses/` made under JDK-8246778, so these may need an update. Sorry about that.

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

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

From vromero at openjdk.java.net  Mon Dec  7 16:17:11 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 7 Dec 2020 16:17:11 GMT
Subject: Withdrawn: 8246778: Compiler implementation for Sealed Classes
 (Second Preview)
In-Reply-To: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
Message-ID: <JKzUgPoWZ4E2hg_cMH0flNs6w41Son1at-iRXw1CV48=.e92d0e6e-b585-4d0b-9442-1dbbf16e4cbd@github.com>

On Mon, 16 Nov 2020 13:30:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review the code for the second iteration of sealed classes. In this iteration we are:
> 
> - Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
> - Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
> - renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
> - adding code to make sure that annotations can't be sealed
> - improving some tests
> 
> TIA
> 
> Related specs:
> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)

This pull request has been closed without being integrated.

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

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

From lfoltan at openjdk.java.net  Mon Dec  7 16:25:13 2020
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Mon, 7 Dec 2020 16:25:13 GMT
Subject: RFR: 8252180: [JEP 390] Deprecate wrapper class constructors for
 removal
In-Reply-To: <DBXljSbfnxVvTWaB3vWYuroiHOTlz8ZVqocZR4JffNw=.1fbca489-56da-4190-ad5a-2fd42512ff59@github.com>
References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>
 <DBXljSbfnxVvTWaB3vWYuroiHOTlz8ZVqocZR4JffNw=.1fbca489-56da-4190-ad5a-2fd42512ff59@github.com>
Message-ID: <daRqe8BueKkQgPH9tjRo4guncvyjbw6wdG6szQDOXgY=.be84a3cc-ec84-47c6-8633-19206ee7525b@github.com>

On Mon, 7 Dec 2020 15:50:55 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100).
>> 
>> Development has been broken into 5 tasks, each with its own JBS issue:
>> - Deprecate wrapper class constructors for removal (rriggs)
>> - Revise "value-based class" & apply to wrappers (dlsmith)
>> - Define & apply annotation jdk.internal.ValueBased (rriggs)
>> - Add 'lint' warning for @ValueBased classes (sadayapalam)
>> - Diagnose synchronization on @ValueBased classes (lfoltan)
>> 
>> All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.)
>> 
>> CSRs have also been completed or are nearly complete:
>> 
>> - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation
>> - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class"
>> - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings
>> 
>> Here's an overview of the files changed:
>> 
>> - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes.
>> 
>> - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`.
>> 
>> - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance.
>> 
>> - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
>> 
>> - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
>> 
>> - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation.
>> 
>> - `src/java.management.rmi`: removing uses of wrapper class constructors.
>> 
>> - `src/java.xml`: removing uses of wrapper class constructors.
>> 
>> - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`.
>> 
>> - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.)
>> 
>> - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests
>> 
>> - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics
>> 
>> - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`.
>
> The hotspot changes look good.  In a future change, could you add additional classes, such as ProcessHandle to test TestSyncOnValueBasedClassEvent.  Currently, it only tests primitive classes.

@hseigel thank you for the review.  I have created https://bugs.openjdk.java.net/browse/JDK-8257836 as an RFE to address additional testing.
Lois

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

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

From vromero at openjdk.java.net  Mon Dec  7 16:49:16 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 7 Dec 2020 16:49:16 GMT
Subject: RFR: 8254784: javac should reject records with @SafeVarargs
 applied to varargs record component [v2]
In-Reply-To: <iPkv4HzJx-zdI94MBm8tr_AcEAIz2XdWp6P_9BL-xWc=.fb2b0071-8284-4a25-a98f-b56402f19d22@github.com>
References: <qsYgkP7DYZbKKoKw2FCJrTtakM_m92eFFKb8a7DVozU=.bcc1c680-743c-438a-aa80-a93869c0e68e@github.com>
 <g9iHAAuzadirk9gB3weLo97NRi0i2u2gsIGaywdWn1c=.b6155edc-c669-4934-a81a-8f7913163cbc@github.com>
 <iPkv4HzJx-zdI94MBm8tr_AcEAIz2XdWp6P_9BL-xWc=.fb2b0071-8284-4a25-a98f-b56402f19d22@github.com>
Message-ID: <gOls4bI2Dr4Ic3UrFr4SfWQuvb4Lf8oeG2u8q-ume4M=.f8c6f619-1d8c-4a89-ae8e-98ec8eb23b1e@github.com>

On Fri, 13 Nov 2020 12:43:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - manual merge with master
>>  - 8254784: javac should reject records with @SafeVarargs applied to varargs record component
>
> Seems sensible. A possible alternative would be to err immediately when we see (e.g. in TypeEnter?) that a record header contains a SafeVarargs annotation, in which case we know we can't support it.

thanks for the approval, yes we could have done what you are proposing too

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

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

From vromero at openjdk.java.net  Mon Dec  7 16:49:18 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 7 Dec 2020 16:49:18 GMT
Subject: Integrated: 8254784: javac should reject records with @SafeVarargs
 applied to varargs record component
In-Reply-To: <qsYgkP7DYZbKKoKw2FCJrTtakM_m92eFFKb8a7DVozU=.bcc1c680-743c-438a-aa80-a93869c0e68e@github.com>
References: <qsYgkP7DYZbKKoKw2FCJrTtakM_m92eFFKb8a7DVozU=.bcc1c680-743c-438a-aa80-a93869c0e68e@github.com>
Message-ID: <xxVWMr8IneH3t2MU_bxrbDF_sp_qtskYxoktLbR09zc=.4303ac3e-7bb8-4785-8b79-9b60d72ea385@github.com>

On Fri, 16 Oct 2020 00:26:24 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this fix for issue [1]. This is the background, for a record defined like:
> 
> record R(@SafeVarargs String... s) {}
> 
> an the following accessor will be generated:
> 
>     `@SafeVararags public String[] s() { return s; }`
> 
> this code is incorrect as the accessor is not a varargs method. But still the compiler is not generating a compiler error. The reason for this is that the method defining the accessor is not generated until the compiler get to its backend phase (at Lower to be more specific) and the check for incorrect @SafeVarargs use in the compiler happen before that, in Attr.
> 
> We decided to do not generate record related code until late phases in order to avoid generating code in the compiler frontend and because if code is generated in early stages then APs could see ASTs not created from user defined code. 
> 
> The proposed fix is to issue an error as soon as the compiler finds out that the @SafeVarargs annotation is applied to a compiler generated accessor because in other case the compiler would be forced to generate incorrect code.
> 
> TIA for the reviews,
> Vicente
> 
> [1] [https://bugs.openjdk.java.net/browse/JDK-8254784](https://bugs.openjdk.java.net/browse/JDK-8254784)

This pull request has now been integrated.

Changeset: b4b9828c
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b4b9828c
Stats:     62 lines in 4 files changed: 58 ins; 0 del; 4 mod

8254784: javac should reject records with @SafeVarargs applied to varargs record component

Reviewed-by: mcimadamore

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

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

From jjg at openjdk.java.net  Mon Dec  7 18:37:37 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 7 Dec 2020 18:37:37 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations. [v6]
In-Reply-To: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
Message-ID: <r6x0B8EUk4UVr8bP6gCQ4FS63wxnQLg6uhDHyjQ5cvA=.b27e6dc8-35c1-4360-b62d-e0aa196e6f4a@github.com>

> This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description.
> 
> The goal is to be able to simplify the following common pattern:
> 
>     /**
>      * Returns the result. Optional additional text.
>      * @return the result
>      */
>     int method() { 
> 
> by 
> 
>     /**
>      * {@return the result} Optional additional text.
>      */
>     int method() { 
> 
> Note:
> 
> * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere.
> * The expansion of the inline tag is `Returns " _content_ `.`  where _content_ is the content of the tag. 
> * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description
> * The inline tag can be inherited into overriding methods as if it was provided as a block tag.

Jonathan Gibbons 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 12 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into new-return
 - Update JShell to handle inline `{@return}`
 - Merge remote-tracking branch 'upstream/master' into new-return
 - fix test
 - Update for new `@return` tag
 - Merge remote-tracking branch 'upstream/master' into new-return
 - Update DocCommentParser to permit nested inline tags in specified cases: @return
 - Add default impl for new method
 - Fix test failure
 - Fix trailing whitespace in test
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/096e9a24...a25dadca

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1355/files
  - new: https://git.openjdk.java.net/jdk/pull/1355/files/60ff9839..a25dadca

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1355&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1355&range=04-05

  Stats: 20689 lines in 549 files changed: 14531 ins; 4346 del; 1812 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1355.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1355/head:pull/1355

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

From mchung at openjdk.java.net  Mon Dec  7 19:11:13 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 7 Dec 2020 19:11:13 GMT
Subject: RFR: 8257845: Integrate JEP 390
In-Reply-To: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>
References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>
Message-ID: <GNs2ZteaXLwKQRUnWSYy5zTpcGsgATc-a8lc_aLtiv4=.f65395ab-659f-4209-a11a-78ebc03f43ba@github.com>

On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100).
> 
> Development has been broken into 5 tasks, each with its own JBS issue:
> - Deprecate wrapper class constructors for removal (rriggs)
> - Revise "value-based class" & apply to wrappers (dlsmith)
> - Define & apply annotation jdk.internal.ValueBased (rriggs)
> - Add 'lint' warning for @ValueBased classes (sadayapalam)
> - Diagnose synchronization on @ValueBased classes (lfoltan)
> 
> All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.)
> 
> CSRs have also been completed or are nearly complete:
> 
> - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation
> - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class"
> - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings
> 
> Here's an overview of the files changed:
> 
> - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes.
> 
> - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance.
> 
> - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation.
> 
> - `src/java.management.rmi`: removing uses of wrapper class constructors.
> 
> - `src/java.xml`: removing uses of wrapper class constructors.
> 
> - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`.
> 
> - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.)
> 
> - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests
> 
> - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics
> 
> - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`.

core-libs and hotspot change look okay.

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

Marked as reviewed by mchung (Reviewer).

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

From jjg at openjdk.java.net  Mon Dec  7 19:17:11 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 7 Dec 2020 19:17:11 GMT
Subject: RFR: 8231622: SuppressWarning("serial") ignored on field
 serialVersionUID [v2]
In-Reply-To: <4goARqQD66tV2vjOvFDNRKH4qTNdcMEcvcEQ0pemyTE=.b361dcd5-5438-4bc8-97f3-2189aaa2782c@github.com>
References: <_2Z8RhLQo1F6ddk2cZS5J_hoRMPLCe5ssVMeyyscFnc=.d267dddd-12d6-4968-a32d-6bd3510daf45@github.com>
 <7pKHc5G19_52b3VTxU-iAj1aLwWzAKYaK2fI57AmiSw=.c2c52e2d-b8aa-470f-9acd-0a2890b7dcda@github.com>
 <4goARqQD66tV2vjOvFDNRKH4qTNdcMEcvcEQ0pemyTE=.b361dcd5-5438-4bc8-97f3-2189aaa2782c@github.com>
Message-ID: <ZL0cuQToRloB4pZYCLNh1iOFASW_4VeuN_WIaFT1tlE=.d19c6241-ca7f-4537-9dea-8b19cddc65c3@github.com>

On Fri, 4 Dec 2020 18:35:14 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Thank you for your comment. I revise my code according to your suggestion.
> 
> And I found some previous tests use the wrong style which are like this patch. I want to modify them so that these tests won't mislead other developers, especially the new developers. Could I get your help to open a new issue about it in the bug tracker? Thanks a lot.

Can you give me a list of tests that you think need to be addressed?

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

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

From jjg at openjdk.java.net  Mon Dec  7 19:24:14 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 7 Dec 2020 19:24:14 GMT
Subject: RFR: 8231622: SuppressWarning("serial") ignored on field
 serialVersionUID [v2]
In-Reply-To: <EFt3JG5qibOriEpCuxCta2jxN-VSGYfkveexxYo9E0Q=.0a706fd2-62ca-4ff9-ae0d-69ed8c5edd28@github.com>
References: <_2Z8RhLQo1F6ddk2cZS5J_hoRMPLCe5ssVMeyyscFnc=.d267dddd-12d6-4968-a32d-6bd3510daf45@github.com>
 <EFt3JG5qibOriEpCuxCta2jxN-VSGYfkveexxYo9E0Q=.0a706fd2-62ca-4ff9-ae0d-69ed8c5edd28@github.com>
Message-ID: <7FIRVZWxC7jmkBBDhFouBiN0s2NFUW3GeBOvkSN4lbw=.38d7d5c1-66f6-4597-a346-6b738c6c346d@github.com>

On Fri, 4 Dec 2020 18:26:36 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi all,
>> 
>> Currently, a warning is generated when compiling the following code by using the option `-Xlint`.
>> 
>> import java.io.Serializable;
>> class B implements Serializable {
>>     @SuppressWarnings("serial")
>>     private static final byte serialVersionUID = 5;
>> }
>> 
>> output:
>> B.java:4: warning: [serial] serialVersionUID must be of type long in class B
>>     private static final byte serialVersionUID = 5;
>>                               ^
>> 1 warning
>> 
>> The annotation `@SuppressWarnings("serial")` on  field serialVersionUID is ignored by the compiler.
>> This patch fixes it and adds some tests.
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revise test cases. Remove legal header and add /nodynamiccopyright/

I approve these changes.

That being said, a more modern idiom for negative tests involving small source files and corresponding small golden files, is to write a single file that uses library code like `toolbox.ToolBox` to write files on the fly, perhaps from content in a text block, and to compare the output against another text block.  For slightly more advanced usage, you can compile strings directly using API like `SimpleJavaFileObject`, and avoid the file system altogether.

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

Marked as reviewed by jjg (Reviewer).

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

From vromero at openjdk.java.net  Mon Dec  7 19:26:13 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 7 Dec 2020 19:26:13 GMT
Subject: RFR: 8256411: Based anonymous classes have a weird end position
In-Reply-To: <7aKd4Z5-b2wrbXxf5Kz2ZRjPKyl4Zw0JRVTt6e9hA2M=.71073831-380f-4a99-ad8d-1112a05af229@github.com>
References: <7aKd4Z5-b2wrbXxf5Kz2ZRjPKyl4Zw0JRVTt6e9hA2M=.71073831-380f-4a99-ad8d-1112a05af229@github.com>
Message-ID: <RMwwE05s-XHPx93SjoSZ9aPnEnDFrsIEjYCQcQ7Puyg=.7a4c5b39-34d0-4277-868d-ec7061a060e6@github.com>

On Mon, 16 Nov 2020 18:12:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like this:
> 
> package t;
> class Test {
>     class I {}
>     static Object S = new Test().new I() {};
> }
> 
> There is a synthetically generated `Test.I` in the extends clause of the anonymous class. The current end position for it is the end of the whole anonymous class (i.e. at '}'), which does not make much sense. The proposal is that the end position should be the end position of the "I" identifier, which is the same as if the anonymous class would not be based on an enclosing instance.

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From jjg at openjdk.java.net  Mon Dec  7 19:28:18 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 7 Dec 2020 19:28:18 GMT
Subject: RFR: 8257799: Update JLS cross-references in java.compiler
In-Reply-To: <X3bitfIhnWvSPBcNfBtVwarzCAXz5DK38ZWPM0pZ68Y=.def190bd-b039-42b0-84bc-912fbcf4a0c7@github.com>
References: <X3bitfIhnWvSPBcNfBtVwarzCAXz5DK38ZWPM0pZ68Y=.def190bd-b039-42b0-84bc-912fbcf4a0c7@github.com>
Message-ID: <ncQat1WOYhlQo84ACOwihzAUFQSJDMJy3X2f3tCJUwM=.be3d0b20-92c8-46d5-9acf-88bc4bca83c5@github.com>

On Sat, 5 Dec 2020 21:37:34 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> A few of the @jls tags in the java.compiler module don't make the corresponding JLS section anymore; the null literal section and constant expression sections were renumbered.
> 
> This change makes corrects the mismatches.

Approved.

It would also be reasonable to semi-automate checking whether this sort of edit is necessary as a formal jtreg test, perhaps using a static checked-in copy of the JLS and JVMS index, which is maybe updated near the end of each release. If you think that is worth pursuing, maybe you could file an issue in JBS.

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

Marked as reviewed by jjg (Reviewer).

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

From jjg at openjdk.java.net  Mon Dec  7 19:35:17 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 7 Dec 2020 19:35:17 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
Message-ID: <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>

On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move to share/data, and move jdwp.spec to java.se

I have reviewed all lines in the patch file with or near instances of `jdk.compiler`

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

Marked as reviewed by jjg (Reviewer).

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

From darcy at openjdk.java.net  Mon Dec  7 19:38:41 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 7 Dec 2020 19:38:41 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v2]
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <tGzaObdw0dM1CrH9Epdjqd_lJnEmioaw7trPSWiwaYg=.a65a256b-8517-4b06-a24c-f79c4f0ceb30@github.com>

> Start of JDK 17 updates.

Joe Darcy 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 eight additional commits since the last revision:

 - Merge branch 'master' into JDK-8257450
 - Update tests.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - JDK-8257450
 - JDK-8257450
 - JDK-8257450

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1531/files
  - new: https://git.openjdk.java.net/jdk/pull/1531/files/4187d66f..f6a64473

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

  Stats: 12681 lines in 254 files changed: 8255 ins; 3285 del; 1141 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1531.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531

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

From vromero at openjdk.java.net  Mon Dec  7 19:47:17 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 7 Dec 2020 19:47:17 GMT
Subject: RFR: 8229862: NPE in
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:570)
In-Reply-To: <4X4uxFy-z0Vn9VBKilwfkDUWwt9lPnhdX9km7U5Oqi4=.ec9b59d3-b282-47cc-9ce3-846a072f08f6@github.com>
References: <4X4uxFy-z0Vn9VBKilwfkDUWwt9lPnhdX9km7U5Oqi4=.ec9b59d3-b282-47cc-9ce3-846a072f08f6@github.com>
Message-ID: <o5U5oX8F9zUOA3hAPabjNAvD3emamMy2smLG5u-CLLU=.58aa875f-6607-46bd-9d2a-d612f06c5e39@github.com>

On Mon, 16 Nov 2020 10:32:00 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Based on Bernard's code from:
> http://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015225.html
> 
> Capturing anonymous classes inside lambdas may fail to compile, because:
> -the captured variables are not detected correctly, because `LambdaToMethod...captureLocalClassDefs` needs to find the AST node for the given `ClassSymbol`, but it has not yet been added into the `localClassDefs`. The proposed solution is to re-order the tasks done for JCNewClass, and call the super implementation sooner. This will enter the `ClassSymbol` and corresponding AST node into `localClassDefs` before the capture variables detection.
> -inside the anonymous class definition, some references to the captured variables are replaced using a map that maps captured variables for lambdas (`lambdaTranslationMap`) - but inside the anonymous class, there the captured variables should be mapped using the anonymous class' map/proxies (to fields). The proposed solution is to clear `lambdaTranslationMap` before processing the anonymous class body.

looks sensible, accepted with minor comment

test/langtools/tools/javac/lambda/LambdaConv30.java line 2:

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

nit: the copy year should be 2020 only

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

Marked as reviewed by vromero (Reviewer).

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

From jjg at openjdk.java.net  Mon Dec  7 19:47:17 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 7 Dec 2020 19:47:17 GMT
Subject: RFR: 8245956: JavaCompiler still uses files API instead of Path
 API in a specific case
In-Reply-To: <dQCLUalaPhBxjTKrvGIY6c4d9m5HBRQfRu0QuoMUokM=.de840fae-cf05-4f95-9cc3-edf7646046ed@github.com>
References: <dQCLUalaPhBxjTKrvGIY6c4d9m5HBRQfRu0QuoMUokM=.de840fae-cf05-4f95-9cc3-edf7646046ed@github.com>
Message-ID: <UtY3FrXU41CoqkkS5K5c9O7JBtzxiHLv_W1r6bxHG_0=.cbeff4e1-55f4-495b-9296-cc556deffabb@github.com>

On Wed, 2 Dec 2020 05:10:12 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> `JavacFileManager.getClassLoader` uses `getLocation` which causes exception in some situations.
> This patch uses `getLocationAsPaths` instead of `getLocation` to solve it.
> Thanks you for taking the time to review.
> 
> Best Regards.

Nice.

Some minor suggestions inline for your consideration.

src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java line 744:

> 742:     public ClassLoader getClassLoader(Location location) {
> 743:         checkNotModuleOrientedLocation(location);
> 744:         Collection<? extends Path> paths = getLocationAsPaths(location);

Minor suggestion:  the use of the simple name `path` or `paths` can be confusing in contexts like this, when the name may refer to an instance of `java.nio.file.Path` or a collection of such items.

You did good by renaming the variable from `path` to `paths`.  A more explicit name would be to use `searchPath` as the name for a series of file system objects.

test/langtools/tools/javac/T8245956/T8245956.java line 27:

> 25:  * @test
> 26:  * @bug 8245956
> 27:  * @summary JavaCompiler still uses files API instead of Path API in a specific case

I suggest changing `files API` to `File API`.
I have made the corresponding change in the JBS issue.

test/langtools/tools/javac/T8245956/T8245956.java line 62:

> 60:                 classPath.add(fsPath);
> 61:                 fileManager.setLocationFromPaths(StandardLocation.CLASS_PATH, classPath);
> 62:                 fileManager.getClassLoader(StandardLocation.CLASS_PATH);  // Should not generate any exceptions.

Minor suggestion: add something like a print statement after the `getClassLoader` call to verify that the `getClassLoader` call terminated normally.

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

Marked as reviewed by jjg (Reviewer).

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

From darcy at openjdk.java.net  Mon Dec  7 19:50:16 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 7 Dec 2020 19:50:16 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v2]
In-Reply-To: <2bAC_zX5mRvINljUBg3fBvHY3t-KQX46HpxP-0vPNnw=.e37efaa6-021f-412a-b52b-fb13718e019a@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <EhQCAhIxxXIe8jvHvDQb_htw5IT66wq3F0axf02LquQ=.cff6c11e-e8e0-4f80-9213-e4c3ef0d64a8@github.com>
 <2bAC_zX5mRvINljUBg3fBvHY3t-KQX46HpxP-0vPNnw=.e37efaa6-021f-412a-b52b-fb13718e019a@github.com>
Message-ID: <7YT7teNjF9GmNGWPa_u40xyn_BGgZdxNhcjls6u1Hjs=.5d7bad6b-12ad-4d20-a8ad-d31a74c7a392@github.com>

On Mon, 7 Dec 2020 16:10:42 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> 
> 
> The langtools changes look fine to me. There were additions/changes to jcod files under `test/hotspot/jtreg/runtime/sealedClasses/` made under JDK-8246778, so these may need an update. Sorry about that.

After a merge, the tests in that directory still pass. Will keep merging in new changes and do at least more more test run before pushing. Thanks.

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

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

From hseigel at openjdk.java.net  Mon Dec  7 19:56:20 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 7 Dec 2020 19:56:20 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute cannot
 be extended
Message-ID: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>

Please review this fix for JDK-8256867.  This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes).  Instead, the class is treated as a sealed class which cannot be extended nor implemented.  This new behavior conforms to the JVM Spec.

This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes.

This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64.

Thanks, Harold

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

Commit messages:
 - 8256867: Classes with empty PermittedSubclasses attribute cannot be extended

Changes: https://git.openjdk.java.net/jdk/pull/1675/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1675&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256867
  Stats: 156 lines in 8 files changed: 100 ins; 13 del; 43 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1675.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1675/head:pull/1675

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

From jjg at openjdk.java.net  Mon Dec  7 20:01:15 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 7 Dec 2020 20:01:15 GMT
Subject: RFR: 8245956: JavaCompiler still uses files API instead of Path
 API in a specific case
In-Reply-To: <dQCLUalaPhBxjTKrvGIY6c4d9m5HBRQfRu0QuoMUokM=.de840fae-cf05-4f95-9cc3-edf7646046ed@github.com>
References: <dQCLUalaPhBxjTKrvGIY6c4d9m5HBRQfRu0QuoMUokM=.de840fae-cf05-4f95-9cc3-edf7646046ed@github.com>
Message-ID: <J-s2OmwvaqqltLqlKWl-9_qhBl1D8hFciL6B7Sv9yzo=.01c71a80-48c1-48e9-bcab-8b79c340ea5f@github.com>

On Wed, 2 Dec 2020 05:10:12 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> `JavacFileManager.getClassLoader` uses `getLocation` which causes exception in some situations.
> This patch uses `getLocationAsPaths` instead of `getLocation` to solve it.
> Thanks you for taking the time to review.
> 
> Best Regards.

Marked as reviewed by jjg (Reviewer).

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

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

From jjg at openjdk.java.net  Mon Dec  7 20:18:16 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 7 Dec 2020 20:18:16 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v2]
In-Reply-To: <tGzaObdw0dM1CrH9Epdjqd_lJnEmioaw7trPSWiwaYg=.a65a256b-8517-4b06-a24c-f79c4f0ceb30@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <tGzaObdw0dM1CrH9Epdjqd_lJnEmioaw7trPSWiwaYg=.a65a256b-8517-4b06-a24c-f79c4f0ceb30@github.com>
Message-ID: <yDdsQ2hZCOJ3YiASuI8_uDOcFxTBjf1GHLl-MDYP-GA=.b9fbfbb5-6b0b-4a78-9f9a-c24615c20349@github.com>

On Mon, 7 Dec 2020 19:38:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Start of JDK 17 updates.
>
> Joe Darcy 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 eight additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8257450
>  - Update tests.
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - JDK-8257450
>  - JDK-8257450
>  - JDK-8257450

I've read all the files, and approve all the langtools related ones (i.e. not hotspot)
As you've noticed elsewhere, there's a pending conflict with Magnus' work to move files around.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 108:

> 106: 
> 107:     /**
> 108:       * 16, tbd

The "tbd" can presumably be filled in now

test/jdk/java/lang/module/ClassFileVersionsTest.java line 107:

> 105:                 { 61,   0,  Set.of(STATIC, TRANSITIVE) },
> 106: 
> 107:                 { 62,   0,  Set.of()},                       // JDK 18

This seems unduly repetitive. Could this be dynamically generated, perhaps in a future release?

test/langtools/tools/javac/preview/classReaderTest/Client.preview.out line 1:

> 1: - compiler.warn.preview.feature.use.classfile: Bar.class, 17

Is this a test can could be automated? (i.e. no manual change per release?)

test/langtools/tools/javac/versions/Versions.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 4981566 5028634 5094412 6304984 7025786 7025789 8001112 8028545 8000961 8030610 8028546 8188870 8173382 8173382 8193290 8205619 8028563 8245147 8245586 8257453

long lines are annoying

test/langtools/tools/javac/versions/Versions.java line 297:

> 295:        expectedPass(args, List.of("New7.java", "New8.java", "New10.java", "New11.java",
> 296:                                   "New14.java", "New15.java"));
> 297:         expectedFail(args, List.of("New16.java"));

(minor) looks like bad indentation

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

Marked as reviewed by jjg (Reviewer).

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

From jlahoda at openjdk.java.net  Mon Dec  7 20:18:21 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 7 Dec 2020 20:18:21 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v2]
In-Reply-To: <tGzaObdw0dM1CrH9Epdjqd_lJnEmioaw7trPSWiwaYg=.a65a256b-8517-4b06-a24c-f79c4f0ceb30@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <tGzaObdw0dM1CrH9Epdjqd_lJnEmioaw7trPSWiwaYg=.a65a256b-8517-4b06-a24c-f79c4f0ceb30@github.com>
Message-ID: <Jz0yzt0iCBxSsgO9i2wbb1KI9lMuphTnKtZv6CRxqFg=.c2b17566-f847-4b2e-8b3e-f04459e41157@github.com>

On Mon, 7 Dec 2020 19:38:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Start of JDK 17 updates.
>
> Joe Darcy 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 eight additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8257450
>  - Update tests.
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - JDK-8257450
>  - JDK-8257450
>  - JDK-8257450

Marked as reviewed by jlahoda (Reviewer).

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

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

From vromero at openjdk.java.net  Mon Dec  7 20:23:14 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 7 Dec 2020 20:23:14 GMT
Subject: RFR: 8256149: Weird AST structure for incomplete member select
In-Reply-To: <c09LcmEH_zjugw6V0nu2cWy_iSQrxL--uEL5Iq3zv6I=.cc1b09a7-2219-4abf-ad8c-718dcac7e43f@github.com>
References: <c09LcmEH_zjugw6V0nu2cWy_iSQrxL--uEL5Iq3zv6I=.cc1b09a7-2219-4abf-ad8c-718dcac7e43f@github.com>
Message-ID: <vqjtaIJdQUJDnIKn-RGWJ9pGGsPTb6gDeHl9P15PP7g=.e83574cc-3e2b-4846-9d1f-679250c68c81@github.com>

On Wed, 11 Nov 2020 09:01:52 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> int i1 = "".
> @Deprecated
> void t1() {}
> 
> In current master, this will produce a somewhat twisted AST, and compile-time errors like:
> E.java:2: error: <identifier> expected
> int i = "".
>            ^
> E.java:3: error: illegal start of expression
> @Deprecated void t() {}
> ^
> E.java:3: error: ';' expected
> @Deprecated void t() {}
>            ^
> 3 errors
> 
> The reason is that `@Deprecated` is parsed as a type annotation following `"".<missing>`, which does not make much sense.
> 
> With this proposed patch, the AST is effectively the same as AST for:
> int i1 = "".; //note the semicolon here
> @Deprecated
> void t1() {}
> 
> And the errors are much better as well:
> E.java:2: error: <identifier> expected
> int i = "".
>            ^
> 1 error

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From jwilhelm at openjdk.java.net  Mon Dec  7 20:25:16 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Mon, 7 Dec 2020 20:25:16 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v2]
In-Reply-To: <tGzaObdw0dM1CrH9Epdjqd_lJnEmioaw7trPSWiwaYg=.a65a256b-8517-4b06-a24c-f79c4f0ceb30@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <tGzaObdw0dM1CrH9Epdjqd_lJnEmioaw7trPSWiwaYg=.a65a256b-8517-4b06-a24c-f79c4f0ceb30@github.com>
Message-ID: <rp80Vgj0VdB_CsPictg1wkOOCE4WTZqNeU_-CLg1Y08=.c147742d-f902-4dc9-ae91-aeaff06294d5@github.com>

On Mon, 7 Dec 2020 19:38:41 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Start of JDK 17 updates.
>
> Joe Darcy 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 eight additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8257450
>  - Update tests.
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - JDK-8257450
>  - JDK-8257450
>  - JDK-8257450

Marked as reviewed by jwilhelm (Reviewer).

src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 234:

> 232:      * @since 17
> 233:      */
> 234:     RELEASE_17;

Would it make sense to have a RELEASE_LATEST for the cases that are just updated to the latest release every six months?

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

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

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec  7 20:35:19 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 7 Dec 2020 20:35:19 GMT
Subject: RFR: 6882207: Convert javap to use diamond operator internally
Message-ID: <B_3aVOV1mWiHfgxninu81FWTmgN9dXzckXZb9rTcDzQ=.b7aa8fd0-e92b-408b-a077-4c1a0f6f504e@github.com>

6882207: Convert javap to use diamond operator internally

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

Commit messages:
 - 6882207: Convert javap to use diamond operator internally

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

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

From vromero at openjdk.java.net  Mon Dec  7 20:36:14 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 7 Dec 2020 20:36:14 GMT
Subject: RFR: 7194212: NPE in Flow.visitIdent
In-Reply-To: <ata8yNXB-KSWpLrfUUS2_W4__kQCxkBYK-j8itCCR0s=.0fd12b0b-f2c6-49a7-a107-da29779a097c@github.com>
References: <ata8yNXB-KSWpLrfUUS2_W4__kQCxkBYK-j8itCCR0s=.0fd12b0b-f2c6-49a7-a107-da29779a097c@github.com>
Message-ID: <2xiiR2ddvAJ8Y7mtQ9iP4iMQzQIchJnUInYopItzq_c=.9bac5aad-0cd9-4787-9df9-01ead06ca219@github.com>

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

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

looks sensible

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

Marked as reviewed by vromero (Reviewer).

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

From darcy at openjdk.java.net  Mon Dec  7 20:49:28 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 7 Dec 2020 20:49:28 GMT
Subject: RFR: 8257799: Update JLS cross-references in java.compiler [v2]
In-Reply-To: <X3bitfIhnWvSPBcNfBtVwarzCAXz5DK38ZWPM0pZ68Y=.def190bd-b039-42b0-84bc-912fbcf4a0c7@github.com>
References: <X3bitfIhnWvSPBcNfBtVwarzCAXz5DK38ZWPM0pZ68Y=.def190bd-b039-42b0-84bc-912fbcf4a0c7@github.com>
Message-ID: <4RSGX8wqc89dQ1TKjM_SHGBHBjQYGN8I9arkS6shi7s=.c63d9172-0773-414f-a262-7983e7aa96ff@github.com>

> A few of the @jls tags in the java.compiler module don't make the corresponding JLS section anymore; the null literal section and constant expression sections were renumbered.
> 
> This change makes corrects the mismatches.

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

  Update copyright year.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1642/files
  - new: https://git.openjdk.java.net/jdk/pull/1642/files/6490dcb9..35a7fb6f

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

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

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

From darcy at openjdk.java.net  Mon Dec  7 20:49:28 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 7 Dec 2020 20:49:28 GMT
Subject: Integrated: 8257799: Update JLS cross-references in java.compiler
In-Reply-To: <X3bitfIhnWvSPBcNfBtVwarzCAXz5DK38ZWPM0pZ68Y=.def190bd-b039-42b0-84bc-912fbcf4a0c7@github.com>
References: <X3bitfIhnWvSPBcNfBtVwarzCAXz5DK38ZWPM0pZ68Y=.def190bd-b039-42b0-84bc-912fbcf4a0c7@github.com>
Message-ID: <unMiRlz7bvZFUrta8IQkm93NT-tV-_Z-NtgpB94DhBw=.1dff62a1-0abc-4d77-b43d-56b35f5ef8ce@github.com>

On Sat, 5 Dec 2020 21:37:34 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> A few of the @jls tags in the java.compiler module don't make the corresponding JLS section anymore; the null literal section and constant expression sections were renumbered.
> 
> This change makes corrects the mismatches.

This pull request has now been integrated.

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

8257799: Update JLS cross-references in java.compiler

Reviewed-by: jjg

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

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

From joe.darcy at oracle.com  Mon Dec  7 21:03:05 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 7 Dec 2020 13:03:05 -0800
Subject: RFR: 8257799: Update JLS cross-references in java.compiler
In-Reply-To: <ncQat1WOYhlQo84ACOwihzAUFQSJDMJy3X2f3tCJUwM=.be3d0b20-92c8-46d5-9acf-88bc4bca83c5@github.com>
References: <X3bitfIhnWvSPBcNfBtVwarzCAXz5DK38ZWPM0pZ68Y=.def190bd-b039-42b0-84bc-912fbcf4a0c7@github.com>
 <ncQat1WOYhlQo84ACOwihzAUFQSJDMJy3X2f3tCJUwM=.be3d0b20-92c8-46d5-9acf-88bc4bca83c5@github.com>
Message-ID: <e81e4a19-0e71-4b4e-8033-3a5c2f1a0f4a@oracle.com>


On 12/7/2020 11:28 AM, Jonathan Gibbons wrote:
> On Sat, 5 Dec 2020 21:37:34 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>
>> A few of the @jls tags in the java.compiler module don't make the corresponding JLS section anymore; the null literal section and constant expression sections were renumbered.
>>
>> This change makes corrects the mismatches.
> Approved.
>
> It would also be reasonable to semi-automate checking whether this sort of edit is necessary as a formal jtreg test, perhaps using a static checked-in copy of the JLS and JVMS index, which is maybe updated near the end of each release. If you think that is worth pursuing, maybe you could file an issue in JBS.

Filed JDK-8257854: Add testing for stale @jls and @jvms tags.

Thanks,

-Joe


From darcy at openjdk.java.net  Mon Dec  7 21:20:14 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 7 Dec 2020 21:20:14 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v2]
In-Reply-To: <yDdsQ2hZCOJ3YiASuI8_uDOcFxTBjf1GHLl-MDYP-GA=.b9fbfbb5-6b0b-4a78-9f9a-c24615c20349@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <tGzaObdw0dM1CrH9Epdjqd_lJnEmioaw7trPSWiwaYg=.a65a256b-8517-4b06-a24c-f79c4f0ceb30@github.com>
 <yDdsQ2hZCOJ3YiASuI8_uDOcFxTBjf1GHLl-MDYP-GA=.b9fbfbb5-6b0b-4a78-9f9a-c24615c20349@github.com>
Message-ID: <4iF3Ow7gSpgzkpro43pm2kekcKtgDfnS6mclhehUz4Q=.8e64cd40-c1ba-44e2-8cf5-36b38fd52a45@github.com>

On Mon, 7 Dec 2020 20:08:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Joe Darcy 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 eight additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8257450
>>  - Update tests.
>>  - Merge branch 'master' into JDK-8257450
>>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>>  - JDK-8257450
>>  - JDK-8257450
>>  - JDK-8257450
>
> test/jdk/java/lang/module/ClassFileVersionsTest.java line 107:
> 
>> 105:                 { 61,   0,  Set.of(STATIC, TRANSITIVE) },
>> 106: 
>> 107:                 { 62,   0,  Set.of()},                       // JDK 18
> 
> This seems unduly repetitive. Could this be dynamically generated, perhaps in a future release?

I've had similar thoughts; that strikes me as a fine RFE for after this fork. I see what the code is doing, but haven't delved into the module system details to understand exactly the rationale for these tests. In any case, filed the RFE JDK-8257856: "Make ClassFileVersionsTest.java robust to JDK version updates."

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

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

From darcy at openjdk.java.net  Mon Dec  7 21:21:13 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 7 Dec 2020 21:21:13 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended
In-Reply-To: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
Message-ID: <p5CSjPuPQ9RjX_pLnbkpg1bvBwdhhxb52EiMSm_HvQg=.be4ac16f-c970-44f6-b3b1-7a458712750d@github.com>

On Mon, 7 Dec 2020 19:51:38 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this fix for JDK-8256867.  This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes).  Instead, the class is treated as a sealed class which cannot be extended nor implemented.  This new behavior conforms to the JVM Spec.
> 
> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes.
> 
> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Is there already CSR coverage of this change?

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

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

From hseigel at openjdk.java.net  Mon Dec  7 21:33:12 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 7 Dec 2020 21:33:12 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended
In-Reply-To: <p5CSjPuPQ9RjX_pLnbkpg1bvBwdhhxb52EiMSm_HvQg=.be4ac16f-c970-44f6-b3b1-7a458712750d@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
 <p5CSjPuPQ9RjX_pLnbkpg1bvBwdhhxb52EiMSm_HvQg=.be4ac16f-c970-44f6-b3b1-7a458712750d@github.com>
Message-ID: <h2S56yRSPj5RaX0nV-pLTZBevjFVzjFU1bz79Bx5kq0=.eb0f08d9-b7bb-486e-b4e3-d860cfd93b9f@github.com>

On Mon, 7 Dec 2020 21:18:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Please review this fix for JDK-8256867.  This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes).  Instead, the class is treated as a sealed class which cannot be extended nor implemented.  This new behavior conforms to the JVM Spec.
>> 
>> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes.
>> 
>> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64.
>> 
>> Thanks, Harold
>
> Is there already CSR coverage of this change?

There is no CSR because I viewed this as a bug fix / spec conformance issue.  But, I can write a CSR if you think one is needed.

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

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

From lfoltan at openjdk.java.net  Mon Dec  7 21:33:11 2020
From: lfoltan at openjdk.java.net (Lois Foltan)
Date: Mon, 7 Dec 2020 21:33:11 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended
In-Reply-To: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
Message-ID: <JAGDtAri5tRHfu6OWiEbbapk0D1K50lsMXs1ZtOZ9Hg=.8a1b6614-a7fb-48a0-ba48-e69992a776f5@github.com>

On Mon, 7 Dec 2020 19:51:38 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this fix for JDK-8256867.  This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes).  Instead, the class is treated as a sealed class which cannot be extended nor implemented.  This new behavior conforms to the JVM Spec.
> 
> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes.
> 
> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Changes looks good Harold.
Lois

src/hotspot/share/prims/jvm.cpp line 2130:

> 2128:     JvmtiVMObjectAllocEventCollector oam;
> 2129:     Array<u2>* subclasses = ik->permitted_subclasses();
> 2130:     int length = subclasses == NULL ? 0 : subclasses->length();

Minor comment - you don't really need the check of subclasses == NULL here since subclasses will never be NULL.  You could just assign length to subclasses->length();

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

Marked as reviewed by lfoltan (Reviewer).

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

From mchung at openjdk.java.net  Mon Dec  7 21:59:12 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 7 Dec 2020 21:59:12 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended
In-Reply-To: <JAGDtAri5tRHfu6OWiEbbapk0D1K50lsMXs1ZtOZ9Hg=.8a1b6614-a7fb-48a0-ba48-e69992a776f5@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
 <JAGDtAri5tRHfu6OWiEbbapk0D1K50lsMXs1ZtOZ9Hg=.8a1b6614-a7fb-48a0-ba48-e69992a776f5@github.com>
Message-ID: <1kcTuIiOFlvGm3E3_Pig7uvR0fkKTBE5851DyNFLUHg=.1db1e565-eb47-4721-8314-b9ccf5fdd07f@github.com>

On Mon, 7 Dec 2020 21:30:18 GMT, Lois Foltan <lfoltan at openjdk.org> wrote:

>> Please review this fix for JDK-8256867.  This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes).  Instead, the class is treated as a sealed class which cannot be extended nor implemented.  This new behavior conforms to the JVM Spec.
>> 
>> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes.
>> 
>> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64.
>> 
>> Thanks, Harold
>
> Changes looks good Harold.
> Lois

Hi Harold,

> There is no CSR because I viewed this as a bug fix / spec conformance issue. But, I can write a CSR if you think one is needed.

This spec change needs a CSR since the return value is changed if this class is not sealed.  Please create one.

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

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

From darcy at openjdk.java.net  Mon Dec  7 22:44:17 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 7 Dec 2020 22:44:17 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v2]
In-Reply-To: <rp80Vgj0VdB_CsPictg1wkOOCE4WTZqNeU_-CLg1Y08=.c147742d-f902-4dc9-ae91-aeaff06294d5@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <tGzaObdw0dM1CrH9Epdjqd_lJnEmioaw7trPSWiwaYg=.a65a256b-8517-4b06-a24c-f79c4f0ceb30@github.com>
 <rp80Vgj0VdB_CsPictg1wkOOCE4WTZqNeU_-CLg1Y08=.c147742d-f902-4dc9-ae91-aeaff06294d5@github.com>
Message-ID: <UtJBi5TfjEl2UGdNSgwEZeb4GKeLi0HEWr6US7Pe52s=.a71a3b90-85d4-4b65-a351-5474064c8bb3@github.com>

On Mon, 7 Dec 2020 20:20:58 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

>> Joe Darcy 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 eight additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8257450
>>  - Update tests.
>>  - Merge branch 'master' into JDK-8257450
>>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>>  - JDK-8257450
>>  - JDK-8257450
>>  - JDK-8257450
>
> src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 234:
> 
>> 232:      * @since 17
>> 233:      */
>> 234:     RELEASE_17;
> 
> Would it make sense to have a RELEASE_LATEST for the cases that are just updated to the latest release every six months?

That kind of design was considered and rejected with the API was initially added. The use of enum constants in annotations must be an actual enum constant, not just a static final field pointing to a particular enum value. It would be possible to conceptually alias RELEASE_LATEST with whatever actual constant was the latest (16, then 17, then 18...), but that would cause issues with other uses of the API.

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

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

From vromero at openjdk.java.net  Mon Dec  7 23:47:20 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 7 Dec 2020 23:47:20 GMT
Subject: RFR: 8257855: Example SafeVarargsNotApplicableToRecordAccessors
 breaks test tools/javac/diags/CheckExamples.java
Message-ID: <q83SdaLNqBwuggG03wPvWTdTtAK6Y9w60URYsD0qwZQ=.56c634d8-67bd-43cf-a2e4-c8b422592e21@github.com>

Hi,

Please review this patch which is removing some keys and one option to test: `test/langtools/tools/javac/diags/examples/SafeVarargsNotApplicableToRecordAccessors.java` The PR that pushed the fix (JDK-8254784)[https://bugs.openjdk.java.net/browse/JDK-8254784] for was developed in parallel with the one that made records a standard feature in Java. I forgot to remove these options before pushing the final version of the code,

TIA

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

Commit messages:
 - 8257855: Example SafeVarargsNotApplicableToRecordAccessors breaks test tools/javac/diags/CheckExamples.java

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

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

From jjg at openjdk.java.net  Mon Dec  7 23:52:14 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 7 Dec 2020 23:52:14 GMT
Subject: RFR: 8257855: Example SafeVarargsNotApplicableToRecordAccessors
 breaks test tools/javac/diags/CheckExamples.java
In-Reply-To: <q83SdaLNqBwuggG03wPvWTdTtAK6Y9w60URYsD0qwZQ=.56c634d8-67bd-43cf-a2e4-c8b422592e21@github.com>
References: <q83SdaLNqBwuggG03wPvWTdTtAK6Y9w60URYsD0qwZQ=.56c634d8-67bd-43cf-a2e4-c8b422592e21@github.com>
Message-ID: <7J-kLjxBkK7r6bB6eGlJ6k_dZ_eADw2b1dtElsGAAKI=.ef4e58b3-d63b-48d1-8bfe-9c1aab9ed6ba@github.com>

On Mon, 7 Dec 2020 23:42:47 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Hi,
> 
> Please review this patch which is removing some keys and one option to test: `test/langtools/tools/javac/diags/examples/SafeVarargsNotApplicableToRecordAccessors.java` The PR that pushed the fix (JDK-8254784)[https://bugs.openjdk.java.net/browse/JDK-8254784] for was developed in parallel with the one that made records a standard feature in Java. I forgot to remove these options before pushing the final version of the code,
> 
> TIA

Marked as reviewed by jjg (Reviewer).

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

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

From mchung at openjdk.java.net  Tue Dec  8 00:02:13 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 8 Dec 2020 00:02:13 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended
In-Reply-To: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
Message-ID: <pYsyZC0xuSg34F14eeWjF6tVXsMM4GrtHc6d1DSVeV4=.53041b96-8625-4c04-88c9-4e2b4c4ba1ef@github.com>

On Mon, 7 Dec 2020 19:51:38 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this fix for JDK-8256867.  This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes).  Instead, the class is treated as a sealed class which cannot be extended nor implemented.  This new behavior conforms to the JVM Spec.
> 
> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes.
> 
> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64.
> 
> Thanks, Harold

src/java.base/share/classes/java/lang/Class.java line 4396:

> 4394:      * is unspecified. If this {@code Class} object represents a primitive type,
> 4395:      * {@code void}, an array type, or a class or interface that is not sealed,
> 4396:      * then null is returned.

nit: s/null/`{@code null}`

I'd suggest to clarify if this sealed class or interface has no permitted subclass, something like this:
Returns an array containing {@code Class} objects representing the
direct subinterfaces or subclasses permitted to extend or
implement this class or interface if it is sealed.  The order of such elements
is unspecified.   The array is empty if this sealed class or interface has no
permitted subclass. 

`@return` needs to be revised as well:
@return an array of {@code Class} objects of the permitted subclasses of this sealed class or interface,
     or {@null} if this class or interface is not sealed

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

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

From mchung at openjdk.java.net  Tue Dec  8 00:16:12 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 8 Dec 2020 00:16:12 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended
In-Reply-To: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
Message-ID: <YEHnrGgzCcCEHgCKxEopxpGt_UxnX1ZKAqd8AaMf_tM=.50d6ad27-815f-42dc-851e-078d82efee5d@github.com>

On Mon, 7 Dec 2020 19:51:38 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this fix for JDK-8256867.  This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes).  Instead, the class is treated as a sealed class which cannot be extended nor implemented.  This new behavior conforms to the JVM Spec.
> 
> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes.
> 
> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Other changes look okay except the spec of `Class::getPermittedSubclasses`

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

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

From mchung at openjdk.java.net  Tue Dec  8 00:16:14 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 8 Dec 2020 00:16:14 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended
In-Reply-To: <JAGDtAri5tRHfu6OWiEbbapk0D1K50lsMXs1ZtOZ9Hg=.8a1b6614-a7fb-48a0-ba48-e69992a776f5@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
 <JAGDtAri5tRHfu6OWiEbbapk0D1K50lsMXs1ZtOZ9Hg=.8a1b6614-a7fb-48a0-ba48-e69992a776f5@github.com>
Message-ID: <kU1QHA8TpwTjBYUtu78to9SntPU7rEB_k-mZUBD7lGc=.a9a5180c-c4b6-4a7c-8f8a-cc57dd87af86@github.com>

On Mon, 7 Dec 2020 21:29:23 GMT, Lois Foltan <lfoltan at openjdk.org> wrote:

>> Please review this fix for JDK-8256867.  This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes).  Instead, the class is treated as a sealed class which cannot be extended nor implemented.  This new behavior conforms to the JVM Spec.
>> 
>> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes.
>> 
>> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64.
>> 
>> Thanks, Harold
>
> src/hotspot/share/prims/jvm.cpp line 2130:
> 
>> 2128:     JvmtiVMObjectAllocEventCollector oam;
>> 2129:     Array<u2>* subclasses = ik->permitted_subclasses();
>> 2130:     int length = subclasses == NULL ? 0 : subclasses->length();
> 
> Minor comment - you don't really need the check of subclasses == NULL here since subclasses will never be NULL.  You could just assign length to subclasses->length();

+1.   is_sealed returns true iff `_permitted_subclasses != NULL`

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Dec  8 01:45:29 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 8 Dec 2020 01:45:29 GMT
Subject: RFR: 8245956: JavaCompiler still uses File API instead of Path
 API in a specific case [v2]
In-Reply-To: <dQCLUalaPhBxjTKrvGIY6c4d9m5HBRQfRu0QuoMUokM=.de840fae-cf05-4f95-9cc3-edf7646046ed@github.com>
References: <dQCLUalaPhBxjTKrvGIY6c4d9m5HBRQfRu0QuoMUokM=.de840fae-cf05-4f95-9cc3-edf7646046ed@github.com>
Message-ID: <jGoVUBqU4x4aPIkZ2VfuPrrsBrdZFbl20VvSE9fmsX4=.ad948eef-ea71-469b-a2f4-3d28aab5bb04@github.com>

> Hi all,
> 
> `JavacFileManager.getClassLoader` uses `getLocation` which causes exception in some situations.
> This patch uses `getLocationAsPaths` instead of `getLocation` to solve it.
> Thanks you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Rename variable. Revise comment. Add print statement after the method getClassLoader.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1553/files
  - new: https://git.openjdk.java.net/jdk/pull/1553/files/d9e8700e..f4d82b43

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

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

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

From mchung at openjdk.java.net  Tue Dec  8 02:43:19 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 8 Dec 2020 02:43:19 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
Message-ID: <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>

On Mon, 7 Dec 2020 19:31:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move to share/data, and move jdwp.spec to java.se
>
> I have reviewed all lines in the patch file with or near instances of `jdk.compiler`

Hi Magnus,

I see the motivation of moving these build files for better identification of ownership.   Placing them under
`src/$MODULE/{share,$OS}/data` is one option.  Given that skara will automatically determine appropriate mailing lists of a PR, it seems that `make/modules/$MODULE/data` can be another alternative that skara can include this pattern in the mailing list configuration??   I don't yet have a strong preference while I don't consider everything under `make` must be owned by the build team though.  Do you see one option is better than the other?

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

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

From darcy at openjdk.java.net  Tue Dec  8 03:33:31 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 8 Dec 2020 03:33:31 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v3]
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <tRUP2fV-wQaGbVthcyNveUMh91W74e_w9llIA-cpJnk=.054f9e97-3bbf-426f-a8a8-8050b7b6fae2@github.com>

> Start of JDK 17 updates.

Joe Darcy 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 ten additional commits since the last revision:

 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Update tests.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - JDK-8257450
 - JDK-8257450
 - JDK-8257450

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1531/files
  - new: https://git.openjdk.java.net/jdk/pull/1531/files/f6a64473..96e75b08

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

  Stats: 851 lines in 29 files changed: 560 ins; 163 del; 128 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1531.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531

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

From vromero at openjdk.java.net  Tue Dec  8 04:11:12 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 8 Dec 2020 04:11:12 GMT
Subject: Integrated: 8257855: Example
 SafeVarargsNotApplicableToRecordAccessors breaks test
 tools/javac/diags/CheckExamples.java
In-Reply-To: <q83SdaLNqBwuggG03wPvWTdTtAK6Y9w60URYsD0qwZQ=.56c634d8-67bd-43cf-a2e4-c8b422592e21@github.com>
References: <q83SdaLNqBwuggG03wPvWTdTtAK6Y9w60URYsD0qwZQ=.56c634d8-67bd-43cf-a2e4-c8b422592e21@github.com>
Message-ID: <dtXfeHxkUeHVqyB42fMRhEVKbZHCsyyEWMDswjB52CU=.cf0b8037-d375-4795-8b9c-e6c2230fe8c9@github.com>

On Mon, 7 Dec 2020 23:42:47 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Hi,
> 
> Please review this patch which is removing some keys and one option to test: `test/langtools/tools/javac/diags/examples/SafeVarargsNotApplicableToRecordAccessors.java` The PR that pushed the fix (JDK-8254784)[https://bugs.openjdk.java.net/browse/JDK-8254784] for was developed in parallel with the one that made records a standard feature in Java. I forgot to remove these options before pushing the final version of the code,
> 
> TIA

This pull request has now been integrated.

Changeset: 6ff18e38
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6ff18e38
Stats:     3 lines in 1 file changed: 0 ins; 3 del; 0 mod

8257855: Example SafeVarargsNotApplicableToRecordAccessors breaks test tools/javac/diags/CheckExamples.java

Reviewed-by: jjg

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Dec  8 04:51:13 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 8 Dec 2020 04:51:13 GMT
Subject: RFR: 8231622: SuppressWarning("serial") ignored on field
 serialVersionUID [v2]
In-Reply-To: <7FIRVZWxC7jmkBBDhFouBiN0s2NFUW3GeBOvkSN4lbw=.38d7d5c1-66f6-4597-a346-6b738c6c346d@github.com>
References: <_2Z8RhLQo1F6ddk2cZS5J_hoRMPLCe5ssVMeyyscFnc=.d267dddd-12d6-4968-a32d-6bd3510daf45@github.com>
 <EFt3JG5qibOriEpCuxCta2jxN-VSGYfkveexxYo9E0Q=.0a706fd2-62ca-4ff9-ae0d-69ed8c5edd28@github.com>
 <7FIRVZWxC7jmkBBDhFouBiN0s2NFUW3GeBOvkSN4lbw=.38d7d5c1-66f6-4597-a346-6b738c6c346d@github.com>
Message-ID: <LsmNk_tM3MSV_qvD23l6b7VjT4GBtfNQSzaRROd9Efo=.e51e406f-72a0-4c62-87d7-7b5b789b6a2f@github.com>

On Mon, 7 Dec 2020 19:21:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revise test cases. Remove legal header and add /nodynamiccopyright/
>
> I approve these changes.
> 
> That being said, a more modern idiom for negative tests involving small source files and corresponding small golden files, is to write a single file that uses library code like `toolbox.ToolBox` to write files on the fly, perhaps from content in a text block, and to compare the output against another text block.  For slightly more advanced usage, you can compile strings directly using API like `SimpleJavaFileObject`, and avoid the file system altogether.

> Can you give me a list of tests that you think need to be addressed?

I write a python script to help me to find the possible wrong style tests. The script finds string `Copyright`, `ref=` and `-XDrawDiagnostics` in the files of directory `test`. If a file contains these three strings, it will print the full path name of the file to `result.txt`.

As you can see the entries in the annex `result.txt`, for example, the `test/langtools/tools/doclint/multipackage/MultiPackage.java` is not a wrong style test and `test/langtools/tools/javac/AnonStaticMember_1.java` is a wrong style test.
Later, I will check all the entries manually and revise the wrong style tests because I can't find a better way to do that.

The content of the python script is shown below. I don't attach it as an annex because GitHub doesn't support the python file type.
#!/usr/bin/python
import os


def clean(output_file):
    if os.path.exists(output_file):
        os.remove(output_file)


def outputFileName(full_path, output_file):
    output_file = open(output_file, 'a')
    output_file.write(full_path)
    output_file.write("\n")
    output_file.close()


def findStrListInTestFile(full_path, find_str_list):
    search_file = open(full_path, 'r')
    content = search_file.read()
    search_file.close()
    for find_str in find_str_list:
        is_found = content.find(find_str)
        if is_found == -1:
            return False
    return True


def findWrongStyleTests(find_dir, find_str_list, output_file):
    for dir_path, dir_names, file_names in os.walk(find_dir):
        for file_name in file_names:
            full_path = os.path.join(dir_path, file_name)
            is_found = findStrListInTestFile(full_path, find_str_list)
            if is_found:
                outputFileName(full_path, output_file)


if __name__ == "__main__":
    findDir = "test"
    findStrList = ["Copyright", "ref=", "-XDrawDiagnostics"]
    outputFile = "result.txt"
    clean(outputFile)
    findWrongStyleTests(findDir, findStrList, outputFile)


The steps to run the script are shown below.
- Enter the jdk main directory: `cd path/to/jdk`
- Create a new python script: `vim test.py`
- Copy the code above to the file `test.py`
- Use python command to run the script: `python test.py`

The file `result.txt` is shown below.
[result.txt](https://github.com/openjdk/jdk/files/5656821/result.txt)

Anyway, I don't think we should continue to discuss the concrete content in this patch.

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

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

From minqi at openjdk.java.net  Tue Dec  8 05:45:20 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Tue, 8 Dec 2020 05:45:20 GMT
Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed
 "assert(reserved_rgn != 0LL) failed: No reserved region" [v3]
In-Reply-To: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
Message-ID: <TguKP3F3tuAgdzImLvrt5s35nBTy1w6msEIGYNmWsq8=.0c36bee0-a2d6-48c0-84a8-a60b31e1df28@github.com>

> Hi, Please review
>   Windows mapping for file into memory could not happen to reserved memory. In mapping CDS archive we first reserve enough memory then before mapping, release them. For cds archive and using class space, need split the whole space into two, that is, release the whole reserved space and do reservation to the two split spaces again, which is problematic that there is possibility other thread or system can kick in to take the released space.
>   The fix is the first step of two steps:
>    1) Do not split reserved memory;
>    2) Remove splitting memory.
>    This fix is first step, for Windows and use requested mapping address, reserved for cds archive and ccs on a contiguous space separately, so there is no need to call split. If any reservation failed, release them, go to other way, but do not do the 'real' split either. For Windows (and using class space), the reserved space will be released anyway. 
> 
> Tests:tier1-5,tier7

Yumin Qi has updated the pull request incrementally with 32 additional commits since the last revision:

 - Add total_space_rs, total reserved space to release_reserved_spaces and reserve_address_space_for_archives, made changes to check failed output on test.
 - 8253762: JFR: getField(String) should be able to access subfields
   
   Reviewed-by: mgronlun
 - 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks
   
   Reviewed-by: jnimeh
 - 8257796: [TESTBUG] TestUseSHA512IntrinsicsOptionOnSupportedCPU.java fails on x86_32
   
   Reviewed-by: kvn
 - 8257211: C2: Enable call devirtualization during post-parse phase
   
   Reviewed-by: kvn, neliasso, thartmann
 - 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
   
   Reviewed-by: ihse, alanb, dcubed, erikj
 - 8257718: LogCompilation: late_inline doesnt work right for JDK 8 logs
   
   Reviewed-by: redestad, kvn
 - 8257799: Update JLS cross-references in java.compiler
   
   Reviewed-by: jjg
 - 8254939: macOS: unused function 'replicate4_imm'
   
   Reviewed-by: redestad, thartmann
 - 8257805: Add compiler/blackhole tests to tier1
   
   Reviewed-by: kvn
 - ... and 22 more: https://git.openjdk.java.net/jdk/compare/dd9ae050...f7958306

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1657/files
  - new: https://git.openjdk.java.net/jdk/pull/1657/files/dd9ae050..f7958306

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

  Stats: 8052 lines in 156 files changed: 4548 ins; 2755 del; 749 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1657.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1657/head:pull/1657

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

From darcy at openjdk.java.net  Tue Dec  8 06:12:35 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 8 Dec 2020 06:12:35 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v4]
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <xrNV9DXjcpcs6lplCqKzf84x6PGIA4K0Dw2XP64ufAY=.df6f2f6a-13ad-4a77-a21b-006d70cc72b7@github.com>

> Start of JDK 17 updates.

Joe Darcy 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 10 additional commits since the last revision:

 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Update tests.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - JDK-8257450
 - JDK-8257450
 - JDK-8257450

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1531/files
  - new: https://git.openjdk.java.net/jdk/pull/1531/files/96e75b08..342c8650

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

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

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

From alanb at openjdk.java.net  Tue Dec  8 07:48:13 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 8 Dec 2020 07:48:13 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v2]
In-Reply-To: <4iF3Ow7gSpgzkpro43pm2kekcKtgDfnS6mclhehUz4Q=.8e64cd40-c1ba-44e2-8cf5-36b38fd52a45@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <tGzaObdw0dM1CrH9Epdjqd_lJnEmioaw7trPSWiwaYg=.a65a256b-8517-4b06-a24c-f79c4f0ceb30@github.com>
 <yDdsQ2hZCOJ3YiASuI8_uDOcFxTBjf1GHLl-MDYP-GA=.b9fbfbb5-6b0b-4a78-9f9a-c24615c20349@github.com>
 <4iF3Ow7gSpgzkpro43pm2kekcKtgDfnS6mclhehUz4Q=.8e64cd40-c1ba-44e2-8cf5-36b38fd52a45@github.com>
Message-ID: <fLe7ehwFz63gQW31NJtcGKZLmnVNlaD7kjzrssybjG4=.d8213b0e-8b37-496a-a570-74bbf844d15e@github.com>

On Mon, 7 Dec 2020 21:14:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> test/jdk/java/lang/module/ClassFileVersionsTest.java line 107:
>> 
>>> 105:                 { 61,   0,  Set.of(STATIC, TRANSITIVE) },
>>> 106: 
>>> 107:                 { 62,   0,  Set.of()},                       // JDK 18
>> 
>> This seems unduly repetitive. Could this be dynamically generated, perhaps in a future release?
>
> I've had similar thoughts; that strikes me as a fine RFE for after this fork. I see what the code is doing, but haven't delved into the module system details to understand exactly the rationale for these tests. In any case, filed the RFE JDK-8257856: "Make ClassFileVersionsTest.java robust to JDK version updates."

There was a change to JVMS 4.7.25 in Java 10 to add a rule for the requires_flags that are allowed. This is why this test started was created to test 53.0 vs. 54.0 class files. It wasn't intended to be a burden to update at each release so I'll re-implement it.

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

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

From ihse at openjdk.java.net  Tue Dec  8 08:30:12 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 8 Dec 2020 08:30:12 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
Message-ID: <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>

On Tue, 8 Dec 2020 02:40:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> I have reviewed all lines in the patch file with or near instances of `jdk.compiler`
>
> Hi Magnus,
> 
> I see the motivation of moving these build files for better identification of ownership.   Placing them under
> `src/$MODULE/{share,$OS}/data` is one option.  Given that skara will automatically determine appropriate mailing lists of a PR, it seems that `make/modules/$MODULE/data` can be another alternative that skara can include this pattern in the mailing list configuration??   I don't yet have a strong preference while I don't consider everything under `make` must be owned by the build team though.  Do you see one option is better than the other?

@mlchung If you don't have any strong preference, I implore you to accept this change. I **vastly** prefer to move the data out of `make`!

This is not just about Skara tooling. When working with make files, autoconf and shell scripts, there is no fancy IDE support, so you are stuck with simple text editors and tools like `grep`. I've lost count on how many times I've had my grep searches blow up, since I happened to find e.g. a string in `tzdata` and get hundreds or more of hits. :-( And I do believe we will get a better code structure if the build team "owns" `make`;  or at least has a vested interest in what's in that directory. We still suffer a lot of the old "I don't know where to put this file, so I'll just put it in make cause nobody cares about it anyway" mentality, but I've been working for quite some time to make that list of misplaced files shorter and shorter.

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

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

From ihse at openjdk.java.net  Tue Dec  8 08:35:13 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 8 Dec 2020 08:35:13 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
Message-ID: <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>

On Tue, 8 Dec 2020 08:27:16 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Hi Magnus,
>> 
>> I see the motivation of moving these build files for better identification of ownership.   Placing them under
>> `src/$MODULE/{share,$OS}/data` is one option.  Given that skara will automatically determine appropriate mailing lists of a PR, it seems that `make/modules/$MODULE/data` can be another alternative that skara can include this pattern in the mailing list configuration??   I don't yet have a strong preference while I don't consider everything under `make` must be owned by the build team though.  Do you see one option is better than the other?
>
> @mlchung If you don't have any strong preference, I implore you to accept this change. I **vastly** prefer to move the data out of `make`!
> 
> This is not just about Skara tooling. When working with make files, autoconf and shell scripts, there is no fancy IDE support, so you are stuck with simple text editors and tools like `grep`. I've lost count on how many times I've had my grep searches blow up, since I happened to find e.g. a string in `tzdata` and get hundreds or more of hits. :-( And I do believe we will get a better code structure if the build team "owns" `make`;  or at least has a vested interest in what's in that directory. We still suffer a lot of the old "I don't know where to put this file, so I'll just put it in make cause nobody cares about it anyway" mentality, but I've been working for quite some time to make that list of misplaced files shorter and shorter.

Also, to clarify, for me there is a fundamental difference between `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files that are part of the module, owned by the content team, and the `$MODULE` part is essential to delineate this content. The latter is owned by the build team, and is just a convenient way to organize the build system within the `make` directory. So it's clearly a no-no to put anything but `.gmk` files in `make/modules/$MODULE`.

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

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

From jlahoda at openjdk.java.net  Tue Dec  8 08:41:12 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 8 Dec 2020 08:41:12 GMT
Subject: Integrated: 8256411: Based anonymous classes have a weird end position
In-Reply-To: <7aKd4Z5-b2wrbXxf5Kz2ZRjPKyl4Zw0JRVTt6e9hA2M=.71073831-380f-4a99-ad8d-1112a05af229@github.com>
References: <7aKd4Z5-b2wrbXxf5Kz2ZRjPKyl4Zw0JRVTt6e9hA2M=.71073831-380f-4a99-ad8d-1112a05af229@github.com>
Message-ID: <6yPOwF0e_CIGSGvrGh7DhJKGrWdH-VFOmkWAUD7hDwY=.989c5c8c-6415-4c16-b32a-0ecb2ea4e3b9@github.com>

On Mon, 16 Nov 2020 18:12:35 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like this:
> 
> package t;
> class Test {
>     class I {}
>     static Object S = new Test().new I() {};
> }
> 
> There is a synthetically generated `Test.I` in the extends clause of the anonymous class. The current end position for it is the end of the whole anonymous class (i.e. at '}'), which does not make much sense. The proposal is that the end position should be the end position of the "I" identifier, which is the same as if the anonymous class would not be based on an enclosing instance.

This pull request has now been integrated.

Changeset: 51ac3768
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/51ac3768
Stats:     39 lines in 3 files changed: 35 ins; 0 del; 4 mod

8256411: Based anonymous classes have a weird end position

Reviewed-by: vromero

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

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

From chegar at openjdk.java.net  Tue Dec  8 09:34:16 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 8 Dec 2020 09:34:16 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended
In-Reply-To: <pYsyZC0xuSg34F14eeWjF6tVXsMM4GrtHc6d1DSVeV4=.53041b96-8625-4c04-88c9-4e2b4c4ba1ef@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
 <pYsyZC0xuSg34F14eeWjF6tVXsMM4GrtHc6d1DSVeV4=.53041b96-8625-4c04-88c9-4e2b4c4ba1ef@github.com>
Message-ID: <0gY9SoxDO9oyPxcbLEKGp2Nv9JI1QTtk8OvCAqKvdtM=.51219b79-aa76-4e2d-bf93-0178a6f2e9b1@github.com>

On Mon, 7 Dec 2020 23:47:40 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Please review this fix for JDK-8256867.  This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes).  Instead, the class is treated as a sealed class which cannot be extended nor implemented.  This new behavior conforms to the JVM Spec.
>> 
>> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes.
>> 
>> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64.
>> 
>> Thanks, Harold
>
> src/java.base/share/classes/java/lang/Class.java line 4396:
> 
>> 4394:      * is unspecified. If this {@code Class} object represents a primitive type,
>> 4395:      * {@code void}, an array type, or a class or interface that is not sealed,
>> 4396:      * then null is returned.
> 
> nit: s/null/`{@code null}`
> 
> I'd suggest to clarify if this sealed class or interface has no permitted subclass, something like this:
> Returns an array containing {@code Class} objects representing the
> direct subinterfaces or subclasses permitted to extend or
> implement this class or interface if it is sealed.  The order of such elements
> is unspecified.   The array is empty if this sealed class or interface has no
> permitted subclass. 
> 
> `@return` needs to be revised as well:
> @return an array of {@code Class} objects of the permitted subclasses of this sealed class or interface,
>      or {@null} if this class or interface is not sealed

Mandy's suggested wording is good.

I would like to add one more additional point of clarification. It would
be good to strongly connect `isSealed` and `getPermittedClasses` in a
first-class way in normative spec ( similar to isRecord and
getRecordComponents ).

For example, 

  to `isSealed` add: "getPermittedSubclasses returns a non-null but possibly
       empty value for a sealed class."

  to `getPermittedSubclasses`: "If this class is not a sealed class, that is {@link
     * #isSealed()} returns {@code false}, then this method returns {@code null}.
     * Conversely, if {@link #isSealed()} returns {@code true}, then this method
     * returns a non-null value."

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

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

From jlahoda at openjdk.java.net  Tue Dec  8 09:44:23 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 8 Dec 2020 09:44:23 GMT
Subject: RFR: 8256266: Binding variables don't correct support declaration
 annotations and the final modifier [v4]
In-Reply-To: <7B3tW3Nouyc_OKLm9Be1H8VbeXVBL1WiRt8-V2ZwO2o=.02134c7e-2cc8-449f-a40d-bd6101150d0a@github.com>
References: <7B3tW3Nouyc_OKLm9Be1H8VbeXVBL1WiRt8-V2ZwO2o=.02134c7e-2cc8-449f-a40d-bd6101150d0a@github.com>
Message-ID: <8nXnKIH3Y5w6JWnqjB7lXJxMDr96cxejqW__x8h2DJc=.85e8deff-0b79-42a4-9d08-40b861393ce7@github.com>

> Basically, javac does not handle code like this properly:
> 
> import java.lang.annotation.*;
> 
> public class B {
>      public void test(Object o) {
>          if (o instanceof @A String s) {}
>      }
> }
> 
> @Target(ElementType.LOCAL_VARIABLE)
> @interface A {}
> 
> The parser needs to allow declaration annotations on binding variables, see:
> http://cr.openjdk.java.net/~gbierman/jep394/jep394-20201012/specs/patterns-instanceof-jls.html#jls-14.30.1.1

Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:

 - Removing forgotten debug call.
 - Reject final modifiers on non-pattern matching instanceof.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1192/files
  - new: https://git.openjdk.java.net/jdk/pull/1192/files/fd6a79fe..3923090a

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

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

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

From jlahoda at openjdk.java.net  Tue Dec  8 09:49:15 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 8 Dec 2020 09:49:15 GMT
Subject: RFR: 8256266: Binding variables don't correct support declaration
 annotations and the final modifier [v3]
In-Reply-To: <O4albWTA_QfRRBu1_mBcaMAL00a3uZifjMl9YrFWsjI=.505b7109-9a86-418e-9494-c1669a35ad94@github.com>
References: <7B3tW3Nouyc_OKLm9Be1H8VbeXVBL1WiRt8-V2ZwO2o=.02134c7e-2cc8-449f-a40d-bd6101150d0a@github.com>
 <CFeLFJmVUPu9toG1Nh-v1AL7sW-DujZwceK75UEUAbY=.339ff994-bdd3-4f11-ab4b-4ed22d97e78d@github.com>
 <O4albWTA_QfRRBu1_mBcaMAL00a3uZifjMl9YrFWsjI=.505b7109-9a86-418e-9494-c1669a35ad94@github.com>
Message-ID: <GQZEeOGnBSaiEnge2X8tqbnj1Y3xgcGPE1cB88pmsv4=.0f821ccb-9bf8-4bcd-b490-1831f3351aea@github.com>

On Mon, 7 Dec 2020 13:47:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing tests.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 946:
> 
>> 944:                     TreeInfo.getStartPos(pattern);
>> 945:                 } else {
>> 946:                     if (mods.annotations.nonEmpty()) {
> 
> We don't seem to check for the source level here? E.g. is it possible that `instanceof @Foo Bar` will not issue the usual error if compiled with source != 16?

Oops. Having `instanceof @Foo Bar` is valid, due to type annotations. See e.g.:
https://github.com/openjdk/jdk/blob/d2b66196b4509a32613f476d7247f207289a75e3/test/langtools/tools/javac/annotations/typeAnnotations/TargetTypes.java#L102

But, when I was adding support for the final modifier on binding variables, I've forgot to disable the final modifier on non-pattern matching `instanceof`, so code like `o instanceof final String` was accepted, which is, of course, wrong.

This should be fixed by:
https://github.com/openjdk/jdk/pull/1192/commits/a737f9229adf86af90fdab98a67ad009d76ab44c

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

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

From alanb at openjdk.java.net  Tue Dec  8 12:18:20 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 8 Dec 2020 12:18:20 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
Message-ID: <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>

On Tue, 8 Dec 2020 08:32:28 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> @mlchung If you don't have any strong preference, I implore you to accept this change. I **vastly** prefer to move the data out of `make`!
>> 
>> This is not just about Skara tooling. When working with make files, autoconf and shell scripts, there is no fancy IDE support, so you are stuck with simple text editors and tools like `grep`. I've lost count on how many times I've had my grep searches blow up, since I happened to find e.g. a string in `tzdata` and get hundreds or more of hits. :-( And I do believe we will get a better code structure if the build team "owns" `make`;  or at least has a vested interest in what's in that directory. We still suffer a lot of the old "I don't know where to put this file, so I'll just put it in make cause nobody cares about it anyway" mentality, but I've been working for quite some time to make that list of misplaced files shorter and shorter.
>
> Also, to clarify, for me there is a fundamental difference between `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files that are part of the module, owned by the content team, and the `$MODULE` part is essential to delineate this content. The latter is owned by the build team, and is just a convenient way to organize the build system within the `make` directory. So it's clearly a no-no to put anything but `.gmk` files in `make/modules/$MODULE`.

The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.

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

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

From mcimadamore at openjdk.java.net  Tue Dec  8 12:47:13 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 8 Dec 2020 12:47:13 GMT
Subject: RFR: 8256266: Binding variables don't correct support declaration
 annotations and the final modifier [v4]
In-Reply-To: <8nXnKIH3Y5w6JWnqjB7lXJxMDr96cxejqW__x8h2DJc=.85e8deff-0b79-42a4-9d08-40b861393ce7@github.com>
References: <7B3tW3Nouyc_OKLm9Be1H8VbeXVBL1WiRt8-V2ZwO2o=.02134c7e-2cc8-449f-a40d-bd6101150d0a@github.com>
 <8nXnKIH3Y5w6JWnqjB7lXJxMDr96cxejqW__x8h2DJc=.85e8deff-0b79-42a4-9d08-40b861393ce7@github.com>
Message-ID: <_FJAmi9u-u6iV0YsbYoM4EY6x4Ho5e26SZSmduPQNhE=.b1549acd-f958-4315-a97e-3b6d9dbc5232@github.com>

On Tue, 8 Dec 2020 09:44:23 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Basically, javac does not handle code like this properly:
>> 
>> import java.lang.annotation.*;
>> 
>> public class B {
>>      public void test(Object o) {
>>          if (o instanceof @A String s) {}
>>      }
>> }
>> 
>> @Target(ElementType.LOCAL_VARIABLE)
>> @interface A {}
>> 
>> The parser needs to allow declaration annotations on binding variables, see:
>> http://cr.openjdk.java.net/~gbierman/jep394/jep394-20201012/specs/patterns-instanceof-jls.html#jls-14.30.1.1
>
> Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Removing forgotten debug call.
>  - Reject final modifiers on non-pattern matching instanceof.

Changes look good to me

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

Marked as reviewed by mcimadamore (Reviewer).

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Dec  8 13:02:33 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 8 Dec 2020 13:02:33 GMT
Subject: RFR: 8231622: SuppressWarning("serial") ignored on field
 serialVersionUID [v3]
In-Reply-To: <_2Z8RhLQo1F6ddk2cZS5J_hoRMPLCe5ssVMeyyscFnc=.d267dddd-12d6-4968-a32d-6bd3510daf45@github.com>
References: <_2Z8RhLQo1F6ddk2cZS5J_hoRMPLCe5ssVMeyyscFnc=.d267dddd-12d6-4968-a32d-6bd3510daf45@github.com>
Message-ID: <dLH3TZ0frTK_o5WhhPqxBbc7HfIqE81WK4JJuAZFURI=.52b74fab-d793-4f6b-b9cd-7a4de6d23f0b@github.com>

> Hi all,
> 
> Currently, a warning is generated when compiling the following code by using the option `-Xlint`.
> 
> import java.io.Serializable;
> class B implements Serializable {
>     @SuppressWarnings("serial")
>     private static final byte serialVersionUID = 5;
> }
> 
> output:
> B.java:4: warning: [serial] serialVersionUID must be of type long in class B
>     private static final byte serialVersionUID = 5;
>                               ^
> 1 warning
> 
> The annotation `@SuppressWarnings("serial")` on  field serialVersionUID is ignored by the compiler.
> This patch fixes it and adds some tests.
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li 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 four additional commits since the last revision:

 - Revise tests by using library toolbox.
 - Merge remote-tracking branch 'origin' into JDK-8231622
 - Revise test cases. Remove legal header and add /nodynamiccopyright/
 - 8231622: SuppressWarning(serial) ignored on field serialVersionUID

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1626/files
  - new: https://git.openjdk.java.net/jdk/pull/1626/files/16eeaa56..752ccba4

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

  Stats: 14872 lines in 368 files changed: 9645 ins; 3818 del; 1409 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1626.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1626/head:pull/1626

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Dec  8 13:05:12 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 8 Dec 2020 13:05:12 GMT
Subject: RFR: 8231622: SuppressWarning("serial") ignored on field
 serialVersionUID [v2]
In-Reply-To: <7FIRVZWxC7jmkBBDhFouBiN0s2NFUW3GeBOvkSN4lbw=.38d7d5c1-66f6-4597-a346-6b738c6c346d@github.com>
References: <_2Z8RhLQo1F6ddk2cZS5J_hoRMPLCe5ssVMeyyscFnc=.d267dddd-12d6-4968-a32d-6bd3510daf45@github.com>
 <EFt3JG5qibOriEpCuxCta2jxN-VSGYfkveexxYo9E0Q=.0a706fd2-62ca-4ff9-ae0d-69ed8c5edd28@github.com>
 <7FIRVZWxC7jmkBBDhFouBiN0s2NFUW3GeBOvkSN4lbw=.38d7d5c1-66f6-4597-a346-6b738c6c346d@github.com>
Message-ID: <YP4kF1w7NZgK_8y45e6aF-ViX4d9O9OSc7f7eMXLh8c=.c5c08f3e-aa63-4354-bf93-900fc48c0b29@github.com>

On Mon, 7 Dec 2020 19:21:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revise test cases. Remove legal header and add /nodynamiccopyright/
>
> I approve these changes.
> 
> That being said, a more modern idiom for negative tests involving small source files and corresponding small golden files, is to write a single file that uses library code like `toolbox.ToolBox` to write files on the fly, perhaps from content in a text block, and to compare the output against another text block.  For slightly more advanced usage, you can compile strings directly using API like `SimpleJavaFileObject`, and avoid the file system altogether.

@jonathan-gibbons I revise the test code by using the library toolbox. Thank you for taking the time to review.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Dec  8 13:07:13 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 8 Dec 2020 13:07:13 GMT
Subject: RFR: 8245956: JavaCompiler still uses File API instead of Path
 API in a specific case [v2]
In-Reply-To: <J-s2OmwvaqqltLqlKWl-9_qhBl1D8hFciL6B7Sv9yzo=.01c71a80-48c1-48e9-bcab-8b79c340ea5f@github.com>
References: <dQCLUalaPhBxjTKrvGIY6c4d9m5HBRQfRu0QuoMUokM=.de840fae-cf05-4f95-9cc3-edf7646046ed@github.com>
 <J-s2OmwvaqqltLqlKWl-9_qhBl1D8hFciL6B7Sv9yzo=.01c71a80-48c1-48e9-bcab-8b79c340ea5f@github.com>
Message-ID: <JL6mPMeySyEUde1wWfARO8tjh6hbtnybm1bCcWlPvmc=.27fc1e38-8dc2-4653-812d-db81ee02eb31@github.com>

On Mon, 7 Dec 2020 19:58:28 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename variable. Revise comment. Add print statement after the method getClassLoader.
>
> Marked as reviewed by jjg (Reviewer).

@jonathan-gibbons I revise the code according to your suggestions. Thank you for taking the time to review.

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

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

From jlahoda at openjdk.java.net  Tue Dec  8 13:12:21 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 8 Dec 2020 13:12:21 GMT
Subject: RFR: 8256149: Weird AST structure for incomplete member select
 [v2]
In-Reply-To: <c09LcmEH_zjugw6V0nu2cWy_iSQrxL--uEL5Iq3zv6I=.cc1b09a7-2219-4abf-ad8c-718dcac7e43f@github.com>
References: <c09LcmEH_zjugw6V0nu2cWy_iSQrxL--uEL5Iq3zv6I=.cc1b09a7-2219-4abf-ad8c-718dcac7e43f@github.com>
Message-ID: <BBC9HlvSaNq9oc_oFZCieihkOdF_5TKW4Qx1zk20EyE=.f9202087-60ce-42d8-8884-91de6354f41e@github.com>

> Consider code like:
> int i1 = "".
> @Deprecated
> void t1() {}
> 
> In current master, this will produce a somewhat twisted AST, and compile-time errors like:
> E.java:2: error: <identifier> expected
> int i = "".
>            ^
> E.java:3: error: illegal start of expression
> @Deprecated void t() {}
> ^
> E.java:3: error: ';' expected
> @Deprecated void t() {}
>            ^
> 3 errors
> 
> The reason is that `@Deprecated` is parsed as a type annotation following `"".<missing>`, which does not make much sense.
> 
> With this proposed patch, the AST is effectively the same as AST for:
> int i1 = "".; //note the semicolon here
> @Deprecated
> void t1() {}
> 
> And the errors are much better as well:
> E.java:2: error: <identifier> expected
> int i = "".
>            ^
> 1 error

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merging master into JDK-8256149
 - 8256149: Weird AST structure for incomplete member select

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

Changes: https://git.openjdk.java.net/jdk/pull/1159/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1159&range=01
  Stats: 61 lines in 2 files changed: 60 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1159.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1159/head:pull/1159

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

From jlahoda at openjdk.java.net  Tue Dec  8 13:12:22 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 8 Dec 2020 13:12:22 GMT
Subject: Integrated: 8256149: Weird AST structure for incomplete member select
In-Reply-To: <c09LcmEH_zjugw6V0nu2cWy_iSQrxL--uEL5Iq3zv6I=.cc1b09a7-2219-4abf-ad8c-718dcac7e43f@github.com>
References: <c09LcmEH_zjugw6V0nu2cWy_iSQrxL--uEL5Iq3zv6I=.cc1b09a7-2219-4abf-ad8c-718dcac7e43f@github.com>
Message-ID: <8VrGAfeP3AsI3tggXMy9Y-GUlCReWIu5CXL90hg9uhA=.133448ae-a94d-42a6-a41c-cf248de06d99@github.com>

On Wed, 11 Nov 2020 09:01:52 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like:
> int i1 = "".
> @Deprecated
> void t1() {}
> 
> In current master, this will produce a somewhat twisted AST, and compile-time errors like:
> E.java:2: error: <identifier> expected
> int i = "".
>            ^
> E.java:3: error: illegal start of expression
> @Deprecated void t() {}
> ^
> E.java:3: error: ';' expected
> @Deprecated void t() {}
>            ^
> 3 errors
> 
> The reason is that `@Deprecated` is parsed as a type annotation following `"".<missing>`, which does not make much sense.
> 
> With this proposed patch, the AST is effectively the same as AST for:
> int i1 = "".; //note the semicolon here
> @Deprecated
> void t1() {}
> 
> And the errors are much better as well:
> E.java:2: error: <identifier> expected
> int i = "".
>            ^
> 1 error

This pull request has now been integrated.

Changeset: d0c52651
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d0c52651
Stats:     61 lines in 2 files changed: 60 ins; 0 del; 1 mod

8256149: Weird AST structure for incomplete member select

Reviewed-by: vromero

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Dec  8 13:19:14 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 8 Dec 2020 13:19:14 GMT
Subject: RFR: 8254023: A module declaration is not allowed to be a target
 of an annotation that lacks an @Target meta-annotation
In-Reply-To: <tBB2q0ATDEr8k86St14cqLVTAwy2CH34WolOWfPH1bw=.e9a456ad-28c8-4e36-9eb4-62024a96c0e4@github.com>
References: <wFdu9AyyNU2SB0nWx9mq_2syF2XyQIB0z6Rmc-r1fNc=.369439d1-385e-4fd1-aac1-72e48ac246e8@github.com>
 <pqSfmocPi4AJGQJEJl4j6UgITEL0f62TKSVpxwOer6w=.49e74a9b-ecb0-4a13-9dfc-93c27fd5149a@github.com>
 <5_HZhCK8rd2yWcf4XzGa_N50I1Xl3CMmUXSugfoJIUk=.379b61e3-e4a3-4509-ac7b-940a25ae4609@github.com>
 <6VDsNZKAYnkmm_YsLRjClBhqPMPPqy4d3TrWLcElkOU=.3f9b9d49-4e49-4574-a07c-6f72acefcfd2@github.com>
 <tBB2q0ATDEr8k86St14cqLVTAwy2CH34WolOWfPH1bw=.e9a456ad-28c8-4e36-9eb4-62024a96c0e4@github.com>
Message-ID: <7sWMYyBTyXojxTilJbHx3YALtC1xRWZFcLtp_x_T7Go=.26c155c0-becf-4bbd-9cf1-588fc4040074@github.com>

On Mon, 7 Dec 2020 15:51:59 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>>> Short term (Java 16) it makes sense to fix https://bugs.openjdk.java.net/browse/JDK-8254023 given that both competing specs agree for this case, it is a small fix, and externally found.
>>>
>>>For Java 17 we should align both specs and the reference implementation one way or another.
>> 
>> @jbf According to your comments, I revise my code to only fix JDK-8254023.
>> The rest of the work, ambiguity of the specifications, will be clarified and fixed in Java 17.
>> Thank you for taking the time to review.
>
> the change looks good but I'm surprised that no other tests are failing and need changes, in particular tests like:  `test/langtools/tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java`

@vicente-romero-oracle It is difficult to identify which test should be changed, because all the tests passed. As you said, the `TargetAnnoCombo.java` maybe need to be changed. I want to revise it now. Should I do it?

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

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

From erik.joelsson at oracle.com  Tue Dec  8 14:05:28 2020
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 8 Dec 2020 06:05:28 -0800
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
Message-ID: <c7811a03-ceba-1482-ae36-1c3bf5e0eed3@oracle.com>


On 2020-12-08 00:30, Magnus Ihse Bursie wrote:
> On Tue, 8 Dec 2020 02:40:43 GMT, Mandy Chung <mchung at openjdk.org> wrote:
>
>>> I have reviewed all lines in the patch file with or near instances of `jdk.compiler`
>> Hi Magnus,
>>
>> I see the motivation of moving these build files for better identification of ownership.   Placing them under
>> `src/$MODULE/{share,$OS}/data` is one option.  Given that skara will automatically determine appropriate mailing lists of a PR, it seems that `make/modules/$MODULE/data` can be another alternative that skara can include this pattern in the mailing list configuration??   I don't yet have a strong preference while I don't consider everything under `make` must be owned by the build team though.  Do you see one option is better than the other?
> @mlchung If you don't have any strong preference, I implore you to accept this change. I **vastly** prefer to move the data out of `make`!
>
> This is not just about Skara tooling. When working with make files, autoconf and shell scripts, there is no fancy IDE support, so you are stuck with simple text editors and tools like `grep`. I've lost count on how many times I've had my grep searches blow up, since I happened to find e.g. a string in `tzdata` and get hundreds or more of hits. :-( And I do believe we will get a better code structure if the build team "owns" `make`;  or at least has a vested interest in what's in that directory. We still suffer a lot of the old "I don't know where to put this file, so I'll just put it in make cause nobody cares about it anyway" mentality, but I've been working for quite some time to make that list of misplaced files shorter and shorter.
>
I strongly agree with Magnus for all the same reasons. To me, the data 
files are clearly a form of source code that should be considered owned 
by the component teams. I'm honestly perplexed over why this is being 
argued against.

/Erik

> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/1611

From jlahoda at openjdk.java.net  Tue Dec  8 14:10:26 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 8 Dec 2020 14:10:26 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended [v2]
In-Reply-To: <bKk-eDcJOGlU6rWMeUn8dTfAqqC4p0ktTNr3hTmC2Lw=.ba4acfe3-6686-47cc-ad94-867323257809@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
 <bKk-eDcJOGlU6rWMeUn8dTfAqqC4p0ktTNr3hTmC2Lw=.ba4acfe3-6686-47cc-ad94-867323257809@github.com>
Message-ID: <PSYdBiAA286RKLVgVUO60lcmy_HOpyUkssRYlw172Dk=.8b3fb7c5-f7f0-4c4e-84c6-93ac0e54efce@github.com>

On Tue, 8 Dec 2020 14:07:08 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this fix for JDK-8256867.  This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes).  Instead, the class is treated as a sealed class which cannot be extended nor implemented.  This new behavior conforms to the JVM Spec.
>> 
>> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes.
>> 
>> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8256867: Classes with empty PermittedSubclasses attribute cannot be extended

The langtools changes look good to me - thanks!

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

Marked as reviewed by jlahoda (Reviewer).

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

From hseigel at openjdk.java.net  Tue Dec  8 14:10:26 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 8 Dec 2020 14:10:26 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended [v2]
In-Reply-To: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
Message-ID: <bKk-eDcJOGlU6rWMeUn8dTfAqqC4p0ktTNr3hTmC2Lw=.ba4acfe3-6686-47cc-ad94-867323257809@github.com>

> Please review this fix for JDK-8256867.  This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes).  Instead, the class is treated as a sealed class which cannot be extended nor implemented.  This new behavior conforms to the JVM Spec.
> 
> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes.
> 
> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  8256867: Classes with empty PermittedSubclasses attribute cannot be extended

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1675/files
  - new: https://git.openjdk.java.net/jdk/pull/1675/files/89c61b95..de461457

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

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

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

From hseigel at openjdk.java.net  Tue Dec  8 14:26:14 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 8 Dec 2020 14:26:14 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended [v2]
In-Reply-To: <kU1QHA8TpwTjBYUtu78to9SntPU7rEB_k-mZUBD7lGc=.a9a5180c-c4b6-4a7c-8f8a-cc57dd87af86@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
 <JAGDtAri5tRHfu6OWiEbbapk0D1K50lsMXs1ZtOZ9Hg=.8a1b6614-a7fb-48a0-ba48-e69992a776f5@github.com>
 <kU1QHA8TpwTjBYUtu78to9SntPU7rEB_k-mZUBD7lGc=.a9a5180c-c4b6-4a7c-8f8a-cc57dd87af86@github.com>
Message-ID: <iZijnbnIXHiAm0RvB4PizRtXO-F-ovnaqKIrkeer8lY=.7f6c31f6-2578-4b9f-a035-9b10554a358e@github.com>

On Tue, 8 Dec 2020 00:09:34 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/hotspot/share/prims/jvm.cpp line 2130:
>> 
>>> 2128:     JvmtiVMObjectAllocEventCollector oam;
>>> 2129:     Array<u2>* subclasses = ik->permitted_subclasses();
>>> 2130:     int length = subclasses == NULL ? 0 : subclasses->length();
>> 
>> Minor comment - you don't really need the check of subclasses == NULL here since subclasses will never be NULL.  You could just assign length to subclasses->length();
>
> +1.   is_sealed returns true iff `_permitted_subclasses != NULL`

Thanks for the reviews.  I removed the check of subclasses == NULL in the updated commit.

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

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

From hseigel at openjdk.java.net  Tue Dec  8 14:31:13 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 8 Dec 2020 14:31:13 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended [v2]
In-Reply-To: <0gY9SoxDO9oyPxcbLEKGp2Nv9JI1QTtk8OvCAqKvdtM=.51219b79-aa76-4e2d-bf93-0178a6f2e9b1@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
 <pYsyZC0xuSg34F14eeWjF6tVXsMM4GrtHc6d1DSVeV4=.53041b96-8625-4c04-88c9-4e2b4c4ba1ef@github.com>
 <0gY9SoxDO9oyPxcbLEKGp2Nv9JI1QTtk8OvCAqKvdtM=.51219b79-aa76-4e2d-bf93-0178a6f2e9b1@github.com>
Message-ID: <Sqz5bfJ-9io_KLSyL_TYFYD-pX8p_vuify7pc_W806U=.53f6ff75-3f2c-485d-b2b4-8ce2a98c3b5a@github.com>

On Tue, 8 Dec 2020 09:30:59 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 4396:
>> 
>>> 4394:      * is unspecified. If this {@code Class} object represents a primitive type,
>>> 4395:      * {@code void}, an array type, or a class or interface that is not sealed,
>>> 4396:      * then null is returned.
>> 
>> nit: s/null/`{@code null}`
>> 
>> I'd suggest to clarify if this sealed class or interface has no permitted subclass, something like this:
>> Returns an array containing {@code Class} objects representing the
>> direct subinterfaces or subclasses permitted to extend or
>> implement this class or interface if it is sealed.  The order of such elements
>> is unspecified.   The array is empty if this sealed class or interface has no
>> permitted subclass. 
>> 
>> `@return` needs to be revised as well:
>> @return an array of {@code Class} objects of the permitted subclasses of this sealed class or interface,
>>      or {@null} if this class or interface is not sealed
>
> Mandy's suggested wording is good.
> 
> I would like to add one more additional point of clarification. It would
> be good to strongly connect `isSealed` and `getPermittedClasses` in a
> first-class way in normative spec ( similar to isRecord and
> getRecordComponents ).
> 
> For example, 
> 
>   to `isSealed` add: "getPermittedSubclasses returns a non-null but possibly
>        empty value for a sealed class."
> 
>   to `getPermittedSubclasses`: "If this class is not a sealed class, that is {@link
>      * #isSealed()} returns {@code false}, then this method returns {@code null}.
>      * Conversely, if {@link #isSealed()} returns {@code true}, then this method
>      * returns a non-null value."

Please review the updated commit.  It incorporates the changes to the comments in Class.java suggested by Mandy and Chris.
Thanks, Harold

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

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

From chegar at openjdk.java.net  Tue Dec  8 14:41:13 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 8 Dec 2020 14:41:13 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended [v2]
In-Reply-To: <bKk-eDcJOGlU6rWMeUn8dTfAqqC4p0ktTNr3hTmC2Lw=.ba4acfe3-6686-47cc-ad94-867323257809@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
 <bKk-eDcJOGlU6rWMeUn8dTfAqqC4p0ktTNr3hTmC2Lw=.ba4acfe3-6686-47cc-ad94-867323257809@github.com>
Message-ID: <HVFl-xBcnv-srCjtqTXRahw7mgY-0ZMTg5BGH-OFN70=.89ded08a-d67b-4353-905f-fa72315ed16f@github.com>

On Tue, 8 Dec 2020 14:10:26 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this fix for JDK-8256867.  This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes).  Instead, the class is treated as a sealed class which cannot be extended nor implemented.  This new behavior conforms to the JVM Spec.
>> 
>> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes.
>> 
>> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8256867: Classes with empty PermittedSubclasses attribute cannot be extended

Thanks Harold. LGTM.

src/java.base/share/classes/java/lang/Class.java line 4399:

> 4397:      * that is {@link #isSealed()} returns {@code false}, then this method returns {@code null}.
> 4398:      * Conversely, if {@link #isSealed()} returns {@code true}, then this method
> 4399:      * returns a non-null value."

Trivially, the trailing quote can be removed.

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

Marked as reviewed by chegar (Reviewer).

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

From hseigel at openjdk.java.net  Tue Dec  8 14:53:13 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 8 Dec 2020 14:53:13 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended [v2]
In-Reply-To: <HVFl-xBcnv-srCjtqTXRahw7mgY-0ZMTg5BGH-OFN70=.89ded08a-d67b-4353-905f-fa72315ed16f@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
 <bKk-eDcJOGlU6rWMeUn8dTfAqqC4p0ktTNr3hTmC2Lw=.ba4acfe3-6686-47cc-ad94-867323257809@github.com>
 <HVFl-xBcnv-srCjtqTXRahw7mgY-0ZMTg5BGH-OFN70=.89ded08a-d67b-4353-905f-fa72315ed16f@github.com>
Message-ID: <XOysYVGp0n65n_k4StWZloaawZmYksuxW51q5oXcmmM=.6ef08e6d-ac26-40b6-be47-917146f70022@github.com>

On Tue, 8 Dec 2020 14:37:52 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8256867: Classes with empty PermittedSubclasses attribute cannot be extended
>
> src/java.base/share/classes/java/lang/Class.java line 4399:
> 
>> 4397:      * that is {@link #isSealed()} returns {@code false}, then this method returns {@code null}.
>> 4398:      * Conversely, if {@link #isSealed()} returns {@code true}, then this method
>> 4399:      * returns a non-null value."
> 
> Trivially, the trailing quote can be removed.

Thanks Chris!  I'll remove the trailing quote.

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

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

From hseigel at openjdk.java.net  Tue Dec  8 14:57:26 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 8 Dec 2020 14:57:26 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended [v3]
In-Reply-To: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
Message-ID: <8d5us_1aPK9ZKVkA3712a0aFzkkGiC-3Ho10FZbk5sA=.fe57780d-a678-4b8e-ac3e-301ac8246c37@github.com>

> Please review this fix for JDK-8256867.  This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes).  Instead, the class is treated as a sealed class which cannot be extended nor implemented.  This new behavior conforms to the JVM Spec.
> 
> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes.
> 
> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64.
> 
> Thanks, Harold

Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:

  8256867: Classes with empty PermittedSubclasses attribute cannot be extended

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1675/files
  - new: https://git.openjdk.java.net/jdk/pull/1675/files/de461457..2ce2a993

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

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

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

From chegar at openjdk.java.net  Tue Dec  8 15:02:13 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 8 Dec 2020 15:02:13 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended [v3]
In-Reply-To: <8d5us_1aPK9ZKVkA3712a0aFzkkGiC-3Ho10FZbk5sA=.fe57780d-a678-4b8e-ac3e-301ac8246c37@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
 <8d5us_1aPK9ZKVkA3712a0aFzkkGiC-3Ho10FZbk5sA=.fe57780d-a678-4b8e-ac3e-301ac8246c37@github.com>
Message-ID: <t2Q454yt-mrMEZTytj9n_Bncxk6cUuPYx0g3SE-7oPk=.01092d1e-82f8-4da2-8e6f-04867b613b10@github.com>

On Tue, 8 Dec 2020 14:57:26 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this fix for JDK-8256867.  This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes).  Instead, the class is treated as a sealed class which cannot be extended nor implemented.  This new behavior conforms to the JVM Spec.
>> 
>> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes.
>> 
>> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8256867: Classes with empty PermittedSubclasses attribute cannot be extended

Marked as reviewed by chegar (Reviewer).

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

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

From herrick at openjdk.java.net  Tue Dec  8 15:11:50 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 8 Dec 2020 15:11:50 GMT
Subject: RFR: JDK-8257539: tools/jpackage/windows/WinL10nTest.java
 unpack.bat failed with Exit code: 1618 [v2]
In-Reply-To: <RB0t2t8DmPX1d5Xvhb6JqnSkROKwB31WL77I-8Pi3cU=.f6d55f17-bc58-4faa-a1ac-92bb6320a118@github.com>
References: <RB0t2t8DmPX1d5Xvhb6JqnSkROKwB31WL77I-8Pi3cU=.f6d55f17-bc58-4faa-a1ac-92bb6320a118@github.com>
Message-ID: <UhKMC14CZoXTrgGQrC8iJJFVSzaTYCXD3whnca5s7Dw=.fd4c1d0f-822c-43c4-a27b-7cfa610d571d@github.com>

> increase retries and timeout increasing in runMsiexecWithRetries

Andy Herrick has updated the pull request incrementally with 18 additional commits since the last revision:

 - 8256149: Weird AST structure for incomplete member select
   
   Reviewed-by: vromero
 - 8257194: Add 'foreign linker API' in 'jdk.incubator.foreign' module desc/summary
   
   Reviewed-by: jvernee, shade
 - 8257848: -XX:CompileCommand=blackhole,* should be diagnostic
   
   Reviewed-by: vlivanov
 - 8242258: (jrtfs) Path::toUri throws AssertionError for malformed input
   
   Reviewed-by: alanb
 - 8254733: HotSpot Style Guide should permit using range-based for loops
   
   Reviewed-by: dholmes, pliden, jrose, dcubed, iklam, eosterlund, tschatzl, kvn
 - 8253644: C2: assert(skeleton_predicate_has_opaque(iff)) failed: unexpected
   
   Reviewed-by: roland, kvn
 - 8256411: Based anonymous classes have a weird end position
   
   Reviewed-by: vromero
 - 8257813: [redo] C2: Filter type in PhiNode::Value() for induction variables of trip-counted integer loops
   
   Reviewed-by: chagedorn, kvn
 - 8257769: Cipher.getParameters() throws NPE for ChaCha20-Poly1305
   
   Reviewed-by: mullan, valeriep
 - 8257855: Example SafeVarargsNotApplicableToRecordAccessors breaks test tools/javac/diags/CheckExamples.java
   
   Reviewed-by: jjg
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/7c4743c5...5d065497

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1676/files
  - new: https://git.openjdk.java.net/jdk/pull/1676/files/7c4743c5..5d065497

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

  Stats: 1938 lines in 49 files changed: 1465 ins; 276 del; 197 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1676.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1676/head:pull/1676

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

From weijun at openjdk.java.net  Tue Dec  8 15:28:11 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 8 Dec 2020 15:28:11 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
Message-ID: <ciA4jbPTJ1liYuwfkxHqghSqy6M3_4gZAIpzJGhzzlA=.0e282d88-4f1d-4999-9a27-c7081825cb05@github.com>

On Tue, 8 Dec 2020 12:15:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Also, to clarify, for me there is a fundamental difference between `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files that are part of the module, owned by the content team, and the `$MODULE` part is essential to delineate this content. The latter is owned by the build team, and is just a convenient way to organize the build system within the `make` directory. So it's clearly a no-no to put anything but `.gmk` files in `make/modules/$MODULE`.
>
> The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.

Is there a plan to move make/jdk/src/classes/build/tools/intpoly into java.base as well?

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

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

From ihse at openjdk.java.net  Tue Dec  8 16:20:21 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 8 Dec 2020 16:20:21 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
Message-ID: <XJDGP3MtiEMsfcKaybq1ZpasjInl_6TwEOxVCVKnPgU=.9c47e0ac-6c43-42f9-b2d6-22675351814a@github.com>

On Tue, 8 Dec 2020 12:15:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Also, to clarify, for me there is a fundamental difference between `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files that are part of the module, owned by the content team, and the `$MODULE` part is essential to delineate this content. The latter is owned by the build team, and is just a convenient way to organize the build system within the `make` directory. So it's clearly a no-no to put anything but `.gmk` files in `make/modules/$MODULE`.
>
> The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.

@AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place.

I chose to put the data files used for both java.base and the "additional" modules in java.base, based on the comment that Naoto made in https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027044.html:

> As to charsetmapping and cldrconverter, I believe they can reside in 
java.base, as jdk.charsets and jdk.localedata modules depend on it.

Of course it would be preferable to make a proper split, but that requires work done by the component teams to break the modules apart.

Specifically for  make/modules/jdk.charsets/Gensrc.gmk; the code in that file is more or less duplicated in make/modules/java.base/gensrc/GensrcCharsetMapping.gmk, since the same data set is processed twice, once for java.base and once for jdk.charsets. I don't think that means that make/modules/jdk.charsets/Gensrc.gmk should move to any other place.

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

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

From herrick at openjdk.java.net  Tue Dec  8 16:25:03 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 8 Dec 2020 16:25:03 GMT
Subject: RFR: JDK-8257539: tools/jpackage/windows/WinL10nTest.java
 unpack.bat failed with Exit code: 1618
In-Reply-To: <9y9motn8OVRRsHTGtvfWMt-4aTC9_E--vqhOir0eu9A=.c58b8b5a-e4a4-4172-8c08-b8ba05b0f9b0@github.com>
References: <RB0t2t8DmPX1d5Xvhb6JqnSkROKwB31WL77I-8Pi3cU=.f6d55f17-bc58-4faa-a1ac-92bb6320a118@github.com>
 <s8py0M4XMsD6CRz15ZUuN2ipQFB9T5lGttkbIwqh_Us=.2b5ec883-00fe-49ca-b36c-cbe419f9a5cf@github.com>
 <9y9motn8OVRRsHTGtvfWMt-4aTC9_E--vqhOir0eu9A=.c58b8b5a-e4a4-4172-8c08-b8ba05b0f9b0@github.com>
Message-ID: <KXhwC_QsPvLZbWxx0VOSHwM2T11LVIahL_eGfyzUTw8=.239cab51-45a1-468d-bc51-58aae763e853@github.com>

On Tue, 8 Dec 2020 14:56:20 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> Looks like test failed due to:
>> [Fatal Error] b.wxl:3:1: XML document structures must start and end within the same entity.
>> So, I am not sure how increased repeat will help. Do we know why it failed to parse XML?
>
>> 
>> 
>> Looks like test failed due to:
>> [Fatal Error] b.wxl:3:1: XML document structures must start and end within the same entity.
>> So, I am not sure how increased repeat will help. Do we know why it failed to parse XML?
> 
> If you scroll down from that error - you can see that that is the expected error and the return code from jpackage is asserted to be 1, and it is asserted that the resulting WinL10NTest.msi does not exist.
> 
> the @Parameters for "data" cause instance of this test to be run 8 times with different args.  This instances is expected to fail since allWxlFilesValid is false.
> later in the log (https://mach5.us.oracle.com:10060/api/v1/results/mach5-one-jdk-16+26-1740-tier2-20201124-1335-16116386-open_test_jdk_tier2_part2-windows-x64-125-1606226621-1556/log) you can see the timeout, where unpack.bat is run three times with 3 second delay and returns 1618 each time:
> **13:58:30.303] TRACE: exec: Execute [cmd /c .\\test.3563aceb\\unpacked-msi\\unpack.bat](3); discard I/O...
> [13:58:33.469] TRACE: exec: Done. Exit code: 1618
> [13:58:36.492] TRACE: exec: Execute [cmd /c .\\test.3563aceb\\unpacked-msi\\unpack.bat](3); discard I/O...
> [13:58:39.636] TRACE: exec: Done. Exit code: 1618
> [13:58:42.652] TRACE: exec: Execute [cmd /c .\\test.3563aceb\\unpacked-msi\\unpack.bat](3); discard I/O...
> [13:58:45.803] TRACE: exec: Done. Exit code: 1618
> [13:58:48.832] ERROR: Expected [0]. Actual [1618]: Check command [cmd /c .\\test.3563aceb\\unpacked-msi\\unpack.bat](3) exited with 0 code
> [13:58:48.832] [  FAILED  ] WinL10nTest([name=a.wxl; culture=fr, name=b.wxl; culture=fr](length=2), fr;en-us, null).test; checks=17
> [13:58:48.832] [ RUN      ] WinL10nTest([name=a.wxl; culture=fr, name=b.wxl; culture=it, name=c.wxl; culture=fr, name=d.wxl; culture=it](length=4), fr;it;en-us,**
> 
> running unpack.bat with msiexec command in it succeed for one test instance after the expected failure, then got 1618 return on the second test instance after the expected failure with the above timeout.

I converted to draft because somehow merging with master caused a mess - since is simple change in one test file I may create a new branch and new pull request cleanly again.

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

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

From ihse at openjdk.java.net  Tue Dec  8 16:25:06 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 8 Dec 2020 16:25:06 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <ciA4jbPTJ1liYuwfkxHqghSqy6M3_4gZAIpzJGhzzlA=.0e282d88-4f1d-4999-9a27-c7081825cb05@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
 <ciA4jbPTJ1liYuwfkxHqghSqy6M3_4gZAIpzJGhzzlA=.0e282d88-4f1d-4999-9a27-c7081825cb05@github.com>
Message-ID: <38lUUfvwvq4J4K8Ri6DEs6QAv-iMDkUDo0se8Hk75ig=.38d3a5a7-968d-4ab8-a533-b26ce8982fe5@github.com>

On Tue, 8 Dec 2020 15:25:47 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.
>
> Is there a plan to move make/jdk/src/classes/build/tools/intpoly into java.base as well?
> 
> Update: I see all subdirs in tools are still there.

@wangweij Moving build tools is a related, but separate, question, which is addressed by https://bugs.openjdk.java.net/browse/JDK-8241463.

I send out a review earlier this year (see https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027038.html), but there were differing opinions on what the proper placement of these tools should be, and the discussion kind of fizzled out without reaching a conclusion.

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

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

From darcy at openjdk.java.net  Tue Dec  8 17:10:30 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 8 Dec 2020 17:10:30 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v5]
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <Dz2qX4jgdJNFNA7gCwtoIYSsdNpkp4T77NAdnYbb-y4=.1e89eca5-a6e3-4397-afe3-94ca88265147@github.com>

> Start of JDK 17 updates.

Joe Darcy 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 12 additional commits since the last revision:

 - Merge branch 'master' into JDK-8257450
 - Update symbol files for JDK 16b27.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Update tests.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - JDK-8257450
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/e5462611...ff9b78ec

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1531/files
  - new: https://git.openjdk.java.net/jdk/pull/1531/files/342c8650..ff9b78ec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=03-04

  Stats: 1427 lines in 38 files changed: 1106 ins; 191 del; 130 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1531.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531

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

From jjg at openjdk.java.net  Tue Dec  8 17:22:02 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 8 Dec 2020 17:22:02 GMT
Subject: RFR: 6882207: Convert javap to use diamond operator internally
In-Reply-To: <B_3aVOV1mWiHfgxninu81FWTmgN9dXzckXZb9rTcDzQ=.b7aa8fd0-e92b-408b-a077-4c1a0f6f504e@github.com>
References: <B_3aVOV1mWiHfgxninu81FWTmgN9dXzckXZb9rTcDzQ=.b7aa8fd0-e92b-408b-a077-4c1a0f6f504e@github.com>
Message-ID: <xFO--p2lPwhNfzXl4k6qfR25-RC-W0e5Nv_dxEy3de0=.00cd2af6-e7bc-4770-8113-2e6537bb54df@github.com>

On Mon, 7 Dec 2020 20:30:07 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 6882207: Convert javap to use diamond operator internally

Nice; thanks

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

Marked as reviewed by jjg (Reviewer).

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

From mchung at openjdk.java.net  Tue Dec  8 17:23:19 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 8 Dec 2020 17:23:19 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended [v3]
In-Reply-To: <8d5us_1aPK9ZKVkA3712a0aFzkkGiC-3Ho10FZbk5sA=.fe57780d-a678-4b8e-ac3e-301ac8246c37@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
 <8d5us_1aPK9ZKVkA3712a0aFzkkGiC-3Ho10FZbk5sA=.fe57780d-a678-4b8e-ac3e-301ac8246c37@github.com>
Message-ID: <l65ZeH76u0Fpg8qPWzNmfM13dnvwcSVFRupztcBhNMk=.c2094d98-2c47-4ab6-a5c1-4f7c15d2b247@github.com>

On Tue, 8 Dec 2020 14:57:26 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this fix for JDK-8256867.  This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes).  Instead, the class is treated as a sealed class which cannot be extended nor implemented.  This new behavior conforms to the JVM Spec.
>> 
>> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes.
>> 
>> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8256867: Classes with empty PermittedSubclasses attribute cannot be extended

src/java.base/share/classes/java/lang/Class.java line 4399:

> 4397:      * that is {@link #isSealed()} returns {@code false}, then this method returns {@code null}.
> 4398:      * Conversely, if {@link #isSealed()} returns {@code true}, then this method
> 4399:      * returns a non-null value.

@ChrisHegarty minor but I prefer a simpler alternative to address your concern is to add a link to the reference to "sealed class or interface" to `Class::isSealed` as follows:
implement this class or interface if it is {@linkplain #isSealed() sealed}.
The order of such elements is unspecified. If this {@code Class} object
represents a primitive type,  is unspecified. The array is empty if this
{@linkplain #isSealed() sealed} class or interface has no permitted subclass. 
If this {@code Class} object represents a primitive type, {@code void}, an array type,
or a class or interface that is not sealed, then this method returns {@code null}.

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

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

From alanb at openjdk.java.net  Tue Dec  8 17:36:08 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 8 Dec 2020 17:36:08 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
Message-ID: <Fd81NFkU3bt5ZOedlgG7f2BcvIC2xWuLGD0Eg0TuMsw=.83681790-d8ac-4ec0-a0a3-00d582ac2f15@github.com>

On Tue, 8 Dec 2020 12:15:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Also, to clarify, for me there is a fundamental difference between `src/$MODULE` and `make/modules/$MODULE`. The former is the home of files that are part of the module, owned by the content team, and the `$MODULE` part is essential to delineate this content. The latter is owned by the build team, and is just a convenient way to organize the build system within the `make` directory. So it's clearly a no-no to put anything but `.gmk` files in `make/modules/$MODULE`.
>
> The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.

> @AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place.

This is a complicated area of the build, not really a Project Jigsaw issue. It's complicated because the source code for the charsets is generated at build time and the set of non-standard charsets included in java.base varies by platform, e.g. there's are several IBMxxx charsets in java.base when building on AIX that are not interesting to include in java.base on other platforms. This means we can't split up the mapping tables in make/data/charsetmapping and put them in different directories. If you are moving them into the src tree then src/java.base (as you have it) is best but will still have the ugly wart that some of these mapping tables will be used to generate code for the jdk.charsets module.

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

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

From jjg at openjdk.java.net  Tue Dec  8 17:36:16 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 8 Dec 2020 17:36:16 GMT
Subject: RFR: 8231622: SuppressWarning("serial") ignored on field
 serialVersionUID [v3]
In-Reply-To: <dLH3TZ0frTK_o5WhhPqxBbc7HfIqE81WK4JJuAZFURI=.52b74fab-d793-4f6b-b9cd-7a4de6d23f0b@github.com>
References: <_2Z8RhLQo1F6ddk2cZS5J_hoRMPLCe5ssVMeyyscFnc=.d267dddd-12d6-4968-a32d-6bd3510daf45@github.com>
 <dLH3TZ0frTK_o5WhhPqxBbc7HfIqE81WK4JJuAZFURI=.52b74fab-d793-4f6b-b9cd-7a4de6d23f0b@github.com>
Message-ID: <fGpVUylnqbNBsDy0lblp7pIv5_WvKyoCCdLSPKgOl3Y=.984a0612-5e9f-420c-bf17-6b598b321532@github.com>

On Tue, 8 Dec 2020 13:02:33 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi all,
>> 
>> Currently, a warning is generated when compiling the following code by using the option `-Xlint`.
>> 
>> import java.io.Serializable;
>> class B implements Serializable {
>>     @SuppressWarnings("serial")
>>     private static final byte serialVersionUID = 5;
>> }
>> 
>> output:
>> B.java:4: warning: [serial] serialVersionUID must be of type long in class B
>>     private static final byte serialVersionUID = 5;
>>                               ^
>> 1 warning
>> 
>> The annotation `@SuppressWarnings("serial")` on  field serialVersionUID is ignored by the compiler.
>> This patch fixes it and adds some tests.
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Guoxiong Li 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 four additional commits since the last revision:
> 
>  - Revise tests by using library toolbox.
>  - Merge remote-tracking branch 'origin' into JDK-8231622
>  - Revise test cases. Remove legal header and add /nodynamiccopyright/
>  - 8231622: SuppressWarning(serial) ignored on field serialVersionUID

Nice improvement. You can make it even better in 3 places by using `ToolBox.checkEquals`, which provides more detailed reporting in the case of a difference being found.

test/langtools/tools/javac/T8231622/T8231622.java line 79:

> 77:         if (!Objects.equals(output, expected)) {
> 78:             throw new AssertionError("incorrect output\nactual=" + output + "\nexpected=" + expected);
> 79:         }

ToolBox provides `checkEquals` which provides a more detailed error message in the case of a difference.

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

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

From chegar at openjdk.java.net  Tue Dec  8 17:41:09 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 8 Dec 2020 17:41:09 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended [v3]
In-Reply-To: <l65ZeH76u0Fpg8qPWzNmfM13dnvwcSVFRupztcBhNMk=.c2094d98-2c47-4ab6-a5c1-4f7c15d2b247@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
 <8d5us_1aPK9ZKVkA3712a0aFzkkGiC-3Ho10FZbk5sA=.fe57780d-a678-4b8e-ac3e-301ac8246c37@github.com>
 <l65ZeH76u0Fpg8qPWzNmfM13dnvwcSVFRupztcBhNMk=.c2094d98-2c47-4ab6-a5c1-4f7c15d2b247@github.com>
Message-ID: <1eiv5vks958dAH0lTcXvEbWancK8w6jLTUITk1s4W8k=.ce9c67a2-6b30-4ff9-a095-4ab03eea3bc5@github.com>

On Tue, 8 Dec 2020 17:18:20 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8256867: Classes with empty PermittedSubclasses attribute cannot be extended
>
> src/java.base/share/classes/java/lang/Class.java line 4399:
> 
>> 4397:      * that is {@link #isSealed()} returns {@code false}, then this method returns {@code null}.
>> 4398:      * Conversely, if {@link #isSealed()} returns {@code true}, then this method
>> 4399:      * returns a non-null value.
> 
> @ChrisHegarty minor but I prefer a simpler alternative to address your concern is to add a link to the reference to "sealed class or interface" to `Class::isSealed` as follows:
> implement this class or interface if it is {@linkplain #isSealed() sealed}.
> The order of such elements is unspecified. If this {@code Class} object
> represents a primitive type,  is unspecified. The array is empty if this
> {@linkplain #isSealed() sealed} class or interface has no permitted subclass. 
> If this {@code Class} object represents a primitive type, {@code void}, an array type,
> or a class or interface that is not sealed, then this method returns {@code null}.

There is certainly a little redundancy in the additional spec wording
that I proposed. In my view it is worth it, as it allows the reader to
more easily grok the null versus empty array for non-sealed classes,
without having to navigate between the pair of methods.

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

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

From prappo at openjdk.java.net  Tue Dec  8 17:59:24 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 8 Dec 2020 17:59:24 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations. [v6]
In-Reply-To: <r6x0B8EUk4UVr8bP6gCQ4FS63wxnQLg6uhDHyjQ5cvA=.b27e6dc8-35c1-4360-b62d-e0aa196e6f4a@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
 <r6x0B8EUk4UVr8bP6gCQ4FS63wxnQLg6uhDHyjQ5cvA=.b27e6dc8-35c1-4360-b62d-e0aa196e6f4a@github.com>
Message-ID: <6F0Kz14Rd1Wdz6odAtI3AcTeG-gD04RQuYFVO2gG8VA=.dd398953-4084-4fe0-99d4-e0f927b8c93b@github.com>

On Mon, 7 Dec 2020 18:37:37 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description.
>> 
>> The goal is to be able to simplify the following common pattern:
>> 
>>     /**
>>      * Returns the result. Optional additional text.
>>      * @return the result
>>      */
>>     int method() { 
>> 
>> by 
>> 
>>     /**
>>      * {@return the result} Optional additional text.
>>      */
>>     int method() { 
>> 
>> Note:
>> 
>> * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere.
>> * The expansion of the inline tag is `Returns " _content_ `.`  where _content_ is the content of the tag. 
>> * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description
>> * The inline tag can be inherited into overriding methods as if it was provided as a block tag.
>
> Jonathan Gibbons 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 12 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into new-return
>  - Update JShell to handle inline `{@return}`
>  - Merge remote-tracking branch 'upstream/master' into new-return
>  - fix test
>  - Update for new `@return` tag
>  - Merge remote-tracking branch 'upstream/master' into new-return
>  - Update DocCommentParser to permit nested inline tags in specified cases: @return
>  - Add default impl for new method
>  - Fix test failure
>  - Fix trailing whitespace in test
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/8343a9ff...a25dadca

1. Although the change generally looks good, there are some issues that should be fixed.
2. I have NOT reviewed the `jdk.internal.shellsupport.doc` portion of the change in detail; please ask someone else to do that.
3. When I run this change through our CI, the `tools/javac/diags/CheckExamples.java` test fails consistently on all platforms. Try to merge with the latest `master` to rule out this PR as a cause.
4. Consider updating the copyright years when addressing this feedback.

src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java line 277:

> 275:      * @param description the description of the return value of a method
> 276:      * @return a {@code ReturnTree} object
> 277:      * @throws UnsupportedOperationException if inline {@code {@return} } tags are

To be consistent with the rest of the file, I suggest using `{@code {@return }}` instead of `{@code {@return} }` (note the position of the whitespace).

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 275:

> 273:                         return tp.parse(p, TagParser.Kind.BLOCK);
> 274:                     } else {
> 275:                             return erroneous("dc.bad.inline.tag", p);

This indentation fits the current `switch` but not the proposed `if` statement.

src/jdk.compiler/share/classes/com/sun/source/doctree/ReturnTree.java line 44:

> 42:      * Returns whether this instance is an inline tag.
> 43:      *
> 44:      * @return {@code true} if this instance is an inline tag

Although I'm not sure how `boolean` queries are generally specified in the `DocTree` API, consider explicitly specifying that this method returns `false` if called on a non-inline instance.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 333:

> 331:                     DCTree text = inlineText(WhitespaceRetentionPolicy.REMOVE_ALL); // skip content
> 332:                     nextChar();
> 333:                     return m.at(p).newUnknownInlineTagTree(name, List.of(text)).setEndPos(bp);

There's a discrepancy between the inline comment and code. While the comment says that the `else` clause handles a block tag, the returned tree corresponds to an (unknown) inline tag.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1132:

> 1130: 
> 1131:     /**
> 1132:      * @see <a href="https://docs.oracle.com/en/java/javase/14/docs/specs/javadoc/doc-comment-spec.html">JavaDoc Tags</a>

Consider updating the version to 15. Later, we'd hopefully be able to use the [`@spec` tag](https://bugs.openjdk.java.net/browse/JDK-8226279) here.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1126:

> 1124:             return parse(pos);
> 1125:         }
> 1126:         DCTree parse(int pos) throws ParseException {

Please add an empty line between those two to separate the methods.

src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 690:

> 688: 
> 689:         @Override
> 690:         public String getTagName() {

Isn't this method missing `@DefinedBy(Api.COMPILER_TREE)`?

src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/JavadocFormatter.java line 268:

> 266:         /**
> 267:          * {@inheritDoc}
> 268:          * {@code @return} is a bimodfal tage and can be used as either a block tag or an inline

Fix the typos in "bimodfal tage".

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties line 60:

> 58: dc.param.name.not.found = @param name not found
> 59: dc.ref.not.found = reference not found
> 60: dc.return.not.first = '{@return'} not at beginning of description

I can see an inconsistency here. While the templates for `@return` and `@code` put an apostrophe immediately before the closing `}`, the template for `@value` (further below in this file) puts an apostrophe immediately after the closing `}`.

test/langtools/jdk/internal/shellsupport/doc/JavadocFormatterTest.java line 140:

> 138:                    "1234 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234\n" +
> 139:                    "1234 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234\n" +
> 140:                    "1234 1234 1234 1234 1234 1234 1234 1234 1234 \n";

What's that about? I mean is it related to this work on `{@return}`?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/ReturnTaglet.java line 76:

> 74:         } else {
> 75:             List<? extends DocTree> firstSentence = utils.getFirstSentenceTrees(input.element);
> 76:             if (firstSentence.size() == 1 && firstSentence.get(0).getKind() == DocTree.Kind.RETURN) {

There's one more place where `firstSentence.size() == 1` is checked. I wonder if it could be a simpler `!firstSentence.isEmpty()` check?

Are there any non-trivial cases which might bite us later, should we change that check?

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

Changes requested by prappo (Reviewer).

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

From mchung at openjdk.java.net  Tue Dec  8 18:06:15 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 8 Dec 2020 18:06:15 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended [v3]
In-Reply-To: <1eiv5vks958dAH0lTcXvEbWancK8w6jLTUITk1s4W8k=.ce9c67a2-6b30-4ff9-a095-4ab03eea3bc5@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
 <8d5us_1aPK9ZKVkA3712a0aFzkkGiC-3Ho10FZbk5sA=.fe57780d-a678-4b8e-ac3e-301ac8246c37@github.com>
 <l65ZeH76u0Fpg8qPWzNmfM13dnvwcSVFRupztcBhNMk=.c2094d98-2c47-4ab6-a5c1-4f7c15d2b247@github.com>
 <1eiv5vks958dAH0lTcXvEbWancK8w6jLTUITk1s4W8k=.ce9c67a2-6b30-4ff9-a095-4ab03eea3bc5@github.com>
Message-ID: <cFIEb4-66e37ByCgJd0o5lruvqR7WFlQQT_cZdgTy4A=.3271490f-f5aa-426f-909d-904cf2bda6d8@github.com>

On Tue, 8 Dec 2020 17:38:12 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Class.java line 4399:
>> 
>>> 4397:      * that is {@link #isSealed()} returns {@code false}, then this method returns {@code null}.
>>> 4398:      * Conversely, if {@link #isSealed()} returns {@code true}, then this method
>>> 4399:      * returns a non-null value.
>> 
>> @ChrisHegarty minor but I prefer a simpler alternative to address your concern is to add a link to the reference to "sealed class or interface" to `Class::isSealed` as follows:
>> implement this class or interface if it is {@linkplain #isSealed() sealed}.
>> The order of such elements is unspecified. If this {@code Class} object
>> represents a primitive type,  is unspecified. The array is empty if this
>> {@linkplain #isSealed() sealed} class or interface has no permitted subclass. 
>> If this {@code Class} object represents a primitive type, {@code void}, an array type,
>> or a class or interface that is not sealed, then this method returns {@code null}.
>
> There is certainly a little redundancy in the additional spec wording
> that I proposed. In my view it is worth it, as it allows the reader to
> more easily grok the null versus empty array for non-sealed classes,
> without having to navigate between the pair of methods.

I see this new pattern introduced in `getRecordComponents`.  You may consider if this pattern should consistently applied in other `Class` APIs such as `getEnumConstants`.

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

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

From mchung at openjdk.java.net  Tue Dec  8 18:20:07 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 8 Dec 2020 18:20:07 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <38lUUfvwvq4J4K8Ri6DEs6QAv-iMDkUDo0se8Hk75ig=.38d3a5a7-968d-4ab8-a533-b26ce8982fe5@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
 <ciA4jbPTJ1liYuwfkxHqghSqy6M3_4gZAIpzJGhzzlA=.0e282d88-4f1d-4999-9a27-c7081825cb05@github.com>
 <38lUUfvwvq4J4K8Ri6DEs6QAv-iMDkUDo0se8Hk75ig=.38d3a5a7-968d-4ab8-a533-b26ce8982fe5@github.com>
Message-ID: <bMQXFWp99P-Nji3N6Po4crLH2ITQxLln-YIiNabc2js=.b170ff22-2955-4355-9d12-06375891eaed@github.com>

On Tue, 8 Dec 2020 16:19:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Is there a plan to move make/jdk/src/classes/build/tools/intpoly into java.base as well?
>> 
>> Update: I see all subdirs in tools are still there.
>
> @wangweij Moving build tools is a related, but separate, question, which is addressed by https://bugs.openjdk.java.net/browse/JDK-8241463.
> 
> I send out a review earlier this year (see https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027038.html), but there were differing opinions on what the proper placement of these tools should be, and the discussion kind of fizzled out without reaching a conclusion.

@magicus @erikj79 it's now clearly stated that you want everything under `make` owned by the build team, which is fair.  You are right that `make` has been easily considered as a dumping ground and it's time to define a clean structure.

I reviewed this patch and this looks okay to me.   Some follow-up questions and follow-on cleanup for example "should jdwp.spec belong to `specs` directory vs `data`?  There are platform-specific data (such as charsets) which has been special-case in the makefile and they need follow-on clean up.   I agree that this should be cleaned up by the component teams and not part of this PR.

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

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

From mchung at openjdk.java.net  Tue Dec  8 18:24:08 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 8 Dec 2020 18:24:08 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <bMQXFWp99P-Nji3N6Po4crLH2ITQxLln-YIiNabc2js=.b170ff22-2955-4355-9d12-06375891eaed@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
 <ciA4jbPTJ1liYuwfkxHqghSqy6M3_4gZAIpzJGhzzlA=.0e282d88-4f1d-4999-9a27-c7081825cb05@github.com>
 <38lUUfvwvq4J4K8Ri6DEs6QAv-iMDkUDo0se8Hk75ig=.38d3a5a7-968d-4ab8-a533-b26ce8982fe5@github.com>
 <bMQXFWp99P-Nji3N6Po4crLH2ITQxLln-YIiNabc2js=.b170ff22-2955-4355-9d12-06375891eaed@github.com>
Message-ID: <XbBJA_8zarG-F3qYYl0yXuS4ftw17t0gQbvE-o8mBOc=.2d1bb989-40d6-48c8-bc79-7f36580e000c@github.com>

On Tue, 8 Dec 2020 18:16:15 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> @wangweij Moving build tools is a related, but separate, question, which is addressed by https://bugs.openjdk.java.net/browse/JDK-8241463.
>> 
>> I send out a review earlier this year (see https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027038.html), but there were differing opinions on what the proper placement of these tools should be, and the discussion kind of fizzled out without reaching a conclusion.
>
> @magicus @erikj79 it's now clearly stated that you want everything under `make` owned by the build team, which is fair.  You are right that `make` has been easily considered as a dumping ground and it's time to define a clean structure.
> 
> I reviewed this patch and this looks okay to me.   Some follow-up questions and follow-on cleanup for example "should jdwp.spec belong to `specs` directory vs `data`?  There are platform-specific data (such as charsets) which has been special-case in the makefile and they need follow-on clean up.   I agree that this should be cleaned up by the component teams and not part of this PR.

With these new files showing up in under `src` directory, should `bin/idea.sh` be changed to exclude `data` to avoid incurring costs in loading JDK project from IDE that many of us use for development?

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

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

From mchung at openjdk.java.net  Tue Dec  8 18:27:09 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 8 Dec 2020 18:27:09 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended [v3]
In-Reply-To: <8d5us_1aPK9ZKVkA3712a0aFzkkGiC-3Ho10FZbk5sA=.fe57780d-a678-4b8e-ac3e-301ac8246c37@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
 <8d5us_1aPK9ZKVkA3712a0aFzkkGiC-3Ho10FZbk5sA=.fe57780d-a678-4b8e-ac3e-301ac8246c37@github.com>
Message-ID: <k28vKOBQbmPLsY0bQ5izKCC-sWcE_uulmkOV7WpGmto=.1d991bc6-9713-443e-98a2-8193fc81afa7@github.com>

On Tue, 8 Dec 2020 14:57:26 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Please review this fix for JDK-8256867.  This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes).  Instead, the class is treated as a sealed class which cannot be extended nor implemented.  This new behavior conforms to the JVM Spec.
>> 
>> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes.
>> 
>> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64.
>> 
>> Thanks, Harold
>
> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8256867: Classes with empty PermittedSubclasses attribute cannot be extended

Marked as reviewed by mchung (Reviewer).

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

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

From mchung at openjdk.java.net  Tue Dec  8 18:33:16 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 8 Dec 2020 18:33:16 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v5]
In-Reply-To: <Dz2qX4jgdJNFNA7gCwtoIYSsdNpkp4T77NAdnYbb-y4=.1e89eca5-a6e3-4397-afe3-94ca88265147@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <Dz2qX4jgdJNFNA7gCwtoIYSsdNpkp4T77NAdnYbb-y4=.1e89eca5-a6e3-4397-afe3-94ca88265147@github.com>
Message-ID: <-0FTWuV91_n7GwB4Om2qXb6LsQh7YxKq2ZCq4qSITGQ=.8955f873-e2ca-4eb1-a1d8-f295cdcab9c9@github.com>

On Tue, 8 Dec 2020 17:10:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Start of JDK 17 updates.
>
> Joe Darcy 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 12 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8257450
>  - Update symbol files for JDK 16b27.
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'master' into JDK-8257450
>  - Update tests.
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - JDK-8257450
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/c3d62067...ff9b78ec

Marked as reviewed by mchung (Reviewer).

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

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

From hseigel at openjdk.java.net  Tue Dec  8 18:35:13 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 8 Dec 2020 18:35:13 GMT
Subject: RFR: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended [v3]
In-Reply-To: <k28vKOBQbmPLsY0bQ5izKCC-sWcE_uulmkOV7WpGmto=.1d991bc6-9713-443e-98a2-8193fc81afa7@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
 <8d5us_1aPK9ZKVkA3712a0aFzkkGiC-3Ho10FZbk5sA=.fe57780d-a678-4b8e-ac3e-301ac8246c37@github.com>
 <k28vKOBQbmPLsY0bQ5izKCC-sWcE_uulmkOV7WpGmto=.1d991bc6-9713-443e-98a2-8193fc81afa7@github.com>
Message-ID: <hdyAJMoRB-YvlfkBOIOBVf72uvQvYBAt0NeDJhC7-2U=.4dd6a91d-b972-492a-96cc-a9158a7a4b41@github.com>

On Tue, 8 Dec 2020 18:24:21 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Harold Seigel has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8256867: Classes with empty PermittedSubclasses attribute cannot be extended
>
> Marked as reviewed by mchung (Reviewer).

Thanks Mandy, Chris, Lois, and Jan for reviewing this change.
Harold

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

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

From naoto at openjdk.java.net  Tue Dec  8 18:44:10 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 8 Dec 2020 18:44:10 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <Fd81NFkU3bt5ZOedlgG7f2BcvIC2xWuLGD0Eg0TuMsw=.83681790-d8ac-4ec0-a0a3-00d582ac2f15@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
 <Fd81NFkU3bt5ZOedlgG7f2BcvIC2xWuLGD0Eg0TuMsw=.83681790-d8ac-4ec0-a0a3-00d582ac2f15@github.com>
Message-ID: <k9qXBPmHPOK7f3RlgFTgAwZ_xNkAHcCP2BMajiIcUHA=.05b9e889-3dd2-4e3f-b5a5-41c629077255@github.com>

On Tue, 8 Dec 2020 17:33:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.
>
>> @AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place.
> 
> This is a complicated area of the build, not really a Project Jigsaw issue. It's complicated because the source code for the charsets is generated at build time and the set of non-standard charsets included in java.base varies by platform, e.g. there's are several IBMxxx charsets in java.base when building on AIX that are not interesting to include in java.base on other platforms. This means we can't split up the mapping tables in make/data/charsetmapping and put them in different directories. If you are moving them into the src tree then src/java.base (as you have it) is best but will still have the ugly wart that some of these mapping tables will be used to generate code for the jdk.charsets module.

> @AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place.
> 
> I chose to put the data files used for both java.base and the "additional" modules in java.base, based on the comment that Naoto made in https://mail.openjdk.java.net/pipermail/build-dev/2020-March/027044.html:
> 
> > As to charsetmapping and cldrconverter, I believe they can reside in
> > java.base, as jdk.charsets and jdk.localedata modules depend on it.
> 
> Of course it would be preferable to make a proper split, but that requires work done by the component teams to break the modules apart.
> 
> Specifically for make/modules/jdk.charsets/Gensrc.gmk; the code in that file is more or less duplicated in make/modules/java.base/gensrc/GensrcCharsetMapping.gmk, since the same data set is processed twice, once for java.base and once for jdk.charsets. I don't think that means that make/modules/jdk.charsets/Gensrc.gmk should move to any other place.

I still stand by what I wrote above. It's best to put data in java.base for charsets/localedata. Otherwise we would have to duplicate some in each modules source directory.

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

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

From ihse at openjdk.java.net  Tue Dec  8 19:15:46 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 8 Dec 2020 19:15:46 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <Fd81NFkU3bt5ZOedlgG7f2BcvIC2xWuLGD0Eg0TuMsw=.83681790-d8ac-4ec0-a0a3-00d582ac2f15@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <9SZAjp4Agg8nuCAIUomuXYESFu474ADtc7czst3-cjI=.13ca0e6f-2f17-4f0b-9565-040d59202eeb@github.com>
 <RAEql382cA5zaYHXfMF4GKJzYhkrBUyhkr_-0sgO3VA=.c812196d-82bb-4b3f-9272-59e918b44a91@github.com>
 <Dgm_FfhXDuISICFpGwptt2Afk_K1WE3VQ4BnsMWQ7F4=.1707e545-0630-4a36-b374-239de1be825f@github.com>
 <jj1EJul6uGC9e0NTkanGzMnBT7hcghrXLB3eRQorU5U=.5b075c81-1bd7-4918-b993-cbc667b996a8@github.com>
 <5sm2-MwZfugM_S1QWZTHkQSkScMYDgUkXsmp9zEjdi4=.9889aa8f-edc1-44f7-b9f6-20e4b0b7491d@github.com>
 <Fd81NFkU3bt5ZOedlgG7f2BcvIC2xWuLGD0Eg0TuMsw=.83681790-d8ac-4ec0-a0a3-00d582ac2f15@github.com>
Message-ID: <NvyCKRMEPTJVNNstfqibDocrM3eRvRhp-oKn4RwS5JU=.25dc3794-c662-47ef-ac56-bed4e398cbbe@github.com>

On Tue, 8 Dec 2020 17:33:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The mapping and nr tables, and the *-X.java.template files in make/data/charsetmapping are used to generate source code for the java.base and jdk.charsets modules. The stdcs-$OS files configure the package and module that each charset go into. If the tables used to generate the source files are moved to src/java.base then make/modules/jdk.charsets/Gensrc.gmk will probably need a new home too.
>
>> @AlanBateman The process of modularization was not fully completed with Project Jigsaw, and a few ugly warts remained. I was under the impression that these should be addressed in follow-up fixes, but this was unfortunately never done. Charsets and cldrconverter were both split between a core portion in java.base and the rest in jdk.charsets and jdk.localedata, respectively, but the split was never handled properly, but just "duct taped" in place.
> 
> This is a complicated area of the build, not really a Project Jigsaw issue. It's complicated because the source code for the charsets is generated at build time and the set of non-standard charsets included in java.base varies by platform, e.g. there's are several IBMxxx charsets in java.base when building on AIX that are not interesting to include in java.base on other platforms. This means we can't split up the mapping tables in make/data/charsetmapping and put them in different directories. If you are moving them into the src tree then src/java.base (as you have it) is best but will still have the ugly wart that some of these mapping tables will be used to generate code for the jdk.charsets module.

@AlanBateman @mlchung @naotoj I can certainly anticipate follow-up cleanups on this patch. In fact, I think this patch has the potential to be a catalyst for such change, since the data that has been "hidden away" in `make` now becomes more visible to the teams that are capable of doing something about it. (With that said, of course the build team will assist in helping to clear up messy code structure, as we always do.) But I think we should be restrictive in trying too hard to make everything right in this single patch; it's better to get things approximately right and then go through the "warts" one by one and solve them properly.

@AlanBateman What I meant by Jigsaw was that when the monolithic source code were modularized, the separation of concern between java.base and jdk.charsets/jdk.localedata was not complete, compared to (more or less) all other modules. It might very well be the case that we will never be able to make such a separation; but, prior to Jigsaw, this was not a "wart". It only became a code hygiene issue when some of the charsets and localedata was extraced from java.base.

@mlchung My gut reaction is that we should not change idea.sh. First of all, kind of the purpose of this move is to make it clear to module developers the full set of materials their module consists of. That purpose would be sort of defeated, if we were to hide this in a popular IDE configuration. Secondly, I doubt this will add any performance difference. Listing additional files in the workspace is unlikely to do much, unless you actively open and/or interact with these files. But if you are worried, please fetch the PR (Skara adds instructions in the body) and try it out yourself!

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

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

From jjg at openjdk.java.net  Tue Dec  8 19:23:44 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 8 Dec 2020 19:23:44 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations. [v6]
In-Reply-To: <6F0Kz14Rd1Wdz6odAtI3AcTeG-gD04RQuYFVO2gG8VA=.dd398953-4084-4fe0-99d4-e0f927b8c93b@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
 <r6x0B8EUk4UVr8bP6gCQ4FS63wxnQLg6uhDHyjQ5cvA=.b27e6dc8-35c1-4360-b62d-e0aa196e6f4a@github.com>
 <6F0Kz14Rd1Wdz6odAtI3AcTeG-gD04RQuYFVO2gG8VA=.dd398953-4084-4fe0-99d4-e0f927b8c93b@github.com>
Message-ID: <BPErLUd1SVfqJPhQGYSya8GbuKRYBJ3JX-Lt3sgY59E=.d2c83ac6-38a9-49a7-bbd7-4ff567fc159d@github.com>

On Tue, 8 Dec 2020 13:14:19 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons 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 12 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into new-return
>>  - Update JShell to handle inline `{@return}`
>>  - Merge remote-tracking branch 'upstream/master' into new-return
>>  - fix test
>>  - Update for new `@return` tag
>>  - Merge remote-tracking branch 'upstream/master' into new-return
>>  - Update DocCommentParser to permit nested inline tags in specified cases: @return
>>  - Add default impl for new method
>>  - Fix test failure
>>  - Fix trailing whitespace in test
>>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/c3337822...a25dadca
>
> src/jdk.compiler/share/classes/com/sun/source/util/DocTreeFactory.java line 277:
> 
>> 275:      * @param description the description of the return value of a method
>> 276:      * @return a {@code ReturnTree} object
>> 277:      * @throws UnsupportedOperationException if inline {@code {@return} } tags are
> 
> To be consistent with the rest of the file, I suggest using `{@code {@return }}` instead of `{@code {@return} }` (note the position of the whitespace).

fixed

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 275:
> 
>> 273:                         return tp.parse(p, TagParser.Kind.BLOCK);
>> 274:                     } else {
>> 275:                             return erroneous("dc.bad.inline.tag", p);
> 
> This indentation fits the current `switch` but not the proposed `if` statement.

fixed

> src/jdk.compiler/share/classes/com/sun/source/doctree/ReturnTree.java line 44:
> 
>> 42:      * Returns whether this instance is an inline tag.
>> 43:      *
>> 44:      * @return {@code true} if this instance is an inline tag
> 
> Although I'm not sure how `boolean` queries are generally specified in the `DocTree` API, consider explicitly specifying that this method returns `false` if called on a non-inline instance.

hmm, OK, seems a bit redundant but will add `and {@code false} otherwise`

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 333:
> 
>> 331:                     DCTree text = inlineText(WhitespaceRetentionPolicy.REMOVE_ALL); // skip content
>> 332:                     nextChar();
>> 333:                     return m.at(p).newUnknownInlineTagTree(name, List.of(text)).setEndPos(bp);
> 
> There's a discrepancy between the inline comment and code. While the comment says that the `else` clause handles a block tag, the returned tree corresponds to an (unknown) inline tag.

The code is correct, and even the comment: which refers to "block tags in inline content".
The case being handled is one like this:

`
    /**
     * This is a bad comment. {@see Object} or {@since 7}.
     */
`

> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/DocCommentParser.java line 1132:
> 
>> 1130: 
>> 1131:     /**
>> 1132:      * @see <a href="https://docs.oracle.com/en/java/javase/14/docs/specs/javadoc/doc-comment-spec.html">JavaDoc Tags</a>
> 
> Consider updating the version to 15. Later, we'd hopefully be able to use the [`@spec` tag](https://bugs.openjdk.java.net/browse/JDK-8226279) here.

done

Yes, this could eventually be a use of the proposed `@spec` tag with a relative URL

> src/jdk.compiler/share/classes/com/sun/tools/javac/tree/DCTree.java line 690:
> 
>> 688: 
>> 689:         @Override
>> 690:         public String getTagName() {
> 
> Isn't this method missing `@DefinedBy(Api.COMPILER_TREE)`?

Oops, yes; fixed; I guess I'm mildly surprised the checker didn't catch it, but that's a different issue

> src/jdk.compiler/share/classes/jdk/internal/shellsupport/doc/JavadocFormatter.java line 268:
> 
>> 266:         /**
>> 267:          * {@inheritDoc}
>> 268:          * {@code @return} is a bimodfal tage and can be used as either a block tag or an inline
> 
> Fix the typos in "bimodfal tage".

Oops, also fixed an instance of `null` to `{@code null}`

> test/langtools/jdk/internal/shellsupport/doc/JavadocFormatterTest.java line 140:
> 
>> 138:                    "1234 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234\n" +
>> 139:                    "1234 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234\n" +
>> 140:                    "1234 1234 1234 1234 1234 1234 1234 1234 1234 \n";
> 
> What's that about? I mean is it related to this work on `{@return}`?

It was needed to fix a test failure

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

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

From jjg at openjdk.java.net  Tue Dec  8 19:31:49 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 8 Dec 2020 19:31:49 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations. [v6]
In-Reply-To: <6F0Kz14Rd1Wdz6odAtI3AcTeG-gD04RQuYFVO2gG8VA=.dd398953-4084-4fe0-99d4-e0f927b8c93b@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
 <r6x0B8EUk4UVr8bP6gCQ4FS63wxnQLg6uhDHyjQ5cvA=.b27e6dc8-35c1-4360-b62d-e0aa196e6f4a@github.com>
 <6F0Kz14Rd1Wdz6odAtI3AcTeG-gD04RQuYFVO2gG8VA=.dd398953-4084-4fe0-99d4-e0f927b8c93b@github.com>
Message-ID: <Hu07LLzaL2T4Mce31UlhLUFYqA6ht6OPCOEv777eyx8=.ffcdbb13-f14d-4211-9658-7186c03c71c8@github.com>

On Tue, 8 Dec 2020 17:52:14 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons 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 12 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into new-return
>>  - Update JShell to handle inline `{@return}`
>>  - Merge remote-tracking branch 'upstream/master' into new-return
>>  - fix test
>>  - Update for new `@return` tag
>>  - Merge remote-tracking branch 'upstream/master' into new-return
>>  - Update DocCommentParser to permit nested inline tags in specified cases: @return
>>  - Add default impl for new method
>>  - Fix test failure
>>  - Fix trailing whitespace in test
>>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/695b9bdc...a25dadca
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/ReturnTaglet.java line 76:
> 
>> 74:         } else {
>> 75:             List<? extends DocTree> firstSentence = utils.getFirstSentenceTrees(input.element);
>> 76:             if (firstSentence.size() == 1 && firstSentence.get(0).getKind() == DocTree.Kind.RETURN) {
> 
> There's one more place where `firstSentence.size() == 1` is checked. I wonder if it could be a simpler `!firstSentence.isEmpty()` check?
> 
> Are there any non-trivial cases which might bite us later, should we change that check?

I think the code is better as is.  It would be wrong to have a firstSentence containing multiple items, beginning with `{@return}` and then to only return the first one in the following line of code. Arguably, a better form may be to use `isEmpty()` and then subsequently assert (somehow) that the size is exactly 1, but using assertions like that is a different discussion (as you know!)

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties line 60:
> 
>> 58: dc.param.name.not.found = @param name not found
>> 59: dc.ref.not.found = reference not found
>> 60: dc.return.not.first = '{@return'} not at beginning of description
> 
> I can see an inconsistency here. While the templates for `@return` and `@code` put an apostrophe immediately before the closing `}`, the template for `@value` (further below in this file) puts an apostrophe immediately after the closing `}`.

I'll investigate and follow up.  It looks like general confusion whether to escape the curly braces, or to quote the enclosed text in the generated message.

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

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

From jlahoda at openjdk.java.net  Tue Dec  8 19:35:03 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 8 Dec 2020 19:35:03 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v12]
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <mCFx_-zaZljumWnBwZfRwVqIs2zBHbQXMec4CBaQKS8=.f75babcd-333b-427d-9152-6f386736bb7f@github.com>

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
> 
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 55 commits:

 - Merging recent master changes into JDK-8250768
 - Fixing navigator for the PREVIEW page.
 - Fixing typo.
 - Removing obsolette @PreviewFeature.
 - Merging master into JDK-8250768
 - Removing unnecessary property keys.
 - Cleanup - removing unnecessary code.
 - Merging master into JDK-8250768-dev4
 - Reflecting review comments.
 - Removing trailing whitespace.
 - ... and 45 more: https://git.openjdk.java.net/jdk/compare/044616bd...0c1c4d57

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

Changes: https://git.openjdk.java.net/jdk/pull/703/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=11
  Stats: 3711 lines in 132 files changed: 2726 ins; 692 del; 293 mod
  Patch: https://git.openjdk.java.net/jdk/pull/703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703

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

From jjg at openjdk.java.net  Tue Dec  8 19:39:34 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 8 Dec 2020 19:39:34 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations. [v6]
In-Reply-To: <Hu07LLzaL2T4Mce31UlhLUFYqA6ht6OPCOEv777eyx8=.ffcdbb13-f14d-4211-9658-7186c03c71c8@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
 <r6x0B8EUk4UVr8bP6gCQ4FS63wxnQLg6uhDHyjQ5cvA=.b27e6dc8-35c1-4360-b62d-e0aa196e6f4a@github.com>
 <6F0Kz14Rd1Wdz6odAtI3AcTeG-gD04RQuYFVO2gG8VA=.dd398953-4084-4fe0-99d4-e0f927b8c93b@github.com>
 <Hu07LLzaL2T4Mce31UlhLUFYqA6ht6OPCOEv777eyx8=.ffcdbb13-f14d-4211-9658-7186c03c71c8@github.com>
Message-ID: <o_s2YWGXPZW407TYuwVobzRSb2tHHod3h77Z13Xc4VA=.533ca947-c406-4a13-b506-2b5edfc1302d@github.com>

On Tue, 8 Dec 2020 19:29:15 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties line 60:
>> 
>>> 58: dc.param.name.not.found = @param name not found
>>> 59: dc.ref.not.found = reference not found
>>> 60: dc.return.not.first = '{@return'} not at beginning of description
>> 
>> I can see an inconsistency here. While the templates for `@return` and `@code` put an apostrophe immediately before the closing `}`, the template for `@value` (further below in this file) puts an apostrophe immediately after the closing `}`.
>
> I'll investigate and follow up.  It looks like general confusion whether to escape the curly braces, or to quote the enclosed text in the generated message.

It looks like the quotes are never needed. I'll remove all of them.

`
/**
 * This is a comment.
 * This is a bad {@return fred}
 * This is a bad {@value}
 * This is a bad <code>{@code code}</code>.
 */
public class C { }
`

`
play/doclint-msgs/src/C.java:3: warning: {@return} not at beginning of description
 * This is a bad {@return fred}
                 ^
play/doclint-msgs/src/C.java:3: error: invalid use of @return
 * This is a bad {@return fred}
                 ^
play/doclint-msgs/src/C.java:4: error: {@value} not allowed here
 * This is a bad {@value}
                 ^
play/doclint-msgs/src/C.java:5: warning: {@code} within <code>
 * This is a bad <code>{@code code}</code>.
                       ^
2 errors
2 warnings
`

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

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

From jlahoda at openjdk.java.net  Tue Dec  8 20:34:42 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 8 Dec 2020 20:34:42 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations. [v6]
In-Reply-To: <r6x0B8EUk4UVr8bP6gCQ4FS63wxnQLg6uhDHyjQ5cvA=.b27e6dc8-35c1-4360-b62d-e0aa196e6f4a@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
 <r6x0B8EUk4UVr8bP6gCQ4FS63wxnQLg6uhDHyjQ5cvA=.b27e6dc8-35c1-4360-b62d-e0aa196e6f4a@github.com>
Message-ID: <cbBEBOyQa9TuERImoX5p141C30qmLcyGZbz1u754r4I=.42841c51-d38b-4fff-8599-c1a27efcba00@github.com>

On Mon, 7 Dec 2020 18:37:37 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description.
>> 
>> The goal is to be able to simplify the following common pattern:
>> 
>>     /**
>>      * Returns the result. Optional additional text.
>>      * @return the result
>>      */
>>     int method() { 
>> 
>> by 
>> 
>>     /**
>>      * {@return the result} Optional additional text.
>>      */
>>     int method() { 
>> 
>> Note:
>> 
>> * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere.
>> * The expansion of the inline tag is `Returns " _content_ `.`  where _content_ is the content of the tag. 
>> * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description
>> * The inline tag can be inherited into overriding methods as if it was provided as a block tag.
>
> Jonathan Gibbons 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 12 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into new-return
>  - Update JShell to handle inline `{@return}`
>  - Merge remote-tracking branch 'upstream/master' into new-return
>  - fix test
>  - Update for new `@return` tag
>  - Merge remote-tracking branch 'upstream/master' into new-return
>  - Update DocCommentParser to permit nested inline tags in specified cases: @return
>  - Add default impl for new method
>  - Fix test failure
>  - Fix trailing whitespace in test
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/d5251c03...a25dadca

The javac/jshell changes look sensible to me.

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

Marked as reviewed by jlahoda (Reviewer).

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

From jlahoda at openjdk.java.net  Tue Dec  8 20:34:45 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Tue, 8 Dec 2020 20:34:45 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations. [v6]
In-Reply-To: <BPErLUd1SVfqJPhQGYSya8GbuKRYBJ3JX-Lt3sgY59E=.d2c83ac6-38a9-49a7-bbd7-4ff567fc159d@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
 <r6x0B8EUk4UVr8bP6gCQ4FS63wxnQLg6uhDHyjQ5cvA=.b27e6dc8-35c1-4360-b62d-e0aa196e6f4a@github.com>
 <6F0Kz14Rd1Wdz6odAtI3AcTeG-gD04RQuYFVO2gG8VA=.dd398953-4084-4fe0-99d4-e0f927b8c93b@github.com>
 <BPErLUd1SVfqJPhQGYSya8GbuKRYBJ3JX-Lt3sgY59E=.d2c83ac6-38a9-49a7-bbd7-4ff567fc159d@github.com>
Message-ID: <JnQtc3k2pGLwvCgsDVXMJqmkEDw-yHZN8lEDFt_F_O8=.d18d689c-8ca4-4cbf-a367-9f32dffff3b0@github.com>

On Tue, 8 Dec 2020 19:21:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> test/langtools/jdk/internal/shellsupport/doc/JavadocFormatterTest.java line 140:
>> 
>>> 138:                    "1234 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234\n" +
>>> 139:                    "1234 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234 1234\n" +
>>> 140:                    "1234 1234 1234 1234 1234 1234 1234 1234 1234 \n";
>> 
>> What's that about? I mean is it related to this work on `{@return}`?
>
> It was needed to fix a test failure

FWIW, I believe the reason is that JavadocFormatter.scan (around line 580 in the new code) is checking for inline tags using the instanceof operator, and adds a space for inline tags. We could add a test to prevent that (i.e. not add the space , but not sure if there is a real problem with generating the space.

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

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

From jjg at openjdk.java.net  Tue Dec  8 21:05:41 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 8 Dec 2020 21:05:41 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v5]
In-Reply-To: <bG8PpoaqCnD_mWq0sKWSkOgOmiEyvsrpbn9v5hRTWuM=.a4206e56-1a5b-493e-9e47-7156166c74fa@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
 <bG8PpoaqCnD_mWq0sKWSkOgOmiEyvsrpbn9v5hRTWuM=.a4206e56-1a5b-493e-9e47-7156166c74fa@github.com>
Message-ID: <GdekdlOJbNpIYlK9w5R6xo7pWYlFAgUXK45IQxBvN-c=.c6c809b7-250b-4170-85e3-d8f4f60f1205@github.com>

On Thu, 3 Dec 2020 09:22:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
>> -updating and moving tests into test/langtools, so that it is easier to run them.
>> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
>> -fixing the -Xprint annotation processor to print record component annotations.
>> 
>> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Blank lines do not count for the text block indentation, removing them.

Marked as reviewed by jjg (Reviewer).

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

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

From jjg at openjdk.java.net  Tue Dec  8 21:07:00 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 8 Dec 2020 21:07:00 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations. [v7]
In-Reply-To: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
Message-ID: <mxzmCSyd8Tsa_oLe3y6UyWZQ3TnGesro59Pw8uWA8R4=.190db47e-27d1-4710-a20f-f1202017cc2f@github.com>

> This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description.
> 
> The goal is to be able to simplify the following common pattern:
> 
>     /**
>      * Returns the result. Optional additional text.
>      * @return the result
>      */
>     int method() { 
> 
> by 
> 
>     /**
>      * {@return the result} Optional additional text.
>      */
>     int method() { 
> 
> Note:
> 
> * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere.
> * The expansion of the inline tag is `Returns " _content_ `.`  where _content_ is the content of the tag. 
> * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description
> * The inline tag can be inherited into overriding methods as if it was provided as a block tag.

Jonathan Gibbons 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 13 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into new-return
 - Merge remote-tracking branch 'upstream/master' into new-return
 - Update JShell to handle inline `{@return}`
 - Merge remote-tracking branch 'upstream/master' into new-return
 - fix test
 - Update for new `@return` tag
 - Merge remote-tracking branch 'upstream/master' into new-return
 - Update DocCommentParser to permit nested inline tags in specified cases: @return
 - Add default impl for new method
 - Fix test failure
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/8575ca29...95e21512

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1355/files
  - new: https://git.openjdk.java.net/jdk/pull/1355/files/a25dadca..95e21512

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1355&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1355&range=05-06

  Stats: 2176 lines in 64 files changed: 1570 ins; 338 del; 268 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1355.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1355/head:pull/1355

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

From jjg at openjdk.java.net  Tue Dec  8 21:10:56 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 8 Dec 2020 21:10:56 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations. [v8]
In-Reply-To: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
Message-ID: <634yP2cV-UXVQEBl4kwtb24ktGnQecgdVpAMb_AiZks=.828a786e-374d-4d1f-b8b9-7d5df67fc4ac@github.com>

> This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description.
> 
> The goal is to be able to simplify the following common pattern:
> 
>     /**
>      * Returns the result. Optional additional text.
>      * @return the result
>      */
>     int method() { 
> 
> by 
> 
>     /**
>      * {@return the result} Optional additional text.
>      */
>     int method() { 
> 
> Note:
> 
> * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere.
> * The expansion of the inline tag is `Returns " _content_ `.`  where _content_ is the content of the tag. 
> * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description
> * The inline tag can be inherited into overriding methods as if it was provided as a block tag.

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

  address review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1355/files
  - new: https://git.openjdk.java.net/jdk/pull/1355/files/95e21512..8f62f5a9

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

  Stats: 15 lines in 9 files changed: 1 ins; 0 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1355.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1355/head:pull/1355

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

From darcy at openjdk.java.net  Tue Dec  8 22:02:36 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 8 Dec 2020 22:02:36 GMT
Subject: RFR: 8257845: Integrate JEP 390
In-Reply-To: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>
References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>
Message-ID: <lA2QkyGu3CXrJiU2e9BPPLiOHGgontFySBCP4bBvcYI=.18155edc-dfa5-4a5c-8b21-3dd8d6d5612c@github.com>

On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100).
> 
> Development has been broken into 5 tasks, each with its own JBS issue:
> - [JDK-8252180](https://bugs.openjdk.java.net/browse/JDK-8252180): Deprecate wrapper class constructors for removal (rriggs)
> - [JDK-8254047](https://bugs.openjdk.java.net/browse/JDK-8254047): Revise "value-based class" & apply to wrappers (dlsmith)
> - [JDK-8252181](https://bugs.openjdk.java.net/browse/JDK-8252181):Define & apply annotation jdk.internal.ValueBased (rriggs)
> - [JDK-8252183](https://bugs.openjdk.java.net/browse/JDK-8252183): Add 'lint' warning for @ValueBased classes (sadayapalam)
> - [JDK-8257027](https://bugs.openjdk.java.net/browse/JDK-8257027): Diagnose synchronization on @ValueBased classes (lfoltan)
> 
> All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.)
> 
> CSRs have also been completed or are nearly complete:
> 
> - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation
> - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class"
> - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings
> 
> Here's an overview of the files changed:
> 
> - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes.
> 
> - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance.
> 
> - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation.
> 
> - `src/java.management.rmi`: removing uses of wrapper class constructors.
> 
> - `src/java.xml`: removing uses of wrapper class constructors.
> 
> - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`.
> 
> - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.)
> 
> - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests
> 
> - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics
> 
> - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`.

Marked as reviewed by darcy (Reviewer).

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

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

From prappo at openjdk.java.net  Tue Dec  8 22:42:36 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 8 Dec 2020 22:42:36 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations. [v6]
In-Reply-To: <Hu07LLzaL2T4Mce31UlhLUFYqA6ht6OPCOEv777eyx8=.ffcdbb13-f14d-4211-9658-7186c03c71c8@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
 <r6x0B8EUk4UVr8bP6gCQ4FS63wxnQLg6uhDHyjQ5cvA=.b27e6dc8-35c1-4360-b62d-e0aa196e6f4a@github.com>
 <6F0Kz14Rd1Wdz6odAtI3AcTeG-gD04RQuYFVO2gG8VA=.dd398953-4084-4fe0-99d4-e0f927b8c93b@github.com>
 <Hu07LLzaL2T4Mce31UlhLUFYqA6ht6OPCOEv777eyx8=.ffcdbb13-f14d-4211-9658-7186c03c71c8@github.com>
Message-ID: <4j3lZSRTfTYC5-97JUGuY0sYDP3c8h_VOSK3XuGWAGw=.0b3cf943-207a-43b9-a9a7-15fd361d109b@github.com>

On Tue, 8 Dec 2020 19:27:32 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/taglets/ReturnTaglet.java line 76:
>> 
>>> 74:         } else {
>>> 75:             List<? extends DocTree> firstSentence = utils.getFirstSentenceTrees(input.element);
>>> 76:             if (firstSentence.size() == 1 && firstSentence.get(0).getKind() == DocTree.Kind.RETURN) {
>> 
>> There's one more place where `firstSentence.size() == 1` is checked. I wonder if it could be a simpler `!firstSentence.isEmpty()` check?
>> 
>> Are there any non-trivial cases which might bite us later, should we change that check?
>
> I think the code is better as is.  It would be wrong to have a firstSentence containing multiple items, beginning with `{@return}` and then to only return the first one in the following line of code. Arguably, a better form may be to use `isEmpty()` and then subsequently assert (somehow) that the size is exactly 1, but using assertions like that is a different discussion (as you know!)

I guess I was thinking about a corner case like `{@summary {@return ...} ...}` which this patch and the complementary specification consider illegal anyway.

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

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

From dholmes at openjdk.java.net  Tue Dec  8 22:38:37 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 8 Dec 2020 22:38:37 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v5]
In-Reply-To: <Dz2qX4jgdJNFNA7gCwtoIYSsdNpkp4T77NAdnYbb-y4=.1e89eca5-a6e3-4397-afe3-94ca88265147@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <Dz2qX4jgdJNFNA7gCwtoIYSsdNpkp4T77NAdnYbb-y4=.1e89eca5-a6e3-4397-afe3-94ca88265147@github.com>
Message-ID: <6zD-WD76gZaXzeOuaj0c1N75lPbLTxUOHoLu9M4ZbLc=.367ab8af-b105-4977-afe1-0a29bbe2d88a@github.com>

On Tue, 8 Dec 2020 17:10:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Start of JDK 17 updates.
>
> Joe Darcy 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 12 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8257450
>  - Update symbol files for JDK 16b27.
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'master' into JDK-8257450
>  - Update tests.
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - JDK-8257450
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/d1c29ce3...ff9b78ec

Marked as reviewed by dholmes (Reviewer).

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

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

From prappo at openjdk.java.net  Tue Dec  8 22:58:36 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 8 Dec 2020 22:58:36 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations. [v8]
In-Reply-To: <634yP2cV-UXVQEBl4kwtb24ktGnQecgdVpAMb_AiZks=.828a786e-374d-4d1f-b8b9-7d5df67fc4ac@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
 <634yP2cV-UXVQEBl4kwtb24ktGnQecgdVpAMb_AiZks=.828a786e-374d-4d1f-b8b9-7d5df67fc4ac@github.com>
Message-ID: <XTY6lPbLJn623b7zk4vK2rzR84wmFyWCSG9g0-paNmQ=.40ef6310-690c-41ee-8ade-a0b55ed163c0@github.com>

On Tue, 8 Dec 2020 21:10:56 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description.
>> 
>> The goal is to be able to simplify the following common pattern:
>> 
>>     /**
>>      * Returns the result. Optional additional text.
>>      * @return the result
>>      */
>>     int method() { 
>> 
>> by 
>> 
>>     /**
>>      * {@return the result} Optional additional text.
>>      */
>>     int method() { 
>> 
>> Note:
>> 
>> * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere.
>> * The expansion of the inline tag is `Returns " _content_ `.`  where _content_ is the content of the tag. 
>> * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description
>> * The inline tag can be inherited into overriding methods as if it was provided as a block tag.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

Thanks for considering my feedback.

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

Marked as reviewed by prappo (Reviewer).

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

From dlsmith at openjdk.java.net  Tue Dec  8 23:07:35 2020
From: dlsmith at openjdk.java.net (Dan Smith)
Date: Tue, 8 Dec 2020 23:07:35 GMT
Subject: Integrated: 8257845: Integrate JEP 390
In-Reply-To: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>
References: <14WC4YuIN1sJ3jl5_htTC7wkzyzjpt540r7tmEQ85Lc=.4c5ac2b3-d24a-4aae-886b-b07e671f2948@github.com>
Message-ID: <m1u0m-A87QjUbJ0ibhqKmX9jplJ-_fl0G9kMFbRg2h0=.05c46efb-fd39-405e-9282-b552fc4e5f98@github.com>

On Sat, 5 Dec 2020 01:46:31 GMT, Dan Smith <dlsmith at openjdk.org> wrote:

> Integration of [JEP 390](https://bugs.openjdk.java.net/browse/JDK-8249100).
> 
> Development has been broken into 5 tasks, each with its own JBS issue:
> - [JDK-8252180](https://bugs.openjdk.java.net/browse/JDK-8252180): Deprecate wrapper class constructors for removal (rriggs)
> - [JDK-8254047](https://bugs.openjdk.java.net/browse/JDK-8254047): Revise "value-based class" & apply to wrappers (dlsmith)
> - [JDK-8252181](https://bugs.openjdk.java.net/browse/JDK-8252181):Define & apply annotation jdk.internal.ValueBased (rriggs)
> - [JDK-8252183](https://bugs.openjdk.java.net/browse/JDK-8252183): Add 'lint' warning for @ValueBased classes (sadayapalam)
> - [JDK-8257027](https://bugs.openjdk.java.net/browse/JDK-8257027): Diagnose synchronization on @ValueBased classes (lfoltan)
> 
> All changes have been previously reviewed and integrated into the [`jep390` branch](https://github.com/openjdk/valhalla/tree/jep390) of the `valhalla` repository. See the subtasks of the 5 JBS issues for these changes, including discussion and links to reviews. (Reviewers: mchung, dlsmith, jlaskey, rriggs, lfoltan, fparain, hseigel.)
> 
> CSRs have also been completed or are nearly complete:
> 
> - [JDK-8254324](https://bugs.openjdk.java.net/browse/JDK-8254324) for wrapper class constructor deprecation
> - [JDK-8254944](https://bugs.openjdk.java.net/browse/JDK-8254944) for revisions to "value-based class"
> - [JDK-8256023](https://bugs.openjdk.java.net/browse/JDK-8256023) for new `javac` lint warnings
> 
> Here's an overview of the files changed:
> 
> - `src/hotspot`: implementing diagnostics when `monitorenter` is applied to an instance of a class tagged with `jdk.internal.ValueBased`. This enhances previous work that produced such diagnostics for the primitive wrapper classes.
> 
> - `src/java.base/share/classes/java/lang`: deprecating for removal the wrapper class constructors; revising the definition of "value-based class" in `ValueBased.html` and the description used by linking classes; applying "value-based class" to the primitive wrapper classes; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/java/lang/constant`: no longer designating these classes as "value-based", since they rely heavily on field inheritance.
> 
> - `src/java.base/share/classes/java/time`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/java/util`: revising the description used to link to `ValueBased.html`; marking value-based classes with `@jdk.internal.ValueBased`.
> 
> - `src/java.base/share/classes/jdk/internal`: define the `@jdk.internal.ValueBased` annotation.
> 
> - `src/java.management.rmi`: removing uses of wrapper class constructors.
> 
> - `src/java.xml`: removing uses of wrapper class constructors.
> 
> - `src/jdk.compiler`: implementing the `synchronization` lint category, which reports attempts to synchronize on classes and interfaces annotated with `@jdk.internal.ValueBased`.
> 
> - `src/jdk.incubator.foreign`: revising the description used to link to `ValueBased.html`. (Applying `@jdk.internal.ValueBased` would require a special module export, which was not deemed necessary for an incubating API.)
> 
> - `src/jdk.internal.vm.compiler`: suppressing `javac` deprecation and synchronization warnings in tests
> 
> - `src/jdk.jfr`: supplementary changes for HotSpot diagnostics
> 
> - `test`: testing new `javac` and HotSpot behavior; removing usages of deprecated wrapper class constructors from tests, or suppressing deprecation warnings; revising the description used to link to `ValueBased.html`.

This pull request has now been integrated.

Changeset: 48d8650a
Author:    Dan Smith <dlsmith at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/48d8650a
Stats:     902 lines in 114 files changed: 489 ins; 121 del; 292 mod

8257845: Integrate JEP 390
8254047: [JEP 390] Revise "value-based class" & apply to wrappers
8252181: [JEP 390] Define & apply annotation jdk.internal.ValueBased
8252183: [JEP 390] Add 'lint' warning for @ValueBased classes
8257027: [JEP 390] Diagnose synchronization on @ValueBased classes
8252180: [JEP 390] Deprecate wrapper class constructors for removal

Co-authored-by: Roger Riggs <rriggs at openjdk.org>
Co-authored-by: Srikanth Adayapalam <sadayapalam at openjdk.org>
Co-authored-by: Lois Foltan <lfoltan at openjdk.org>
Reviewed-by: rriggs, hseigel, mchung, darcy

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

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

From darcy at openjdk.java.net  Tue Dec  8 23:23:55 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 8 Dec 2020 23:23:55 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v6]
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <2l-iK2j0yRtpmRF_vpBdI9CYFmWeOdBG7ZvM2GyhPp4=.611ca7ee-4de0-4168-9ec8-8784f921de75@github.com>

> Start of JDK 17 updates.

Joe Darcy 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 14 additional commits since the last revision:

 - Get in JEP 390 changes.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Update symbol files for JDK 16b27.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Update tests.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/823053e1...57ba7b64

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1531/files
  - new: https://git.openjdk.java.net/jdk/pull/1531/files/ff9b78ec..57ba7b64

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=04-05

  Stats: 1178 lines in 148 files changed: 571 ins; 195 del; 412 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1531.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531

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

From jjg at openjdk.java.net  Tue Dec  8 23:29:52 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 8 Dec 2020 23:29:52 GMT
Subject: RFR: JDK-8075778: Add javadoc tag to avoid duplication of return
 information in simple situations. [v9]
In-Reply-To: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
Message-ID: <6rIohEbesequmBRim0-RlliTSWpOD4_gkEKHUggfxLc=.ce34ae75-952c-4c7c-bb3c-9d3dcaece7f3@github.com>

> This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description.
> 
> The goal is to be able to simplify the following common pattern:
> 
>     /**
>      * Returns the result. Optional additional text.
>      * @return the result
>      */
>     int method() { 
> 
> by 
> 
>     /**
>      * {@return the result} Optional additional text.
>      */
>     int method() { 
> 
> Note:
> 
> * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere.
> * The expansion of the inline tag is `Returns " _content_ `.`  where _content_ is the content of the tag. 
> * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description
> * The inline tag can be inherited into overriding methods as if it was provided as a block tag.

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

  fix whitespace

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1355/files
  - new: https://git.openjdk.java.net/jdk/pull/1355/files/8f62f5a9..58a6e7ed

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

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

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

From jjg at openjdk.java.net  Tue Dec  8 23:29:53 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 8 Dec 2020 23:29:53 GMT
Subject: Integrated: JDK-8075778: Add javadoc tag to avoid duplication of
 return information in simple situations.
In-Reply-To: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
References: <fZzUIlQpgbewvdAaP7Bkwh-z_IHxJvxVznbKkFj7CVM=.677c60ee-19f8-43bd-bc3a-339519e5da7f@github.com>
Message-ID: <g5PLwdDcYAhThp-7DESph5GUCyCYhfIjDGImiXPGQWQ=.70b17b5f-efff-4cd4-9639-40f10d1acd0b@github.com>

On Fri, 20 Nov 2020 17:15:22 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> This change extends the functionality of the `@return` tag so that it can also be used as an inline tag in the first sentence of a description.
> 
> The goal is to be able to simplify the following common pattern:
> 
>     /**
>      * Returns the result. Optional additional text.
>      * @return the result
>      */
>     int method() { 
> 
> by 
> 
>     /**
>      * {@return the result} Optional additional text.
>      */
>     int method() { 
> 
> Note:
> 
> * The inline tag may only be used at the beginning of the description. A warning will be given if it is used elsewhere.
> * The expansion of the inline tag is `Returns " _content_ `.`  where _content_ is the content of the tag. 
> * If there is no block `@return` tag, the standard doclet will look for an inline tag at the beginning of the description
> * The inline tag can be inherited into overriding methods as if it was provided as a block tag.

This pull request has now been integrated.

Changeset: b29f9cd7
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b29f9cd7
Stats:     696 lines in 21 files changed: 584 ins; 29 del; 83 mod

8075778: Add javadoc tag to avoid duplication of return information in simple situations.

Reviewed-by: prappo, jlahoda

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

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

From darcy at openjdk.java.net  Wed Dec  9 01:49:44 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 9 Dec 2020 01:49:44 GMT
Subject: RFR: 8256917: Use combo @returns tag in java.compiler javadoc
Message-ID: <u6jENcml_43Y96kICsJ7LHcX3MN6ckibw8CbGy03g74=.ad69997b-3fc9-46a6-84bd-f2d690c7d45b@github.com>

Take advantage of upgraded dual-use @return tag.

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

Commit messages:
 - Take advantage of dual-use @return tag.

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

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

From jjg at openjdk.java.net  Wed Dec  9 02:02:34 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 9 Dec 2020 02:02:34 GMT
Subject: RFR: 8256917: Use combo @returns tag in java.compiler javadoc
In-Reply-To: <u6jENcml_43Y96kICsJ7LHcX3MN6ckibw8CbGy03g74=.ad69997b-3fc9-46a6-84bd-f2d690c7d45b@github.com>
References: <u6jENcml_43Y96kICsJ7LHcX3MN6ckibw8CbGy03g74=.ad69997b-3fc9-46a6-84bd-f2d690c7d45b@github.com>
Message-ID: <9xZyBO163QUxE4iqZYBncQgI-sxVsaIIYAN20KxuHhk=.5baf9444-30a9-47f5-98bf-7ba14b138b54@github.com>

On Wed, 9 Dec 2020 01:44:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Take advantage of upgraded dual-use @return tag.

Pleasantly boring. Nice to see the duplication going away.

In places, I would have tweaked the phrasing or the layout, but I accept that would be out of scope for the intent of this otherwise simple change.

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

Marked as reviewed by jjg (Reviewer).

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

From iris at openjdk.java.net  Wed Dec  9 02:14:35 2020
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 9 Dec 2020 02:14:35 GMT
Subject: RFR: 8256917: Use combo @returns tag in java.compiler javadoc
In-Reply-To: <u6jENcml_43Y96kICsJ7LHcX3MN6ckibw8CbGy03g74=.ad69997b-3fc9-46a6-84bd-f2d690c7d45b@github.com>
References: <u6jENcml_43Y96kICsJ7LHcX3MN6ckibw8CbGy03g74=.ad69997b-3fc9-46a6-84bd-f2d690c7d45b@github.com>
Message-ID: <0dNhGAxfKjJL-BPiRhU2hy3Qd3vCkkFED_lQGc-C4mg=.fd7737b3-133e-490d-9b04-40dc837ae853@github.com>

On Wed, 9 Dec 2020 01:44:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Take advantage of upgraded dual-use @return tag.

Straightforward.  I see a few minor differences (e.g. "otherwise returns X" -> "otherwise X"), but nothing significant.  

Fantastic use of the new @returns tag.  I look forward to seeing it used across the JDK.

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

Marked as reviewed by iris (Reviewer).

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

From darcy at openjdk.java.net  Wed Dec  9 02:27:34 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 9 Dec 2020 02:27:34 GMT
Subject: RFR: 8256917: Use combo @returns tag in java.compiler javadoc
In-Reply-To: <0dNhGAxfKjJL-BPiRhU2hy3Qd3vCkkFED_lQGc-C4mg=.fd7737b3-133e-490d-9b04-40dc837ae853@github.com>
References: <u6jENcml_43Y96kICsJ7LHcX3MN6ckibw8CbGy03g74=.ad69997b-3fc9-46a6-84bd-f2d690c7d45b@github.com>
 <0dNhGAxfKjJL-BPiRhU2hy3Qd3vCkkFED_lQGc-C4mg=.fd7737b3-133e-490d-9b04-40dc837ae853@github.com>
Message-ID: <zh_2Kzo2ZAB3tlBK1gyhvHWR02nPmfe5383CRcdgyh0=.ebe3ca59-260d-47c2-9fe4-95cbd77e0856@github.com>

On Wed, 9 Dec 2020 02:11:45 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Take advantage of upgraded dual-use @return tag.
>
> Straightforward.  I see a few minor differences (e.g. "otherwise returns X" -> "otherwise X"), but nothing significant.  
> 
> Fantastic use of the new @returns tag.  I look forward to seeing it used across the JDK.

> 
> 
> Pleasantly boring. Nice to see the duplication going away.
> 
> In places, I would have tweaked the phrasing or the layout, but I accept that would be out of scope for the intent of this otherwise simple change.



> 
> 
> Pleasantly boring. Nice to see the duplication going away.

The feature is working as intended :-)
 
> In places, I would have tweaked the phrasing or the layout, but I accept that would be out of scope for the intent of this otherwise simple change.

Right; this was a first pass over the JSR 269 API to apply new upgraded @return tag. Fuller use could be made to DRY-out the API on subsequent passes. If I was writing the spec for this API from scratch, I'd incorporate the new facility to being with.

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

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

From darcy at openjdk.java.net  Wed Dec  9 02:34:33 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 9 Dec 2020 02:34:33 GMT
Subject: RFR: 8256917: Use combo @returns tag in java.compiler javadoc
In-Reply-To: <0dNhGAxfKjJL-BPiRhU2hy3Qd3vCkkFED_lQGc-C4mg=.fd7737b3-133e-490d-9b04-40dc837ae853@github.com>
References: <u6jENcml_43Y96kICsJ7LHcX3MN6ckibw8CbGy03g74=.ad69997b-3fc9-46a6-84bd-f2d690c7d45b@github.com>
 <0dNhGAxfKjJL-BPiRhU2hy3Qd3vCkkFED_lQGc-C4mg=.fd7737b3-133e-490d-9b04-40dc837ae853@github.com>
Message-ID: <gSDp_D2gWyJ_FJwdqFeO2ToxklvRwdvHtygcIqs-83k=.bfaf36b8-b779-4bf1-a858-c6aeec2e4a5f@github.com>

On Wed, 9 Dec 2020 02:11:45 GMT, Iris Clark <iris at openjdk.org> wrote:

> 
> 
> Straightforward. I see a few minor differences (e.g. "otherwise returns X" -> "otherwise X"), but nothing significant.

Yes; I didn't limit my pass over the API to cases where there was strict duplication, near duplication was fair game too :-) From an offline specdiff, there weren't any unexpected changes and most of the individual code diffs didn't lead to spec diffs.

> Fantastic use of the new @returns tag. I look forward to seeing it used across the JDK.

Kudos to @jonathan-gibbons and the javadoc team for getting this feature in!

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

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

From darcy at openjdk.java.net  Wed Dec  9 02:40:34 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 9 Dec 2020 02:40:34 GMT
Subject: Integrated: 8256917: Use combo @returns tag in java.compiler javadoc
In-Reply-To: <u6jENcml_43Y96kICsJ7LHcX3MN6ckibw8CbGy03g74=.ad69997b-3fc9-46a6-84bd-f2d690c7d45b@github.com>
References: <u6jENcml_43Y96kICsJ7LHcX3MN6ckibw8CbGy03g74=.ad69997b-3fc9-46a6-84bd-f2d690c7d45b@github.com>
Message-ID: <a7X73sA7FAufgS9Ijrkg0fM0KRAIq7ZAHdxTlHb76to=.c87398b4-4a16-4d49-af75-dfaa9294fa9c@github.com>

On Wed, 9 Dec 2020 01:44:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Take advantage of upgraded dual-use @return tag.

This pull request has now been integrated.

Changeset: 2a62d5d3
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2a62d5d3
Stats:     331 lines in 33 files changed: 2 ins; 170 del; 159 mod

8256917: Use combo @returns tag in java.compiler javadoc

Reviewed-by: jjg, iris

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

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

From vromero at openjdk.java.net  Wed Dec  9 06:38:33 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 9 Dec 2020 06:38:33 GMT
Subject: RFR: 8254023: A module declaration is not allowed to be a target
 of an annotation that lacks an @Target meta-annotation
In-Reply-To: <tBB2q0ATDEr8k86St14cqLVTAwy2CH34WolOWfPH1bw=.e9a456ad-28c8-4e36-9eb4-62024a96c0e4@github.com>
References: <wFdu9AyyNU2SB0nWx9mq_2syF2XyQIB0z6Rmc-r1fNc=.369439d1-385e-4fd1-aac1-72e48ac246e8@github.com>
 <pqSfmocPi4AJGQJEJl4j6UgITEL0f62TKSVpxwOer6w=.49e74a9b-ecb0-4a13-9dfc-93c27fd5149a@github.com>
 <5_HZhCK8rd2yWcf4XzGa_N50I1Xl3CMmUXSugfoJIUk=.379b61e3-e4a3-4509-ac7b-940a25ae4609@github.com>
 <6VDsNZKAYnkmm_YsLRjClBhqPMPPqy4d3TrWLcElkOU=.3f9b9d49-4e49-4574-a07c-6f72acefcfd2@github.com>
 <tBB2q0ATDEr8k86St14cqLVTAwy2CH34WolOWfPH1bw=.e9a456ad-28c8-4e36-9eb4-62024a96c0e4@github.com>
Message-ID: <55-uvNq2QGWKbTD3uVotqaRdbInO5Ih0L462CR7cnGc=.4a2912dd-6868-4290-9e39-2c5f50cf4ca2@github.com>

On Mon, 7 Dec 2020 15:51:59 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>>> Short term (Java 16) it makes sense to fix https://bugs.openjdk.java.net/browse/JDK-8254023 given that both competing specs agree for this case, it is a small fix, and externally found.
>>>
>>>For Java 17 we should align both specs and the reference implementation one way or another.
>> 
>> @jbf According to your comments, I revise my code to only fix JDK-8254023.
>> The rest of the work, ambiguity of the specifications, will be clarified and fixed in Java 17.
>> Thank you for taking the time to review.
>
> the change looks good but I'm surprised that no other tests are failing and need changes, in particular tests like:  `test/langtools/tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java`

> @vicente-romero-oracle It is difficult to identify which test should be changed, because all the tests passed. As you said, the `TargetAnnoCombo.java` maybe need to be changed. I want to revise it now. Should I do it?

sure please, I think that you should not only check that that test passes but also modify it, explicitly adding cases for the MODULE target. As a general comment this change is simple but the implications are not. I think the patch needs to add more tests. We also need to test that annotation processors can `see` the annotation applied to modules, etc.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Wed Dec  9 08:04:46 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Wed, 9 Dec 2020 08:04:46 GMT
Subject: RFR: 8231622: SuppressWarning("serial") ignored on field
 serialVersionUID [v4]
In-Reply-To: <_2Z8RhLQo1F6ddk2cZS5J_hoRMPLCe5ssVMeyyscFnc=.d267dddd-12d6-4968-a32d-6bd3510daf45@github.com>
References: <_2Z8RhLQo1F6ddk2cZS5J_hoRMPLCe5ssVMeyyscFnc=.d267dddd-12d6-4968-a32d-6bd3510daf45@github.com>
Message-ID: <pAZwuCZyGdGLQ1Hk165sxorpi-S4qq2LDutt2ZUSnvM=.c2c59d4d-d830-45f9-803d-10e2b5cd5cb9@github.com>

> Hi all,
> 
> Currently, a warning is generated when compiling the following code by using the option `-Xlint`.
> 
> import java.io.Serializable;
> class B implements Serializable {
>     @SuppressWarnings("serial")
>     private static final byte serialVersionUID = 5;
> }
> 
> output:
> B.java:4: warning: [serial] serialVersionUID must be of type long in class B
>     private static final byte serialVersionUID = 5;
>                               ^
> 1 warning
> 
> The annotation `@SuppressWarnings("serial")` on  field serialVersionUID is ignored by the compiler.
> This patch fixes it and adds some tests.
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Use method ToolBox.checkEqual

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1626/files
  - new: https://git.openjdk.java.net/jdk/pull/1626/files/752ccba4..8714ccfb

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

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Wed Dec  9 08:04:49 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Wed, 9 Dec 2020 08:04:49 GMT
Subject: RFR: 8231622: SuppressWarning("serial") ignored on field
 serialVersionUID [v3]
In-Reply-To: <fGpVUylnqbNBsDy0lblp7pIv5_WvKyoCCdLSPKgOl3Y=.984a0612-5e9f-420c-bf17-6b598b321532@github.com>
References: <_2Z8RhLQo1F6ddk2cZS5J_hoRMPLCe5ssVMeyyscFnc=.d267dddd-12d6-4968-a32d-6bd3510daf45@github.com>
 <dLH3TZ0frTK_o5WhhPqxBbc7HfIqE81WK4JJuAZFURI=.52b74fab-d793-4f6b-b9cd-7a4de6d23f0b@github.com>
 <fGpVUylnqbNBsDy0lblp7pIv5_WvKyoCCdLSPKgOl3Y=.984a0612-5e9f-420c-bf17-6b598b321532@github.com>
Message-ID: <4I-GEhPV6gPy6SXDfqbZNCq1qmmixvQv1Wo2KO1QwC4=.4b205641-24e2-4cb2-b33e-73d7104d498b@github.com>

On Tue, 8 Dec 2020 17:30:53 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Guoxiong Li 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 four additional commits since the last revision:
>> 
>>  - Revise tests by using library toolbox.
>>  - Merge remote-tracking branch 'origin' into JDK-8231622
>>  - Revise test cases. Remove legal header and add /nodynamiccopyright/
>>  - 8231622: SuppressWarning(serial) ignored on field serialVersionUID
>
> test/langtools/tools/javac/T8231622/T8231622.java line 79:
> 
>> 77:         if (!Objects.equals(output, expected)) {
>> 78:             throw new AssertionError("incorrect output\nactual=" + output + "\nexpected=" + expected);
>> 79:         }
> 
> ToolBox provides `checkEquals` which provides a more detailed error message in the case of a difference.

Thank you for the suggestion. I fixed it.

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

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

From ihse at openjdk.java.net  Wed Dec  9 13:32:43 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 9 Dec 2020 13:32:43 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v12]
In-Reply-To: <mCFx_-zaZljumWnBwZfRwVqIs2zBHbQXMec4CBaQKS8=.f75babcd-333b-427d-9152-6f386736bb7f@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <mCFx_-zaZljumWnBwZfRwVqIs2zBHbQXMec4CBaQKS8=.f75babcd-333b-427d-9152-6f386736bb7f@github.com>
Message-ID: <k1SYjoM2awbCbJ9aK3_biTQRgLTIa62VlyOOqi1-IHQ=.c33493b3-4c7e-409e-b02d-13cdc467d71f@github.com>

On Tue, 8 Dec 2020 19:35:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
>> 
>> The notable changes are:
>> 
>>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>>  
>>  Please also see the CSR [6] for more information.
>>  
>>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 55 commits:
> 
>  - Merging recent master changes into JDK-8250768
>  - Fixing navigator for the PREVIEW page.
>  - Fixing typo.
>  - Removing obsolette @PreviewFeature.
>  - Merging master into JDK-8250768
>  - Removing unnecessary property keys.
>  - Cleanup - removing unnecessary code.
>  - Merging master into JDK-8250768-dev4
>  - Reflecting review comments.
>  - Removing trailing whitespace.
>  - ... and 45 more: https://git.openjdk.java.net/jdk/compare/044616bd...0c1c4d57

Build changes still good.

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

Marked as reviewed by ihse (Reviewer).

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

From jlahoda at openjdk.java.net  Wed Dec  9 13:40:54 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 9 Dec 2020 13:40:54 GMT
Subject: RFR: 8229862: NPE in
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:570) [v2]
In-Reply-To: <4X4uxFy-z0Vn9VBKilwfkDUWwt9lPnhdX9km7U5Oqi4=.ec9b59d3-b282-47cc-9ce3-846a072f08f6@github.com>
References: <4X4uxFy-z0Vn9VBKilwfkDUWwt9lPnhdX9km7U5Oqi4=.ec9b59d3-b282-47cc-9ce3-846a072f08f6@github.com>
Message-ID: <PecxiabWUAYOyPphQOKUqPeBRFhKUwx-BwUHHtqzwW8=.e515b53a-db82-441e-aaac-56d1dcec13e8@github.com>

> Based on Bernard's code from:
> http://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015225.html
> 
> Capturing anonymous classes inside lambdas may fail to compile, because:
> -the captured variables are not detected correctly, because `LambdaToMethod...captureLocalClassDefs` needs to find the AST node for the given `ClassSymbol`, but it has not yet been added into the `localClassDefs`. The proposed solution is to re-order the tasks done for JCNewClass, and call the super implementation sooner. This will enter the `ClassSymbol` and corresponding AST node into `localClassDefs` before the capture variables detection.
> -inside the anonymous class definition, some references to the captured variables are replaced using a map that maps captured variables for lambdas (`lambdaTranslationMap`) - but inside the anonymous class, there the captured variables should be mapped using the anonymous class' map/proxies (to fields). The proposed solution is to clear `lambdaTranslationMap` before processing the anonymous class body.

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

  Correcting copyright year.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1221/files
  - new: https://git.openjdk.java.net/jdk/pull/1221/files/288dac25..0f8415e1

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

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

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

From ihse at openjdk.java.net  Wed Dec  9 13:46:39 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 9 Dec 2020 13:46:39 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v6]
In-Reply-To: <2l-iK2j0yRtpmRF_vpBdI9CYFmWeOdBG7ZvM2GyhPp4=.611ca7ee-4de0-4168-9ec8-8784f921de75@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
 <2l-iK2j0yRtpmRF_vpBdI9CYFmWeOdBG7ZvM2GyhPp4=.611ca7ee-4de0-4168-9ec8-8784f921de75@github.com>
Message-ID: <4lA_pBO9zyK3YLajvxRTMaSpzXaTmeieeakdjmoRx_0=.1dbcf13e-809f-432b-ad71-8b9bd9afb9d7@github.com>

On Tue, 8 Dec 2020 23:23:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Start of JDK 17 updates.
>
> Joe Darcy 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 14 additional commits since the last revision:
> 
>  - Get in JEP 390 changes.
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'master' into JDK-8257450
>  - Update symbol files for JDK 16b27.
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'master' into JDK-8257450
>  - Update tests.
>  - Merge branch 'master' into JDK-8257450
>  - Merge branch 'JDK-8257450' of https://github.com/jddarcy/jdk into JDK-8257450
>  - ... and 4 more: https://git.openjdk.java.net/jdk/compare/5c27251d...57ba7b64

Build changes (or should I say "change"?) looks good!

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

Marked as reviewed by ihse (Reviewer).

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

From jlahoda at openjdk.java.net  Wed Dec  9 15:10:07 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 9 Dec 2020 15:10:07 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v6]
In-Reply-To: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
Message-ID: <0GbDxAutpYeJtWyAb4zDfywKH5y0Nur6zkOLqfCUTlA=.e522e1b8-cdda-4598-9129-a1935bccd276@github.com>

> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
> -updating and moving tests into test/langtools, so that it is easier to run them.
> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
> -fixing the -Xprint annotation processor to print record component annotations.
> 
> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.

Jan Lahoda 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 13 additional commits since the last revision:

 - Need to open a few packages for the test.
 - Merge branch 'master' into JDK-8256950
 - Blank lines do not count for the text block indentation, removing them.
 - Reflecting review comments.
 - Fixing tests on Windows - normalizing line endings.
 - Merge branch 'JDK-8256950' of https://github.com/lahodaj/jdk into JDK-8256950
 - Update CreateSymbolsTest.java
 - CreateSymbols should support records with no components.
 - Cleaning TODO.
 - Cleaning TODO.
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/51dfede0...08d7a106

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1480/files
  - new: https://git.openjdk.java.net/jdk/pull/1480/files/3aaaf28c..08d7a106

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=04-05

  Stats: 41234 lines in 1081 files changed: 28666 ins; 7705 del; 4863 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1480.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1480/head:pull/1480

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

From jlahoda at openjdk.java.net  Wed Dec  9 15:10:08 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 9 Dec 2020 15:10:08 GMT
Subject: Integrated: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols
In-Reply-To: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
Message-ID: <dywHI85TUvu9EFIXRFiv1ptu1RbndCyrSosd5E1zkMU=.1dc8e16c-f1c8-4ff2-9097-4bfa3dc9664a@github.com>

On Fri, 27 Nov 2020 13:21:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
> -updating and moving tests into test/langtools, so that it is easier to run them.
> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
> -fixing the -Xprint annotation processor to print record component annotations.
> 
> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.

This pull request has now been integrated.

Changeset: 6eff9315
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6eff9315
Stats:     1961 lines in 12 files changed: 1198 ins; 745 del; 18 mod

8256950: Add record attribute support to symbol generator CreateSymbols

Reviewed-by: jjg, chegar

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

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

From jlahoda at openjdk.java.net  Wed Dec  9 16:52:36 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 9 Dec 2020 16:52:36 GMT
Subject: Integrated: 8229862: NPE in
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:570)
In-Reply-To: <4X4uxFy-z0Vn9VBKilwfkDUWwt9lPnhdX9km7U5Oqi4=.ec9b59d3-b282-47cc-9ce3-846a072f08f6@github.com>
References: <4X4uxFy-z0Vn9VBKilwfkDUWwt9lPnhdX9km7U5Oqi4=.ec9b59d3-b282-47cc-9ce3-846a072f08f6@github.com>
Message-ID: <yFfEQdh8WoAXYbF7lceJhvI-vjs1Y9bjAVG6CihZKeo=.124443d4-0efa-416d-a7f9-8f63e4b94603@github.com>

On Mon, 16 Nov 2020 10:32:00 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Based on Bernard's code from:
> http://mail.openjdk.java.net/pipermail/compiler-dev/2020-October/015225.html
> 
> Capturing anonymous classes inside lambdas may fail to compile, because:
> -the captured variables are not detected correctly, because `LambdaToMethod...captureLocalClassDefs` needs to find the AST node for the given `ClassSymbol`, but it has not yet been added into the `localClassDefs`. The proposed solution is to re-order the tasks done for JCNewClass, and call the super implementation sooner. This will enter the `ClassSymbol` and corresponding AST node into `localClassDefs` before the capture variables detection.
> -inside the anonymous class definition, some references to the captured variables are replaced using a map that maps captured variables for lambdas (`lambdaTranslationMap`) - but inside the anonymous class, there the captured variables should be mapped using the anonymous class' map/proxies (to fields). The proposed solution is to clear `lambdaTranslationMap` before processing the anonymous class body.

This pull request has now been integrated.

Changeset: bd22aa5e
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bd22aa5e
Stats:     64 lines in 3 files changed: 62 ins; 1 del; 1 mod

8229862: NPE in jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:570)

Co-authored-by: Bernard Blaser <bsrbnd at openjdk.org>
Reviewed-by: vromero

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

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

From hseigel at openjdk.java.net  Wed Dec  9 19:11:35 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Wed, 9 Dec 2020 19:11:35 GMT
Subject: Integrated: 8256867: Classes with empty PermittedSubclasses attribute
 cannot be extended
In-Reply-To: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
References: <JvKH3f2s4UFEGo-aOhbwaurpmxC4lwP5iwpnbuZH-vo=.15d02733-ff3f-429e-adcb-3d212f658005@github.com>
Message-ID: <IZGysqapKuO-Ev_pUIFG4rMKvDYPTePCbyal1UwahQY=.427fdd0b-ef25-4cdd-a4d0-e85c29fc0c9e@github.com>

On Mon, 7 Dec 2020 19:51:38 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this fix for JDK-8256867.  This change no longer throws a ClassFormatError exception when loading a class whose PermittedSubclasses attribute is empty (contains no classes).  Instead, the class is treated as a sealed class which cannot be extended nor implemented.  This new behavior conforms to the JVM Spec.
> 
> This change required changing Class.permittedSubclasses() to return an empty array for classes with empty PermittedSubclasses attributes, and to return null for non-sealed classes.
> 
> This fix was tested with Mach5 tiers 1-2 on Linux, MacOS, and Windows, and tiers 3-5 on Linux x64.
> 
> Thanks, Harold

This pull request has now been integrated.

Changeset: d33a689b
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d33a689b
Stats:     167 lines in 8 files changed: 106 ins; 13 del; 48 mod

8256867: Classes with empty PermittedSubclasses attribute cannot be extended

Reviewed-by: lfoltan, mchung, jlahoda, chegar

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

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

From github.com+741251+turbanoff at openjdk.java.net  Wed Dec  9 19:23:33 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 9 Dec 2020 19:23:33 GMT
Subject: Integrated: 6882207: Convert javap to use diamond operator internally
In-Reply-To: <B_3aVOV1mWiHfgxninu81FWTmgN9dXzckXZb9rTcDzQ=.b7aa8fd0-e92b-408b-a077-4c1a0f6f504e@github.com>
References: <B_3aVOV1mWiHfgxninu81FWTmgN9dXzckXZb9rTcDzQ=.b7aa8fd0-e92b-408b-a077-4c1a0f6f504e@github.com>
Message-ID: <sWQPVdkXp2ItKrttfIAAsVjKHLsdDZazIsXIg34T_nE=.7ad636dd-9a3c-4f25-b375-472406abfef6@github.com>

On Mon, 7 Dec 2020 20:30:07 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 6882207: Convert javap to use diamond operator internally

This pull request has now been integrated.

Changeset: 30de320c
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/30de320c
Stats:     7 lines in 3 files changed: 0 ins; 0 del; 7 mod

6882207: Convert javap to use diamond operator internally

Reviewed-by: jjg

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

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

From jjg at openjdk.java.net  Wed Dec  9 19:54:35 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 9 Dec 2020 19:54:35 GMT
Subject: RFR: 8245956: JavaCompiler still uses File API instead of Path
 API in a specific case [v2]
In-Reply-To: <jGoVUBqU4x4aPIkZ2VfuPrrsBrdZFbl20VvSE9fmsX4=.ad948eef-ea71-469b-a2f4-3d28aab5bb04@github.com>
References: <dQCLUalaPhBxjTKrvGIY6c4d9m5HBRQfRu0QuoMUokM=.de840fae-cf05-4f95-9cc3-edf7646046ed@github.com>
 <jGoVUBqU4x4aPIkZ2VfuPrrsBrdZFbl20VvSE9fmsX4=.ad948eef-ea71-469b-a2f4-3d28aab5bb04@github.com>
Message-ID: <RYa3yDh8Y72qUz7dVPct2hGMxeghWyaalNibRVG-gYU=.950f462b-d143-47dc-a6c2-26a73f818d17@github.com>

On Tue, 8 Dec 2020 01:45:29 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi all,
>> 
>> `JavacFileManager.getClassLoader` uses `getLocation` which causes exception in some situations.
>> This patch uses `getLocationAsPaths` instead of `getLocation` to solve it.
>> Thanks you for taking the time to review.
>> 
>> Best Regards.
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename variable. Revise comment. Add print statement after the method getClassLoader.

Marked as reviewed by jjg (Reviewer).

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Wed Dec  9 21:12:38 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Wed, 9 Dec 2020 21:12:38 GMT
Subject: Integrated: 8245956: JavaCompiler still uses File API instead of Path
 API in a specific case
In-Reply-To: <dQCLUalaPhBxjTKrvGIY6c4d9m5HBRQfRu0QuoMUokM=.de840fae-cf05-4f95-9cc3-edf7646046ed@github.com>
References: <dQCLUalaPhBxjTKrvGIY6c4d9m5HBRQfRu0QuoMUokM=.de840fae-cf05-4f95-9cc3-edf7646046ed@github.com>
Message-ID: <sRgcvHJGHLn9kbzGPGT2NuX75LPB6cvcGm47wbPmmTY=.7a171aa2-fd0b-4278-a611-58147319ddfe@github.com>

On Wed, 2 Dec 2020 05:10:12 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> `JavacFileManager.getClassLoader` uses `getLocation` which causes exception in some situations.
> This patch uses `getLocationAsPaths` instead of `getLocation` to solve it.
> Thanks you for taking the time to review.
> 
> Best Regards.

This pull request has now been integrated.

Changeset: 46c9a860
Author:    Guoxiong Li <lgxbslgx at gmail.com>
Committer: Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/46c9a860
Stats:     71 lines in 2 files changed: 67 ins; 0 del; 4 mod

8245956: JavaCompiler still uses File API instead of Path API in a specific case

Reviewed-by: jjg

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

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

From weijun at openjdk.java.net  Thu Dec 10 00:46:35 2020
From: weijun at openjdk.java.net (Weijun Wang)
Date: Thu, 10 Dec 2020 00:46:35 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
Message-ID: <Afb0e1sUCYbYLxrSDp5uPPHBTqhH7PY3tzrdP5JSB9w=.0a7838a0-71c3-4ac5-aa64-7af685f2373e@github.com>

On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [ ] java.base
>> - [ ] java.desktop
>> - [x] jdk.compiler
>> - [ ] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move to share/data, and move jdwp.spec to java.se

The security-related part (cacerts, blacklisted.certs, publicsuffxlist) looks fine to me.

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

Marked as reviewed by weijun (Reviewer).

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

From darcy at openjdk.java.net  Thu Dec 10 01:09:44 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 10 Dec 2020 01:09:44 GMT
Subject: RFR: 8257638: Update usage of "type" terminology in javax.lang.model
Message-ID: <8Hb0NZustPk1ivP7aBRpr8PHzHlPNOckYQOP62hMt5Y=.9399a64b-fd29-459f-8770-d31414cfb5cf@github.com>

First pass at updating javax.lang.model's usage of the word "type" to correspond to changes in usage of "type" being made in JLS.

The wording in annotated construct and related functionality may need another pass.

Updating @jls tags to renamed JLS sections will be done under a different bug id.

Paragraphs *not* reflowed initially to easy reviewing. Paragraph will be reflowed and copyright year updated before a push is done.

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

Commit messages:
 - Address comments from Alex Buckley.
 - Address code review feedback from jjg.
 - First cut at updating javax.lang.model to revised "type" terminology in JLS.

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

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

From jjg at openjdk.java.net  Thu Dec 10 01:09:45 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 10 Dec 2020 01:09:45 GMT
Subject: RFR: 8257638: Update usage of "type" terminology in
 javax.lang.model
In-Reply-To: <8Hb0NZustPk1ivP7aBRpr8PHzHlPNOckYQOP62hMt5Y=.9399a64b-fd29-459f-8770-d31414cfb5cf@github.com>
References: <8Hb0NZustPk1ivP7aBRpr8PHzHlPNOckYQOP62hMt5Y=.9399a64b-fd29-459f-8770-d31414cfb5cf@github.com>
Message-ID: <zFMaR-E1TJhTj7IpKhSb737nCPQsm_Qs50EVpT_smug=.9cc2bd78-e741-4f5e-8ca4-0cbd017ed765@github.com>

On Thu, 10 Dec 2020 00:04:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> First pass at updating javax.lang.model's usage of the word "type" to correspond to changes in usage of "type" being made in JLS.
> 
> The wording in annotated construct and related functionality may need another pass.
> 
> Updating @jls tags to renamed JLS sections will be done under a different bug id.
> 
> Paragraphs *not* reflowed initially to easy reviewing. Paragraph will be reflowed and copyright year updated before a push is done.

There's an instance in TypeElement.java where the plurality of the replacement is incorrect.

Other comments are mostly incidental/minor.

src/java.compiler/share/classes/javax/annotation/processing/Filer.java line 69:

> 67:  * allow the <em>originating elements</em> to be provided as hints to
> 68:  * the tool infrastructure to better manage dependencies.  The
> 69:  * originating elements are the classes or interfaces or packages (representing {@code

would maybe be slightly better as "classes, interfaces or packages"

src/java.compiler/share/classes/javax/annotation/processing/Processor.java line 121:

> 119: 
> 120:  * For this purpose, a package element is <em>not</em> considered to
> 121:  * enclose the top-level classes and interfaces within that package. (A root element

`enclose` would be better as `encloses`

src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java line 35:

> 33:  * Represents a class or interface program element.  Provides access
> 34:  * to information about the class or interface and its members.  Note that an enum
> 35:  * class and a record class are kinds of classes and an annotation interface is a kind of

The sentence beginning "Note that..." is kinda redundant now, but not wrong.

src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java line 130:

> 128:      * For example, the fully qualified name of the interface
> 129:      * {@code java.util.Set<E>} is "{@code java.util.Set}".
> 130:      * Nested class and interface use "{@code .}" as a separator, as in

Should be "classes and interfaces"

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

Changes requested by jjg (Reviewer).

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

From darcy at openjdk.java.net  Thu Dec 10 01:09:45 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 10 Dec 2020 01:09:45 GMT
Subject: RFR: 8257638: Update usage of "type" terminology in
 javax.lang.model
In-Reply-To: <8Hb0NZustPk1ivP7aBRpr8PHzHlPNOckYQOP62hMt5Y=.9399a64b-fd29-459f-8770-d31414cfb5cf@github.com>
References: <8Hb0NZustPk1ivP7aBRpr8PHzHlPNOckYQOP62hMt5Y=.9399a64b-fd29-459f-8770-d31414cfb5cf@github.com>
Message-ID: <EVoiYo4RJMM29zI6x334ywKwbEg1fuVyvsXlENfLM7I=.38a4cff9-b774-4660-927c-5ae043624ce4@github.com>

On Thu, 10 Dec 2020 00:04:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> First pass at updating javax.lang.model's usage of the word "type" to correspond to changes in usage of "type" being made in JLS.
> 
> The wording in annotated construct and related functionality may need another pass.
> 
> Updating @jls tags to renamed JLS sections will be done under a different bug id.
> 
> Paragraphs *not* reflowed initially to easy reviewing. Paragraph will be reflowed and copyright year updated before a push is done.

First pass at updating javax.lang.model's usage of the word "type" to correspond to changes in usage of "type" being made in JLS.

The wording in annotated construct and related functionality may need another pass.

Updating @jls tags to renamed JLS sections will be done under a different bug id.

Paragraphs not reflowed initially to easy reviewing. Paragraph will be reflowed and copyright year updated before a push is done.

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

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

From darcy at openjdk.java.net  Thu Dec 10 01:09:46 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 10 Dec 2020 01:09:46 GMT
Subject: RFR: 8257638: Update usage of "type" terminology in
 javax.lang.model
In-Reply-To: <zFMaR-E1TJhTj7IpKhSb737nCPQsm_Qs50EVpT_smug=.9cc2bd78-e741-4f5e-8ca4-0cbd017ed765@github.com>
References: <8Hb0NZustPk1ivP7aBRpr8PHzHlPNOckYQOP62hMt5Y=.9399a64b-fd29-459f-8770-d31414cfb5cf@github.com>
 <zFMaR-E1TJhTj7IpKhSb737nCPQsm_Qs50EVpT_smug=.9cc2bd78-e741-4f5e-8ca4-0cbd017ed765@github.com>
Message-ID: <0q-JWrLLs0bwG6PtuxVbJz-OGBpcILSnfu3w-rRw9tg=.35b13dcc-df99-4eb5-b477-1b776d576926@github.com>

On Thu, 10 Dec 2020 00:24:55 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> First pass at updating javax.lang.model's usage of the word "type" to correspond to changes in usage of "type" being made in JLS.
>> 
>> The wording in annotated construct and related functionality may need another pass.
>> 
>> Updating @jls tags to renamed JLS sections will be done under a different bug id.
>> 
>> Paragraphs *not* reflowed initially to easy reviewing. Paragraph will be reflowed and copyright year updated before a push is done.
>
> src/java.compiler/share/classes/javax/annotation/processing/Filer.java line 69:
> 
>> 67:  * allow the <em>originating elements</em> to be provided as hints to
>> 68:  * the tool infrastructure to better manage dependencies.  The
>> 69:  * originating elements are the classes or interfaces or packages (representing {@code
> 
> would maybe be slightly better as "classes, interfaces or packages"

Update in subsequent commit.

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

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

From darcy at openjdk.java.net  Thu Dec 10 01:16:37 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 10 Dec 2020 01:16:37 GMT
Subject: RFR: 8257638: Update usage of "type" terminology in
 javax.lang.model
In-Reply-To: <zFMaR-E1TJhTj7IpKhSb737nCPQsm_Qs50EVpT_smug=.9cc2bd78-e741-4f5e-8ca4-0cbd017ed765@github.com>
References: <8Hb0NZustPk1ivP7aBRpr8PHzHlPNOckYQOP62hMt5Y=.9399a64b-fd29-459f-8770-d31414cfb5cf@github.com>
 <zFMaR-E1TJhTj7IpKhSb737nCPQsm_Qs50EVpT_smug=.9cc2bd78-e741-4f5e-8ca4-0cbd017ed765@github.com>
Message-ID: <HqVnxkiD90AIsBjOpdSKeFygIxQPrygTjLK3BBrdolQ=.a043191e-731b-4de6-9c07-dffd2cffd794@github.com>

On Thu, 10 Dec 2020 00:27:32 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> First pass at updating javax.lang.model's usage of the word "type" to correspond to changes in usage of "type" being made in JLS.
>> 
>> The wording in annotated construct and related functionality may need another pass.
>> 
>> Updating @jls tags to renamed JLS sections will be done under a different bug id.
>> 
>> Paragraphs *not* reflowed initially to easy reviewing. Paragraph will be reflowed and copyright year updated before a push is done.
>
> src/java.compiler/share/classes/javax/annotation/processing/Processor.java line 121:
> 
>> 119: 
>> 120:  * For this purpose, a package element is <em>not</em> considered to
>> 121:  * enclose the top-level classes and interfaces within that package. (A root element
> 
> `enclose` would be better as `encloses`

"Package element" is singular so "enclose" is proper, right?

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

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

From jjg at openjdk.java.net  Thu Dec 10 01:21:58 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 10 Dec 2020 01:21:58 GMT
Subject: RFR: 8257638: Update usage of "type" terminology in
 javax.lang.model
In-Reply-To: <HqVnxkiD90AIsBjOpdSKeFygIxQPrygTjLK3BBrdolQ=.a043191e-731b-4de6-9c07-dffd2cffd794@github.com>
References: <8Hb0NZustPk1ivP7aBRpr8PHzHlPNOckYQOP62hMt5Y=.9399a64b-fd29-459f-8770-d31414cfb5cf@github.com>
 <zFMaR-E1TJhTj7IpKhSb737nCPQsm_Qs50EVpT_smug=.9cc2bd78-e741-4f5e-8ca4-0cbd017ed765@github.com>
 <HqVnxkiD90AIsBjOpdSKeFygIxQPrygTjLK3BBrdolQ=.a043191e-731b-4de6-9c07-dffd2cffd794@github.com>
Message-ID: <t-AGdjFnygOm5t8cloZtHw6XKaRr5mS8EifjmSOogv4=.149ba8df-3a48-421f-9d10-2589032c2c97@github.com>

On Thu, 10 Dec 2020 01:13:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.compiler/share/classes/javax/annotation/processing/Processor.java line 121:
>> 
>>> 119: 
>>> 120:  * For this purpose, a package element is <em>not</em> considered to
>>> 121:  * enclose the top-level classes and interfaces within that package. (A root element
>> 
>> `enclose` would be better as `encloses`
>
> "Package element" is singular so "enclose" is proper, right?

Ooops, mea culpa; sorry

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

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

From jjg at openjdk.java.net  Thu Dec 10 01:34:33 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 10 Dec 2020 01:34:33 GMT
Subject: RFR: 8257638: Update usage of "type" terminology in
 javax.lang.model
In-Reply-To: <8Hb0NZustPk1ivP7aBRpr8PHzHlPNOckYQOP62hMt5Y=.9399a64b-fd29-459f-8770-d31414cfb5cf@github.com>
References: <8Hb0NZustPk1ivP7aBRpr8PHzHlPNOckYQOP62hMt5Y=.9399a64b-fd29-459f-8770-d31414cfb5cf@github.com>
Message-ID: <AIqFA-lmrM8Ag2UnIOku7BL-R_9o5wvl1nJthgk58s4=.fcaf5c97-5e3c-4b99-a58e-0c9b9766b764@github.com>

On Thu, 10 Dec 2020 00:04:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> First pass at updating javax.lang.model's usage of the word "type" to correspond to changes in usage of "type" being made in JLS.
> 
> The wording in annotated construct and related functionality may need another pass.
> 
> Updating @jls tags to renamed JLS sections will be done under a different bug id.
> 
> Paragraphs *not* reflowed initially to easy reviewing. Paragraph will be reflowed and copyright year updated before a push is done.

Marked as reviewed by jjg (Reviewer).

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

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

From darcy at openjdk.java.net  Thu Dec 10 02:58:55 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 10 Dec 2020 02:58:55 GMT
Subject: RFR: 8257638: Update usage of "type" terminology in
 javax.lang.model [v2]
In-Reply-To: <8Hb0NZustPk1ivP7aBRpr8PHzHlPNOckYQOP62hMt5Y=.9399a64b-fd29-459f-8770-d31414cfb5cf@github.com>
References: <8Hb0NZustPk1ivP7aBRpr8PHzHlPNOckYQOP62hMt5Y=.9399a64b-fd29-459f-8770-d31414cfb5cf@github.com>
Message-ID: <ZYSrXKWXqBhR42-TYs1TmMAzCLkigB5ujVvOgYg1pTM=.f70da605-9e91-4e11-af20-9496e6cfa3f1@github.com>

> First pass at updating javax.lang.model's usage of the word "type" to correspond to changes in usage of "type" being made in JLS.
> 
> The wording in annotated construct and related functionality may need another pass.
> 
> Updating @jls tags to renamed JLS sections will be done under a different bug id.
> 
> Paragraphs *not* reflowed initially to easy reviewing. Paragraph will be reflowed and copyright year updated before a push is done.

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

  Reflow paragraphs and update copyright year.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1726/files
  - new: https://git.openjdk.java.net/jdk/pull/1726/files/66e9f45f..6e0a242c

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

  Stats: 112 lines in 11 files changed: 12 ins; 0 del; 100 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1726.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1726/head:pull/1726

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

From darcy at openjdk.java.net  Thu Dec 10 03:02:35 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 10 Dec 2020 03:02:35 GMT
Subject: Integrated: 8257638: Update usage of "type" terminology in
 javax.lang.model
In-Reply-To: <8Hb0NZustPk1ivP7aBRpr8PHzHlPNOckYQOP62hMt5Y=.9399a64b-fd29-459f-8770-d31414cfb5cf@github.com>
References: <8Hb0NZustPk1ivP7aBRpr8PHzHlPNOckYQOP62hMt5Y=.9399a64b-fd29-459f-8770-d31414cfb5cf@github.com>
Message-ID: <lYUkByQks8aNkGA7H7mBZ-1wKmni_e3retjwQQv9OjE=.b355e680-e222-4ecd-89a1-543be7930ae2@github.com>

On Thu, 10 Dec 2020 00:04:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> First pass at updating javax.lang.model's usage of the word "type" to correspond to changes in usage of "type" being made in JLS.
> 
> The wording in annotated construct and related functionality may need another pass.
> 
> Updating @jls tags to renamed JLS sections will be done under a different bug id.
> 
> Paragraphs *not* reflowed initially to easy reviewing. Paragraph will be reflowed and copyright year updated before a push is done.

This pull request has now been integrated.

Changeset: d2f9e31a
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d2f9e31a
Stats:     178 lines in 17 files changed: 12 ins; 0 del; 166 mod

8257638: Update usage of "type" terminology in javax.lang.model

Reviewed-by: jjg

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

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

From darcy at openjdk.java.net  Thu Dec 10 04:42:55 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 10 Dec 2020 04:42:55 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v7]
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <gyDm6VZGnylAP8jy5TSVCMa4ergsCp1q_upz-cnUH7w=.4f679fd0-39de-4964-ba9c-80a5a1983e86@github.com>

> Start of JDK 17 updates.

Joe Darcy 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 17 additional commits since the last revision:

 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Get in JEP 390 changes.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Update symbol files for JDK 16b27.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/bbfda542...766c2c01

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1531/files
  - new: https://git.openjdk.java.net/jdk/pull/1531/files/57ba7b64..766c2c01

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1531&range=05-06

  Stats: 4920 lines in 147 files changed: 3195 ins; 1060 del; 665 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1531.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531

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

From darcy at openjdk.java.net  Thu Dec 10 08:24:56 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 10 Dec 2020 08:24:56 GMT
Subject: RFR: 8257450: Start of release updates for JDK 17 [v8]
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <rn9lVol-HjFN8IltKapVMsNV_2JDkmhYPFFcMORD5k0=.0dd4b179-70dd-4a18-a95b-740305095c0f@github.com>

> Start of JDK 17 updates.

Joe Darcy 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 18 additional commits since the last revision:

 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Get in JEP 390 changes.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - Update symbol files for JDK 16b27.
 - Merge branch 'master' into JDK-8257450
 - Merge branch 'master' into JDK-8257450
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/61f30b72...553d134f

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1531/files
  - new: https://git.openjdk.java.net/jdk/pull/1531/files/766c2c01..553d134f

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

  Stats: 554 lines in 7 files changed: 324 ins; 220 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1531.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1531/head:pull/1531

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Dec 10 13:12:37 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 10 Dec 2020 13:12:37 GMT
Subject: RFR: 8231622: SuppressWarning("serial") ignored on field
 serialVersionUID [v3]
In-Reply-To: <fGpVUylnqbNBsDy0lblp7pIv5_WvKyoCCdLSPKgOl3Y=.984a0612-5e9f-420c-bf17-6b598b321532@github.com>
References: <_2Z8RhLQo1F6ddk2cZS5J_hoRMPLCe5ssVMeyyscFnc=.d267dddd-12d6-4968-a32d-6bd3510daf45@github.com>
 <dLH3TZ0frTK_o5WhhPqxBbc7HfIqE81WK4JJuAZFURI=.52b74fab-d793-4f6b-b9cd-7a4de6d23f0b@github.com>
 <fGpVUylnqbNBsDy0lblp7pIv5_WvKyoCCdLSPKgOl3Y=.984a0612-5e9f-420c-bf17-6b598b321532@github.com>
Message-ID: <R482uaINgecBl-hOR6D3cpH-bp5yBZqjCyh-y75QZfI=.d5702448-3d7f-4982-ae63-25cd4856fe9a@github.com>

On Tue, 8 Dec 2020 17:32:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Guoxiong Li 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 four additional commits since the last revision:
>> 
>>  - Revise tests by using library toolbox.
>>  - Merge remote-tracking branch 'origin' into JDK-8231622
>>  - Revise test cases. Remove legal header and add /nodynamiccopyright/
>>  - 8231622: SuppressWarning(serial) ignored on field serialVersionUID
>
> Nice improvement. You can make it even better in 3 places by using `ToolBox.checkEquals`, which provides more detailed reporting in the case of a difference being found.

> Anyway, I don't think we should continue to discuss the concrete content in this patch.

@jonathan-gibbons I submit a patch[1] to solve the previous bad style tests. We can continue the discussion there.

[1] https://github.com/openjdk/jdk/pull/1732

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

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

From jfranck at openjdk.java.net  Thu Dec 10 13:47:37 2020
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Thu, 10 Dec 2020 13:47:37 GMT
Subject: RFR: 8254023: A module declaration is not allowed to be a target
 of an annotation that lacks an @Target meta-annotation
In-Reply-To: <55-uvNq2QGWKbTD3uVotqaRdbInO5Ih0L462CR7cnGc=.4a2912dd-6868-4290-9e39-2c5f50cf4ca2@github.com>
References: <wFdu9AyyNU2SB0nWx9mq_2syF2XyQIB0z6Rmc-r1fNc=.369439d1-385e-4fd1-aac1-72e48ac246e8@github.com>
 <pqSfmocPi4AJGQJEJl4j6UgITEL0f62TKSVpxwOer6w=.49e74a9b-ecb0-4a13-9dfc-93c27fd5149a@github.com>
 <5_HZhCK8rd2yWcf4XzGa_N50I1Xl3CMmUXSugfoJIUk=.379b61e3-e4a3-4509-ac7b-940a25ae4609@github.com>
 <6VDsNZKAYnkmm_YsLRjClBhqPMPPqy4d3TrWLcElkOU=.3f9b9d49-4e49-4574-a07c-6f72acefcfd2@github.com>
 <tBB2q0ATDEr8k86St14cqLVTAwy2CH34WolOWfPH1bw=.e9a456ad-28c8-4e36-9eb4-62024a96c0e4@github.com>
 <55-uvNq2QGWKbTD3uVotqaRdbInO5Ih0L462CR7cnGc=.4a2912dd-6868-4290-9e39-2c5f50cf4ca2@github.com>
Message-ID: <CMHxOHQvUOHVPAkk0TR1N5pyLFoWN6wlDDX4y-vs5Q8=.b3da3476-d256-4011-afae-f6235bbcee45@github.com>

On Wed, 9 Dec 2020 06:35:56 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> the change looks good but I'm surprised that no other tests are failing and need changes, in particular tests like:  `test/langtools/tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java`
>
>> @vicente-romero-oracle It is difficult to identify which test should be changed, because all the tests passed. As you said, the `TargetAnnoCombo.java` maybe need to be changed. I want to revise it now. Should I do it?
> 
> sure please, I think that you should not only check that that test passes but also modify it, explicitly adding cases for the MODULE target. As a general comment this change is simple but the implications are not. I think the patch needs to add more tests. We also need to test that annotation processors can `see` annotations applied to modules, etc. We also need tests that check that target-less annotations, applied to modules are actually represented as such in the corresponding class file.

Hi,

I don't think TargetAnnoCombo should be updated, at least not for this fix. It is an old hard to understand test that predates modules.

It would be good to do further testing as Vicente writes. I suggest:

1) A test that the module info compiles, you already have this.
2) A test that the class file contains the bytes for the annotation might make sense. As Jon has pointed out in different review threads there is the toolbox, perhaps that could be of use? There are some examples of toolbox tests in  `jdk/test/langtools/tools/javac/modules` though I don't have a good example of one that verifies the contents of the class file. Perhaps @vicente-romero-oracle can point to an example? 
3) There should already be tests that annotation processing can pick up annotations on module declarations, it looks like `jdk/test/langtools/tools/javac/modules/AnnotationProcessing.java` contains some of this. See if you can add a case with an annotation without @Target.

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

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

From jfranck at openjdk.java.net  Thu Dec 10 14:02:38 2020
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Thu, 10 Dec 2020 14:02:38 GMT
Subject: RFR: 8257740: Compiler crash when compiling type annotation on
 multicatch inside lambda
In-Reply-To: <yeW8wp7bMvNPXB4EdURtsvz_uvCtn2Szdcj2vBAgno8=.70964bd5-a6eb-4665-a6c8-2d1b61c1b91d@github.com>
References: <yeW8wp7bMvNPXB4EdURtsvz_uvCtn2Szdcj2vBAgno8=.70964bd5-a6eb-4665-a6c8-2d1b61c1b91d@github.com>
Message-ID: <EXLysAdZEQzfoiI4N8ssFUBhwgRAYNQ2hribywfHaV0=.1a6761cc-3557-4524-9a99-5acab9a8292b@github.com>

On Sun, 6 Dec 2020 08:17:29 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> When translating a lambda expression to method, the method `LambdaToMethod.LambdaAnalyzerPreprocessor.LambdaTranslationContext.translate(final Symbol sym, LambdaSymbolKind skind)` creates new VarSymbol(s) according to the old VarSymbol(s). But this `translate` method doesn't set the field `data`  of the new VarSymbol. Maybe it is because the field `data` is unused in later phase.
> 
> Unfortunately, `com.sun.tools.javac.jvm.Code.fillExceptionParameterPositions` and `com.sun.tools.javac.jvm.Code.fillLocalVarPosition` would use the field `data` if the `data` is `ElementKind.EXCEPTION_PARAMETER`.
> 
> It causes the exception_index won't be set in `fillExceptionParameterPositions`. Later, if the exception_index is used, the compiler will crash with error `java.lang.AssertionError: exception_index is not set`.
> 
> This patch fixes it and adds corresponding test cases.
> In my patch, I only set the field ` data`  if  the `data` is `ElementKind.EXCEPTION_PARAMETER`. Because I don't see another situation that the field `data` would be used.
> 
> Thank your for taking the time to review.
> 
> Best Regards.

test/langtools/tools/javac/T8257740/T8257740_2.java line 42:

> 40:             try {
> 41:                 System.out.println();
> 42:             } catch (@T8257740_2_Anno Exception e) { // multi-catch

This looks like a uni-catch?

test/langtools/tools/javac/T8257740/T8257740_1.java line 27:

> 25:  * @test
> 26:  * @bug 8257740
> 27:  * @summary Compiler crash when compiling type annotation on uni-catch inside lambda

Did you manage to make it crash on a uni-catch as well?

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Dec 10 14:44:35 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 10 Dec 2020 14:44:35 GMT
Subject: RFR: 8257740: Compiler crash when compiling type annotation on
 multicatch inside lambda
In-Reply-To: <EXLysAdZEQzfoiI4N8ssFUBhwgRAYNQ2hribywfHaV0=.1a6761cc-3557-4524-9a99-5acab9a8292b@github.com>
References: <yeW8wp7bMvNPXB4EdURtsvz_uvCtn2Szdcj2vBAgno8=.70964bd5-a6eb-4665-a6c8-2d1b61c1b91d@github.com>
 <EXLysAdZEQzfoiI4N8ssFUBhwgRAYNQ2hribywfHaV0=.1a6761cc-3557-4524-9a99-5acab9a8292b@github.com>
Message-ID: <yJbIyvFyMreow8EBsapbxC-e0gnS6GBGgDvewg3yKww=.4515ef9e-6df0-422f-b02d-0e34dd958887@github.com>

On Thu, 10 Dec 2020 13:59:20 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:

>> Hi all,
>> 
>> When translating a lambda expression to method, the method `LambdaToMethod.LambdaAnalyzerPreprocessor.LambdaTranslationContext.translate(final Symbol sym, LambdaSymbolKind skind)` creates new VarSymbol(s) according to the old VarSymbol(s). But this `translate` method doesn't set the field `data`  of the new VarSymbol. Maybe it is because the field `data` is unused in later phase.
>> 
>> Unfortunately, `com.sun.tools.javac.jvm.Code.fillExceptionParameterPositions` and `com.sun.tools.javac.jvm.Code.fillLocalVarPosition` would use the field `data` if the `data` is `ElementKind.EXCEPTION_PARAMETER`.
>> 
>> It causes the exception_index won't be set in `fillExceptionParameterPositions`. Later, if the exception_index is used, the compiler will crash with error `java.lang.AssertionError: exception_index is not set`.
>> 
>> This patch fixes it and adds corresponding test cases.
>> In my patch, I only set the field ` data`  if  the `data` is `ElementKind.EXCEPTION_PARAMETER`. Because I don't see another situation that the field `data` would be used.
>> 
>> Thank your for taking the time to review.
>> 
>> Best Regards.
>
> test/langtools/tools/javac/T8257740/T8257740_1.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8257740
>> 27:  * @summary Compiler crash when compiling type annotation on uni-catch inside lambda
> 
> Did you manage to make it crash on a uni-catch as well?

I test the uni-catch locally by using this test case. The compiler crashes and the error message is same as multi-catch. But I don't know why the reporter only reproduce it by using multi-catch. My local environment is linux&x86_64.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Dec 10 14:52:40 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 10 Dec 2020 14:52:40 GMT
Subject: RFR: 8257740: Compiler crash when compiling type annotation on
 multicatch inside lambda
In-Reply-To: <EXLysAdZEQzfoiI4N8ssFUBhwgRAYNQ2hribywfHaV0=.1a6761cc-3557-4524-9a99-5acab9a8292b@github.com>
References: <yeW8wp7bMvNPXB4EdURtsvz_uvCtn2Szdcj2vBAgno8=.70964bd5-a6eb-4665-a6c8-2d1b61c1b91d@github.com>
 <EXLysAdZEQzfoiI4N8ssFUBhwgRAYNQ2hribywfHaV0=.1a6761cc-3557-4524-9a99-5acab9a8292b@github.com>
Message-ID: <9pjTFnd8yXi2pZXLQOiLPey-WqmfmhiZJ3vrAl6dL9s=.da27f8f7-e090-4a3f-9882-94e830e6364a@github.com>

On Thu, 10 Dec 2020 13:58:22 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:

>> Hi all,
>> 
>> When translating a lambda expression to method, the method `LambdaToMethod.LambdaAnalyzerPreprocessor.LambdaTranslationContext.translate(final Symbol sym, LambdaSymbolKind skind)` creates new VarSymbol(s) according to the old VarSymbol(s). But this `translate` method doesn't set the field `data`  of the new VarSymbol. Maybe it is because the field `data` is unused in later phase.
>> 
>> Unfortunately, `com.sun.tools.javac.jvm.Code.fillExceptionParameterPositions` and `com.sun.tools.javac.jvm.Code.fillLocalVarPosition` would use the field `data` if the `data` is `ElementKind.EXCEPTION_PARAMETER`.
>> 
>> It causes the exception_index won't be set in `fillExceptionParameterPositions`. Later, if the exception_index is used, the compiler will crash with error `java.lang.AssertionError: exception_index is not set`.
>> 
>> This patch fixes it and adds corresponding test cases.
>> In my patch, I only set the field ` data`  if  the `data` is `ElementKind.EXCEPTION_PARAMETER`. Because I don't see another situation that the field `data` would be used.
>> 
>> Thank your for taking the time to review.
>> 
>> Best Regards.
>
> test/langtools/tools/javac/T8257740/T8257740_2.java line 42:
> 
>> 40:             try {
>> 41:                 System.out.println();
>> 42:             } catch (@T8257740_2_Anno Exception e) { // multi-catch
> 
> This looks like a uni-catch?

Sorry for the mistake. I will fix it later.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Dec 10 15:24:55 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 10 Dec 2020 15:24:55 GMT
Subject: RFR: 8257740: Compiler crash when compiling type annotation on
 multicatch inside lambda [v2]
In-Reply-To: <yeW8wp7bMvNPXB4EdURtsvz_uvCtn2Szdcj2vBAgno8=.70964bd5-a6eb-4665-a6c8-2d1b61c1b91d@github.com>
References: <yeW8wp7bMvNPXB4EdURtsvz_uvCtn2Szdcj2vBAgno8=.70964bd5-a6eb-4665-a6c8-2d1b61c1b91d@github.com>
Message-ID: <Cv072DPh3Vmbi7qcQ_VlQP4M0M9m89TTOQ54rRJgYRs=.07becfa5-cdb2-4e88-b7f7-7c96ff6612da@github.com>

> Hi all,
> 
> When translating a lambda expression to method, the method `LambdaToMethod.LambdaAnalyzerPreprocessor.LambdaTranslationContext.translate(final Symbol sym, LambdaSymbolKind skind)` creates new VarSymbol(s) according to the old VarSymbol(s). But this `translate` method doesn't set the field `data`  of the new VarSymbol. Maybe it is because the field `data` is unused in later phase.
> 
> Unfortunately, `com.sun.tools.javac.jvm.Code.fillExceptionParameterPositions` and `com.sun.tools.javac.jvm.Code.fillLocalVarPosition` would use the field `data` if the `data` is `ElementKind.EXCEPTION_PARAMETER`.
> 
> It causes the exception_index won't be set in `fillExceptionParameterPositions`. Later, if the exception_index is used, the compiler will crash with error `java.lang.AssertionError: exception_index is not set`.
> 
> This patch fixes it and adds corresponding test cases.
> In my patch, I only set the field ` data`  if  the `data` is `ElementKind.EXCEPTION_PARAMETER`. Because I don't see another situation that the field `data` would be used.
> 
> Thank your for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Fix multi-catch test case.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1648/files
  - new: https://git.openjdk.java.net/jdk/pull/1648/files/d10b1d86..6c652343

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

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Dec 10 15:24:55 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 10 Dec 2020 15:24:55 GMT
Subject: RFR: 8257740: Compiler crash when compiling type annotation on
 multicatch inside lambda
In-Reply-To: <yeW8wp7bMvNPXB4EdURtsvz_uvCtn2Szdcj2vBAgno8=.70964bd5-a6eb-4665-a6c8-2d1b61c1b91d@github.com>
References: <yeW8wp7bMvNPXB4EdURtsvz_uvCtn2Szdcj2vBAgno8=.70964bd5-a6eb-4665-a6c8-2d1b61c1b91d@github.com>
Message-ID: <-bneMUmnpKDugd7MSBjJdVEF0lyoRzkk5sKTMNS2rZ4=.e7afbfaf-0327-4c64-ae19-e72d4c471bd0@github.com>

On Sun, 6 Dec 2020 08:17:29 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> When translating a lambda expression to method, the method `LambdaToMethod.LambdaAnalyzerPreprocessor.LambdaTranslationContext.translate(final Symbol sym, LambdaSymbolKind skind)` creates new VarSymbol(s) according to the old VarSymbol(s). But this `translate` method doesn't set the field `data`  of the new VarSymbol. Maybe it is because the field `data` is unused in later phase.
> 
> Unfortunately, `com.sun.tools.javac.jvm.Code.fillExceptionParameterPositions` and `com.sun.tools.javac.jvm.Code.fillLocalVarPosition` would use the field `data` if the `data` is `ElementKind.EXCEPTION_PARAMETER`.
> 
> It causes the exception_index won't be set in `fillExceptionParameterPositions`. Later, if the exception_index is used, the compiler will crash with error `java.lang.AssertionError: exception_index is not set`.
> 
> This patch fixes it and adds corresponding test cases.
> In my patch, I only set the field ` data`  if  the `data` is `ElementKind.EXCEPTION_PARAMETER`. Because I don't see another situation that the field `data` would be used.
> 
> Thank your for taking the time to review.
> 
> Best Regards.

I fix the multi-catch test case. Thank you for taking the time to review.

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

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

From darcy at openjdk.java.net  Thu Dec 10 16:52:13 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 10 Dec 2020 16:52:13 GMT
Subject: Integrated: 8257450: Start of release updates for JDK 17
In-Reply-To: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
References: <Hg36HGGaVClXrX9Djr5Sc9A6LzdbSuLzKWiJ1JtRkTE=.7b4697e9-b0cf-4336-8a27-94c8cc2a514e@github.com>
Message-ID: <wXD3dVj531OGGfdWHNznUhqYjItuoSG7JooTYstwUXs=.36d4a91d-be6d-4132-b815-99e152e9b386@github.com>

On Tue, 1 Dec 2020 06:22:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Start of JDK 17 updates.

This pull request has now been integrated.

Changeset: 6be1f567
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6be1f567
Stats:     7607 lines in 77 files changed: 7548 ins; 0 del; 59 mod

8257450: Start of release updates for JDK 17
8257451: Add SourceVersion.RELEASE_17
8257453: Add source 17 and target 17 to javac

Reviewed-by: dholmes, erikj, iris, mikael, jjg, jlahoda, jwilhelm, mchung, ihse

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

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

From vromero at openjdk.java.net  Thu Dec 10 19:36:56 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 10 Dec 2020 19:36:56 GMT
Subject: RFR: 8254023: A module declaration is not allowed to be a target
 of an annotation that lacks an @Target meta-annotation
In-Reply-To: <CMHxOHQvUOHVPAkk0TR1N5pyLFoWN6wlDDX4y-vs5Q8=.b3da3476-d256-4011-afae-f6235bbcee45@github.com>
References: <wFdu9AyyNU2SB0nWx9mq_2syF2XyQIB0z6Rmc-r1fNc=.369439d1-385e-4fd1-aac1-72e48ac246e8@github.com>
 <pqSfmocPi4AJGQJEJl4j6UgITEL0f62TKSVpxwOer6w=.49e74a9b-ecb0-4a13-9dfc-93c27fd5149a@github.com>
 <5_HZhCK8rd2yWcf4XzGa_N50I1Xl3CMmUXSugfoJIUk=.379b61e3-e4a3-4509-ac7b-940a25ae4609@github.com>
 <6VDsNZKAYnkmm_YsLRjClBhqPMPPqy4d3TrWLcElkOU=.3f9b9d49-4e49-4574-a07c-6f72acefcfd2@github.com>
 <tBB2q0ATDEr8k86St14cqLVTAwy2CH34WolOWfPH1bw=.e9a456ad-28c8-4e36-9eb4-62024a96c0e4@github.com>
 <55-uvNq2QGWKbTD3uVotqaRdbInO5Ih0L462CR7cnGc=.4a2912dd-6868-4290-9e39-2c5f50cf4ca2@github.com>
 <CMHxOHQvUOHVPAkk0TR1N5pyLFoWN6wlDDX4y-vs5Q8=.b3da3476-d256-4011-afae-f6235bbcee45@github.com>
Message-ID: <DYE5Xh2_FehT4qZpjTdxeNSd57IGxB0cpVVIQP0g-5o=.55c2c0b8-f9b9-4ce1-a834-6538a1cc3ecf@github.com>

On Thu, 10 Dec 2020 13:44:59 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:

> Hi,
> 
> I don't think TargetAnnoCombo should be updated, at least not for this fix. It is an old hard to understand test that predates modules.
> 
> It would be good to do further testing as Vicente writes. I suggest:
> 
>     1. A test that the module info compiles, you already have this.
> 
>     2. A test that the class file contains the bytes for the annotation might make sense. As Jon has pointed out in different review threads there is the toolbox, perhaps that could be of use? There are some examples of toolbox tests in  `jdk/test/langtools/tools/javac/modules` though I don't have a good example of one that verifies the contents of the class file. Perhaps @vicente-romero-oracle can point to an example?

it is probably an overkill but method: `testAnnos` in test: `test/langtools/tools/javac/records/RecordCompilationTests.java` is an example applied to records that could be adapted to what we want here

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

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

From darcy at openjdk.java.net  Thu Dec 10 22:31:01 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 10 Dec 2020 22:31:01 GMT
Subject: [jdk16] RFR: 8258060: Update @jls tags for renamed/renumbered sections
Message-ID: <YWZLQVS61WrZYBrlxT4af5se4AdLkQXlzFXyaGpKqpY=.81bd8c16-2127-4842-916e-987f51856bba@github.com>

Given upcoming changes in the JLS terminology around the term "type", various sections were renamed:

    https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html

The @jls tags in the java.compiler module which refer to the renamed sections should be updated.

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

Commit messages:
 - 8258060

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

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

From jjg at openjdk.java.net  Thu Dec 10 23:02:56 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 10 Dec 2020 23:02:56 GMT
Subject: [jdk16] RFR: 8258060: Update @jls tags for renamed/renumbered
 sections
In-Reply-To: <YWZLQVS61WrZYBrlxT4af5se4AdLkQXlzFXyaGpKqpY=.81bd8c16-2127-4842-916e-987f51856bba@github.com>
References: <YWZLQVS61WrZYBrlxT4af5se4AdLkQXlzFXyaGpKqpY=.81bd8c16-2127-4842-916e-987f51856bba@github.com>
Message-ID: <crb0yWrZFXGe1W1GLNvu9l1NfBskqRlf90ZazKKiDQU=.d7343840-29a9-4735-a013-2b9236c15546@github.com>

On Thu, 10 Dec 2020 22:25:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Given upcoming changes in the JLS terminology around the term "type", various sections were renamed:
> 
>     https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html
> 
> The @jls tags in the java.compiler module which refer to the renamed sections should be updated.

Marked as reviewed by jjg (Reviewer).

src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java line 187:

> 185:      * @see MirroredTypeException
> 186:      * @see MirroredTypesException
> 187:      * @jls 9.6.1 Annotation Elements

Slightly surprising... but I agree that it matches JLS

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

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

From naoto at openjdk.java.net  Thu Dec 10 23:10:57 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 10 Dec 2020 23:10:57 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
Message-ID: <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>

On Mon, 7 Dec 2020 14:27:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
>> 
>> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
>> 
>> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
>> 
>> ### Modules reviewed
>> 
>> - [ ] java.base
>> - [ ] java.desktop
>> - [x] jdk.compiler
>> - [ ] java.se
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move to share/data, and move jdwp.spec to java.se

Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`, `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good overall.

test/jdk/java/util/Locale/LSRDataTest.java line 57:

> 55:     // path to the lsr file from the make folder, this test relies on the
> 56:     // relative path to the file in the make folder, considering
> 57:     // test and make will always exist in the same jdk layout

The comment refers to the "make" folder. (line 55 as well).

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

Marked as reviewed by naoto (Reviewer).

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

From vromero at openjdk.java.net  Fri Dec 11 02:13:10 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 11 Dec 2020 02:13:10 GMT
Subject: RFR: 8257598: Clarify what component values are used in Record::equals
Message-ID: <Ok-kyDURzKkNYy12QPAu8eq4rVNdC4pvp2eYNSzFSFA=.86faab91-59ac-41c8-92c4-f4cee4acc389@github.com>

Please review this patch which modifies the spec for method java.lang.Record::equals. It states that the implementation of this method should use the record fields for the comparison instead of the accessors.

TIA,
Vicente

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

Commit messages:
 - Merge branch 'master' into JDK-8257598
 - Merge branch 'master' into JDK-8257598
 - 8257598: Clarify what component values are used in Record::equals

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

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

From joe.darcy at oracle.com  Fri Dec 11 02:25:46 2020
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 10 Dec 2020 18:25:46 -0800
Subject: RFR: 8257598: Clarify what component values are used in
 Record::equals
In-Reply-To: <Ok-kyDURzKkNYy12QPAu8eq4rVNdC4pvp2eYNSzFSFA=.86faab91-59ac-41c8-92c4-f4cee4acc389@github.com>
References: <Ok-kyDURzKkNYy12QPAu8eq4rVNdC4pvp2eYNSzFSFA=.86faab91-59ac-41c8-92c4-f4cee4acc389@github.com>
Message-ID: <bef2008b-6678-3a0b-f35f-2f13fb5d63ce@oracle.com>

If this is meant for JDK 16, it is easier overall if PR is done against 
the JDK 16 repo.

-Joe

On 12/10/2020 6:13 PM, Vicente Romero wrote:
> Please review this patch which modifies the spec for method java.lang.Record::equals. It states that the implementation of this method should use the record fields for the comparison instead of the accessors.
>
> TIA,
> Vicente
>
> -------------
>
> Commit messages:
>   - Merge branch 'master' into JDK-8257598
>   - Merge branch 'master' into JDK-8257598
>   - 8257598: Clarify what component values are used in Record::equals
>
> Changes: https://git.openjdk.java.net/jdk/pull/1742/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1742&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8257598
>    Stats: 135 lines in 2 files changed: 132 ins; 1 del; 2 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/1742.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/1742/head:pull/1742
>
> PR: https://git.openjdk.java.net/jdk/pull/1742

From vromero at openjdk.java.net  Fri Dec 11 04:30:55 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 11 Dec 2020 04:30:55 GMT
Subject: Withdrawn: 8257598: Clarify what component values are used in
 Record::equals
In-Reply-To: <Ok-kyDURzKkNYy12QPAu8eq4rVNdC4pvp2eYNSzFSFA=.86faab91-59ac-41c8-92c4-f4cee4acc389@github.com>
References: <Ok-kyDURzKkNYy12QPAu8eq4rVNdC4pvp2eYNSzFSFA=.86faab91-59ac-41c8-92c4-f4cee4acc389@github.com>
Message-ID: <SnUf-9jrfVOMfLElZHkp3SV0p5A4RdJMLQGnUsv3Y_M=.47018fcd-3fa0-4302-befc-e9f3414bcbd4@github.com>

On Fri, 11 Dec 2020 02:07:50 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this patch which modifies the spec for method java.lang.Record::equals. It states that the implementation of this method should use the record fields for the comparison instead of the accessors.
> 
> TIA,
> Vicente

This pull request has been closed without being integrated.

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

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

From vromero at openjdk.java.net  Fri Dec 11 05:10:56 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Fri, 11 Dec 2020 05:10:56 GMT
Subject: RFR: 8257598: Clarify what component values are used in
 Record::equals
In-Reply-To: <Ok-kyDURzKkNYy12QPAu8eq4rVNdC4pvp2eYNSzFSFA=.86faab91-59ac-41c8-92c4-f4cee4acc389@github.com>
References: <Ok-kyDURzKkNYy12QPAu8eq4rVNdC4pvp2eYNSzFSFA=.86faab91-59ac-41c8-92c4-f4cee4acc389@github.com>
Message-ID: <1B_KxwxC3jwpR81YMnTx0wXkrAKiip7CI9K19IYaeFQ=.b5403b79-538b-4111-b3c9-8f8ae7c3e496@github.com>

On Fri, 11 Dec 2020 02:07:50 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this patch which modifies the spec for method java.lang.Record::equals. It states that the implementation of this method should use the record fields for the comparison instead of the accessors.
> 
> TIA,
> Vicente

> _Mailing list message from [Joe Darcy](mailto:joe.darcy at oracle.com) on [compiler-dev](mailto:compiler-dev at openjdk.java.net):_
> 
> If this is meant for JDK 16, it is easier overall if PR is done against
> the JDK 16 repo.
> 
> -Joe
> 
> On 12/10/2020 6:13 PM, Vicente Romero wrote:

true, thanks, I have created another PR based on jdk16: https://github.com/openjdk/jdk16/pull/5

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

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

From minqi at openjdk.java.net  Fri Dec 11 05:17:33 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 11 Dec 2020 05:17:33 GMT
Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed
 "assert(reserved_rgn != 0LL) failed: No reserved region" [v5]
In-Reply-To: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
Message-ID: <mBghLCvd_6OOPgNdUHyl6QGPV9V_C30p2ILwh4bwIac=.4c28be41-fc69-432a-aa39-5f2ccb9820fc@github.com>

> Hi, Please review
>   Windows mapping for file into memory could not happen to reserved memory. In mapping CDS archive we first reserve enough memory then before mapping, release them. For cds archive and using class space, need split the whole space into two, that is, release the whole reserved space and do reservation to the two split spaces again, which is problematic that there is possibility other thread or system can kick in to take the released space.
>   The fix is the first step of two steps:
>    1) Do not split reserved memory;
>    2) Remove splitting memory.
>    This fix is first step, for Windows and use requested mapping address, reserved for cds archive and ccs on a contiguous space separately, so there is no need to call split. If any reservation failed, release them, go to other way, but do not do the 'real' split either. For Windows (and using class space), the reserved space will be released anyway. 
> 
> Tests:tier1-5,tier7

Yumin Qi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 35 commits:

 - Added test case; Fixed an nmt issue caused by bitmap region not released after archive loading failed; Unmap bitmap after archive failure. Fixed reserved region name for adding reserved region.
 - Add total_space_rs, total reserved space to release_reserved_spaces and reserve_address_space_for_archives, made changes to check failed output on test.
 - 8253762: JFR: getField(String) should be able to access subfields
   
   Reviewed-by: mgronlun
 - 8257670: sun/security/ssl/SSLSocketImpl/SSLSocketLeak.java reports leaks
   
   Reviewed-by: jnimeh
 - 8257796: [TESTBUG] TestUseSHA512IntrinsicsOptionOnSupportedCPU.java fails on x86_32
   
   Reviewed-by: kvn
 - 8257211: C2: Enable call devirtualization during post-parse phase
   
   Reviewed-by: kvn, neliasso, thartmann
 - 8257572: Deprecate the archaic signal-chaining interfaces: sigset and signal
   
   Reviewed-by: ihse, alanb, dcubed, erikj
 - 8257718: LogCompilation: late_inline doesnt work right for JDK 8 logs
   
   Reviewed-by: redestad, kvn
 - 8257799: Update JLS cross-references in java.compiler
   
   Reviewed-by: jjg
 - 8254939: macOS: unused function 'replicate4_imm'
   
   Reviewed-by: redestad, thartmann
 - ... and 25 more: https://git.openjdk.java.net/jdk/compare/29a09c89...0421943d

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

Changes: https://git.openjdk.java.net/jdk/pull/1657/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1657&range=04
  Stats: 8183 lines in 159 files changed: 4666 ins; 2763 del; 754 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1657.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1657/head:pull/1657

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

From minqi at openjdk.java.net  Fri Dec 11 06:20:56 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 11 Dec 2020 06:20:56 GMT
Subject: RFR: 8255917: runtime/cds/SharedBaseAddress.java failed
 "assert(reserved_rgn != 0LL) failed: No reserved region" [v5]
In-Reply-To: <Jnzj-AJTVNjpz0ts4WSVDutSf2Fyv1TuLh6pUn5Y904=.e4129581-0c64-4e63-8f20-5d7ae7c6e071@github.com>
References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
 <vtqmULMCnP8KBSPw6V_NFKvYVQzd9nAT9Y4V-N3j9Zs=.3c935956-78ef-491f-b209-eca535b8ca40@github.com>
 <sAqnH0sEch5UPQIwaz0vgcwVE9P_8WS-FSBmH7VU4IQ=.d6161796-38fa-4267-a62d-4dbb82689af4@github.com>
 <Jnzj-AJTVNjpz0ts4WSVDutSf2Fyv1TuLh6pUn5Y904=.e4129581-0c64-4e63-8f20-5d7ae7c6e071@github.com>
Message-ID: <gxcE4bVzUGSQ_clecIjrse_78xNKil4-urgXqWbJmhU=.cadaa2df-7141-45a0-8d2e-e0d15d36f00c@github.com>

On Tue, 8 Dec 2020 06:12:36 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Changes requested by iklam (Reviewer).
>
> Please check 03. 02 is generated when merge with most current and remote head not updated correctly. After set remote head correct, 03 is regenerated and is correct one for review. Thanks

This branch has many conflicts, something wrong since push-02, closed this PR and will send a single patch in new PR.

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

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

From minqi at openjdk.java.net  Fri Dec 11 06:20:57 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Fri, 11 Dec 2020 06:20:57 GMT
Subject: Withdrawn: 8255917: runtime/cds/SharedBaseAddress.java failed
 "assert(reserved_rgn != 0LL) failed: No reserved region"
In-Reply-To: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
References: <4YHyeF2363cg4CSvBO5L3UGcM4PlrJtR8w5oE5uspCk=.a057fe4a-bcca-4337-a2ae-04bb4b1aa2e9@github.com>
Message-ID: <9Hu8Jqsqm4gG7-yV0AZIZvnOh72CmunbbQhdT-LnjBA=.da14a187-fb1b-4190-9e4b-d06896ad7202@github.com>

On Mon, 7 Dec 2020 05:01:27 GMT, Yumin Qi <minqi at openjdk.org> wrote:

> Hi, Please review
>   Windows mapping for file into memory could not happen to reserved memory. In mapping CDS archive we first reserve enough memory then before mapping, release them. For cds archive and using class space, need split the whole space into two, that is, release the whole reserved space and do reservation to the two split spaces again, which is problematic that there is possibility other thread or system can kick in to take the released space.
>   The fix is the first step of two steps:
>    1) Do not split reserved memory;
>    2) Remove splitting memory.
>    This fix is first step, for Windows and use requested mapping address, reserved for cds archive and ccs on a contiguous space separately, so there is no need to call split. If any reservation failed, release them, go to other way, but do not do the 'real' split either. For Windows (and using class space), the reserved space will be released anyway. 
> 
> Tests:tier1-5,tier7

This pull request has been closed without being integrated.

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

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

From jjg at openjdk.java.net  Fri Dec 11 07:23:15 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 11 Dec 2020 07:23:15 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4
In-Reply-To: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
Message-ID: <RAdVAZpFjoxQnDj02FVOpgugTaQuNd-LMzpKXeu4VEU=.465404f4-4737-4ec2-b7b5-1681b6471698@github.com>

On Wed, 28 Oct 2020 03:26:16 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> HTML4 is no longer supported in javadoc.
> 
> doclint needs to drop HTML4 support as well.
> The changes consist of:
> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
> * Modifying test code and expected outputs to be checked in HTML5

Generally nice; congratulations on figuring this all out.

Some comments in files need response and/or action.

Please make the review non-draft as well

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties line 30:

> 28: dc.attr.lacks.value = \u5C5E\u6027\u7F3A\u5C11\u503C
> 29: dc.attr.not.number = \u5C5E\u6027\u503C\u4E0D\u662F\u6570\u5B57
> 30: dc.attr.not.supported.html4 = \u5C5E\u6027\u5728 HTML4 \u4E2D\u4E0D\u53D7\u652F\u6301: {0}

In general, we (Dev) do not edit any localized resource files. That happens "automatically" by the localization team.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java line 410:

> 408:         OBSOLETE,
> 409:         UNSUPPORTED
> 410:     }

On one hand, I don't think we need this level of detail, but on the other, I see it closely matches `AttrKind`, so OK.

Is there are useful distinction between INVALID / OBSOLETE / UNSUPPORTED ?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 692:

> 690:                                 }
> 691:                             } catch (NumberFormatException ex) {
> 692:                                 env.messages.error(HTML, tree, "dc.attr.img.border", attr);

It's generally better practice to use unique message keys at each call site.  This is so that if there is a downstream problem when someone reports a problem with an error message, we know the exact single place in the code where the message comes from.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java line 229:

> 227:                 String argVersion = arg.substring(arg.indexOf(":") + 1);
> 228:                 if (argVersion == null || !argVersion.equals("html5")) {
> 229:                     throw new BadArgs("dc.bad.value.for.option", arg, argVersion);

It might be friendly to give a warning when this option is used, saying that `html5` is the default and only supported version, and that this option may be removed in a future release.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java line 348:

> 346:                 String argVersion = arg.substring(arg.indexOf(":") + 1);
> 347:                 if (argVersion == null || !argVersion.equals("html5")) {
> 348:                     throw new IllegalArgumentException(argVersion);

These lines are only used when invoked from javac/javadoc etc, so it would be reasonable to delete them entirely, provided those tools never try and use this option.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java line 51:

> 49:  * public.
> 50:  *
> 51:  * @see <a href="http://www.w3.org/TR/REC-html40/">HTML 4.01 Specification</a>

Given the presence of UNSUPPORTED in the ensuing code, I'd recommend leaving this link, for historical purposes.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java line 360:

> 358:             attrs(AttrKind.OK, COLSPAN, ROWSPAN, HEADERS, SCOPE, Attr.ABBR),
> 359:             attrs(AttrKind.UNSUPPORTED, WIDTH, BGCOLOR, HEIGHT, NOWRAP, AXIS, ALIGN, CHAR, CHAROFF),
> 360:             attrs(AttrKind.OK, VALIGN)), // Removed after JDK-8255214 fixed.

Does this need attention? JDK-8255215 has been fixed

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java line 541:

> 539:         OBSOLETE,
> 540:         UNSUPPORTED
> 541:     }

Is there a useful distinction between INVALID / OBSOLETE / UNSUPPORTED ?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlVersion.java line 1:

> 1: /*

Yay!

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties line 32:

> 30: dc.attr.not.supported.html5 = attribute not supported in HTML5: {0}
> 31: dc.attr.obsolete = attribute obsolete: {0}
> 32: dc.attr.obsolete.use.css = attribute obsolete, use CSS instead: {0}

Is this still required?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties line 35:

> 33: dc.attr.repeated = repeated attribute: {0}
> 34: dc.attr.img.border = attribute border for img only accepts "0", use CSS instead: {0}
> 35: dc.attr.table.border = attribute border for table only accepts "" or "1", use CSS instead: {0}

I suggest quoting the attribute name "border"

test/langtools/tools/doclint/AccessibilityTest.out line 28:

> 26:      * <table><tr><th>head<tr><td>data</table>
> 27:                                       ^
> 28: AccessibilityTest.java:66: error: no summary or caption for table

summary is not a valid attribute in HTML5, so I would omit it from the message.

test/langtools/tools/doclint/AnchorTest.java line 3:

> 1: /*
> 2:  * @test /nodynamiccopyright/
> 3:  * @bug 8004832 8247957

The bug number should only be added when the test can be considered to be a significant test of the work.

In general, don't bother to add the bug number when a test is just incidentally affected by the work.

In this case, there appears to be no other change to the file, but I guess OK, you've changed to golden output file.

test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTest.java line 11:

> 9:  * @run main DocLintTester -badargs -XhtmlVersion: HtmlVersionTagsAttrsTest.java
> 10:  *
> 11:  *

I'm guessing these blank lines are to maintain line numbers, right?

test/langtools/tools/doclint/html/TableTagTest.out line 22:

> 20:      *  <table summary="abc" width="50%"> <tr> <td> <tfoot> <tr> </tfoot></table>
> 21:                              ^
> 22: 7 errors

Does it work to add the final newline: various tools give warnings if files do not end with newline.

test/langtools/tools/doclint/html/TextNotAllowed.out line 30:

> 28: TextNotAllowed.java:16: error: attribute not supported in HTML5: summary
> 29:  * <table summary=description> abc </table>
> 30:           ^

The test is 'Text Not Allowed', so the test file should be valid except for text where it is not allowed.  Don't add spurious other errors. In this case, provide a `<caption>` to keep DocLint happy.

This applies throughout this test.

test/langtools/tools/doclint/tidy/InvalidName.out line 3:

> 1: InvalidName.java:17: error: invalid name for anchor: "foo()"
> 2:  * <a id="foo()">invalid</a>
> 3:       ^

This seems incorrect. In HTML5 all names are valid unless they contain whitespace.

test/langtools/tools/doclint/tidy/TextNotAllowed.out line 2:

> 1: TextNotAllowed.java:14: error: attribute not supported in HTML5: summary
> 2:  * <table summary=description> abc </table>

See previous comments about spurious error messages

test/langtools/tools/doclint/tidy/TrimmingEmptyTag.out line 5:

> 3:       ^
> 4: TrimmingEmptyTag.java:15: error: attribute not supported in HTML5: summary
> 5:  * <table summary=description></table>

ditto

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java line 148:

> 146:             return;
> 147:         } else if (useXhtmlVersion) {
> 148:             System.err.println(localize("dc.main.use.xhtmlversion"));

use `out.println`

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java line 360:

> 358:             EnumSet.of(Flag.ACCEPTS_BLOCK, Flag.ACCEPTS_INLINE),
> 359:             attrs(AttrKind.OK, COLSPAN, ROWSPAN, HEADERS, SCOPE, Attr.ABBR),
> 360:             attrs(AttrKind.UNSUPPORTED, WIDTH, BGCOLOR, HEIGHT, NOWRAP, AXIS, ALIGN, CHAR, CHAROFF, VALIGN)), // Removed after JDK-8255214 fixed.

remove comment

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java line 375:

> 373: 
> 374:     TR(BlockType.TABLE_ITEM, EndKind.OPTIONAL,
> 375:             attrs(AttrKind.UNSUPPORTED, ALIGN, CHAR, CHAROFF, BGCOLOR, VALIGN)) { // Removed after JDK-8255215 fixed

remove comment

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties line 91:

> 89: dc.main.ioerror=IO error: {0}
> 90: dc.main.no.files.given=No files given
> 91: dc.main.use.xhtmlversion=html5 is the default and only supported version for -XhtmlVersion, and this option may be removed in a future release.

change `version` to `value` 
change `, and` to `;`

`
html5 is the default and only supported value for -XhtmlVersion; this option may be removed in a future release.
`

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

Changes requested by jjg (Reviewer).

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

From ysatowse at openjdk.java.net  Fri Dec 11 07:23:09 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Fri, 11 Dec 2020 07:23:09 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4
Message-ID: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>

HTML4 is no longer supported in javadoc.

doclint needs to drop HTML4 support as well.
The changes consist of:
* Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
* Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
* Modifying test code and expected outputs to be checked in HTML5

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

Commit messages:
 - 3rd: 8247957 and 8256312
 - Merge branch 'master' into JDK-8247957_2
 - 8247957: remove doclint support for HTML 4
 - 8247957: remove doclint support for HTML 4

Changes: https://git.openjdk.java.net/jdk/pull/893/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=893&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8247957
  Stats: 1445 lines in 54 files changed: 418 ins; 744 del; 283 mod
  Patch: https://git.openjdk.java.net/jdk/pull/893.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/893/head:pull/893

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

From ysatowse at openjdk.java.net  Fri Dec 11 07:23:22 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Fri, 11 Dec 2020 07:23:22 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4
In-Reply-To: <RAdVAZpFjoxQnDj02FVOpgugTaQuNd-LMzpKXeu4VEU=.465404f4-4737-4ec2-b7b5-1681b6471698@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <RAdVAZpFjoxQnDj02FVOpgugTaQuNd-LMzpKXeu4VEU=.465404f4-4737-4ec2-b7b5-1681b6471698@github.com>
Message-ID: <n2ea4PoUtsEtADcdUM3AkkrO22AT2Tn4nJo2TspgK54=.3d72d7f6-3ce5-4aa3-a2aa-3f49c51b83b1@github.com>

On Thu, 12 Nov 2020 02:28:51 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> HTML4 is no longer supported in javadoc.
>> 
>> doclint needs to drop HTML4 support as well.
>> The changes consist of:
>> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
>> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
>> * Modifying test code and expected outputs to be checked in HTML5
>
> Generally nice; congratulations on figuring this all out.
> 
> Some comments in files need response and/or action.

@jonathan-gibbons The new commit includes the changes for your review comments and "8256312: Valid anchor 'id' value not allowed".  Please take a look over at your convenience.

> Please make the review non-draft as well

Thanks for reviewing @jonathan-gibbons 
This request should have got changed to "non-draft".

FYI. all tests in jdk-tier1 are still green with the latest changes.
https://mach5.us.oracle.com/mdash/jobs/yoshiki-jdk-20201211-0555-16616611

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties line 30:
> 
>> 28: dc.attr.lacks.value = \u5C5E\u6027\u7F3A\u5C11\u503C
>> 29: dc.attr.not.number = \u5C5E\u6027\u503C\u4E0D\u662F\u6570\u5B57
>> 30: dc.attr.not.supported.html4 = \u5C5E\u6027\u5728 HTML4 \u4E2D\u4E0D\u53D7\u652F\u6301: {0}
> 
> In general, we (Dev) do not edit any localized resource files. That happens "automatically" by the localization team.

I see.  Will discard all changes done in the localized resource files.

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java line 410:
> 
>> 408:         OBSOLETE,
>> 409:         UNSUPPORTED
>> 410:     }
> 
> On one hand, I don't think we need this level of detail, but on the other, I see it closely matches `AttrKind`, so OK.
> 
> Is there are useful distinction between INVALID / OBSOLETE / UNSUPPORTED ?

OK: valid
OBSOLETE: obsolete, deprecated, but still supported (valid)
UNSUPPORTED: ever supported but no longer supported (invalid)
INVALID: the rest of others (invalid)

UNSUPPORTED can be used if we would like to choose a friendly message instead of saying "unknown tag" only.
OBSOLETE is not used anywhere in this commit.  Although HTML5 has some obsolete features, [JDK-8215577](https://bugs.openjdk.java.net/browse/JDK-8215577) didn't define them as valid features if my understanding is correct.  So I chose not to allow obsolete features in order to avoid inconsistency.

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 692:
> 
>> 690:                                 }
>> 691:                             } catch (NumberFormatException ex) {
>> 692:                                 env.messages.error(HTML, tree, "dc.attr.img.border", attr);
> 
> It's generally better practice to use unique message keys at each call site.  This is so that if there is a downstream problem when someone reports a problem with an error message, we know the exact single place in the code where the message comes from.

Agreed.  I would like to change 675-695 as below

                    case BORDER:
                        if (currTag == HtmlTag.TABLE) {
                            String v = getAttrValue(tree);
                            try {
                                if (v == null || (!v.isEmpty() && Integer.parseInt(v) != 1)) {
                                    env.messages.error(HTML, tree, "dc.attr.table.border.not.valid", attr);
                                }
                            } catch (NumberFormatException ex) {
                                env.messages.error(HTML, tree, "dc.attr.table.border.not.number", attr);
                            }
                        } else if (currTag == HtmlTag.IMG) {
                            String v = getAttrValue(tree);
                            try {
                                if (v == null || (!v.isEmpty() && Integer.parseInt(v) != 0)) {
                                    env.messages.error(HTML, tree, "dc.attr.img.border.not.valid", attr);
                                }
                            } catch (NumberFormatException ex) {
                                env.messages.error(HTML, tree, "dc.attr.img.border.not.number", attr);
                            }
                        }
                        break;

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java line 229:
> 
>> 227:                 String argVersion = arg.substring(arg.indexOf(":") + 1);
>> 228:                 if (argVersion == null || !argVersion.equals("html5")) {
>> 229:                     throw new BadArgs("dc.bad.value.for.option", arg, argVersion);
> 
> It might be friendly to give a warning when this option is used, saying that `html5` is the default and only supported version, and that this option may be removed in a future release.

Ok

> test/langtools/tools/doclint/html/TableTagTest.out line 22:
> 
>> 20:      *  <table summary="abc" width="50%"> <tr> <td> <tfoot> <tr> </tfoot></table>
>> 21:                              ^
>> 22: 7 errors
> 
> Does it work to add the final newline: various tools give warnings if files do not end with newline.

It works though.  But I will add a blank line at the end for consistency.

> test/langtools/tools/doclint/html/TextNotAllowed.out line 30:
> 
>> 28: TextNotAllowed.java:16: error: attribute not supported in HTML5: summary
>> 29:  * <table summary=description> abc </table>
>> 30:           ^
> 
> The test is 'Text Not Allowed', so the test file should be valid except for text where it is not allowed.  Don't add spurious other errors. In this case, provide a `<caption>` to keep DocLint happy.
> 
> This applies throughout this test.

Thanks.  I was lacking of such perspective.

> test/langtools/tools/doclint/tidy/TextNotAllowed.out line 2:
> 
>> 1: TextNotAllowed.java:14: error: attribute not supported in HTML5: summary
>> 2:  * <table summary=description> abc </table>
> 
> See previous comments about spurious error messages

Ok.

> test/langtools/tools/doclint/tidy/TrimmingEmptyTag.out line 5:
> 
>> 3:       ^
>> 4: TrimmingEmptyTag.java:15: error: attribute not supported in HTML5: summary
>> 5:  * <table summary=description></table>
> 
> ditto

Ok.

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java line 51:
> 
>> 49:  * public.
>> 50:  *
>> 51:  * @see <a href="http://www.w3.org/TR/REC-html40/">HTML 4.01 Specification</a>
> 
> Given the presence of UNSUPPORTED in the ensuing code, I'd recommend leaving this link, for historical purposes.

Ok.

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java line 360:
> 
>> 358:             attrs(AttrKind.OK, COLSPAN, ROWSPAN, HEADERS, SCOPE, Attr.ABBR),
>> 359:             attrs(AttrKind.UNSUPPORTED, WIDTH, BGCOLOR, HEIGHT, NOWRAP, AXIS, ALIGN, CHAR, CHAROFF),
>> 360:             attrs(AttrKind.OK, VALIGN)), // Removed after JDK-8255214 fixed.
> 
> Does this need attention? JDK-8255215 has been fixed

Yes, now that this can be removed.  I will do.

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java line 348:
> 
>> 346:                 String argVersion = arg.substring(arg.indexOf(":") + 1);
>> 347:                 if (argVersion == null || !argVersion.equals("html5")) {
>> 348:                     throw new IllegalArgumentException(argVersion);
> 
> These lines are only used when invoked from javac/javadoc etc, so it would be reasonable to delete them entirely, provided those tools never try and use this option.

These lines are likely to be used as long as the "--doclint-format html5" option is permitted.  For example, this option is still used in the make/common/JavaCompilation.gmk.

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java line 541:
> 
>> 539:         OBSOLETE,
>> 540:         UNSUPPORTED
>> 541:     }
> 
> Is there a useful distinction between INVALID / OBSOLETE / UNSUPPORTED ?

Same distinction as mentioned for ElemKind

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties line 32:
> 
>> 30: dc.attr.not.supported.html5 = attribute not supported in HTML5: {0}
>> 31: dc.attr.obsolete = attribute obsolete: {0}
>> 32: dc.attr.obsolete.use.css = attribute obsolete, use CSS instead: {0}
> 
> Is this still required?

Do you mean ".html5" would be better to be removed?
If so, yes.  I just left it because the message would be friendly if it still say "attribute not supported in HTML5".

> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties line 35:
> 
>> 33: dc.attr.repeated = repeated attribute: {0}
>> 34: dc.attr.img.border = attribute border for img only accepts "0", use CSS instead: {0}
>> 35: dc.attr.table.border = attribute border for table only accepts "" or "1", use CSS instead: {0}
> 
> I suggest quoting the attribute name "border"

Ok.

> test/langtools/tools/doclint/AccessibilityTest.out line 28:
> 
>> 26:      * <table><tr><th>head<tr><td>data</table>
>> 27:                                       ^
>> 28: AccessibilityTest.java:66: error: no summary or caption for table
> 
> summary is not a valid attribute in HTML5, so I would omit it from the message.

You are right.  I will remove "summary" from the message, and then remove two of the tests that still use "summary".

> test/langtools/tools/doclint/AnchorTest.java line 3:
> 
>> 1: /*
>> 2:  * @test /nodynamiccopyright/
>> 3:  * @bug 8004832 8247957
> 
> The bug number should only be added when the test can be considered to be a significant test of the work.
> 
> In general, don't bother to add the bug number when a test is just incidentally affected by the work.
> 
> In this case, there appears to be no other change to the file, but I guess OK, you've changed to golden output file.

Understood.  Thanks for your instruction.

> test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTest.java line 11:
> 
>> 9:  * @run main DocLintTester -badargs -XhtmlVersion: HtmlVersionTagsAttrsTest.java
>> 10:  *
>> 11:  *
> 
> I'm guessing these blank lines are to maintain line numbers, right?

Right

> test/langtools/tools/doclint/tidy/InvalidName.out line 3:
> 
>> 1: InvalidName.java:17: error: invalid name for anchor: "foo()"
>> 2:  * <a id="foo()">invalid</a>
>> 3:       ^
> 
> This seems incorrect. In HTML5 all names are valid unless they contain whitespace.

Understood.  Need to file it as another DocLint bug.

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

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

From jjg at openjdk.java.net  Fri Dec 11 07:23:23 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 11 Dec 2020 07:23:23 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4
In-Reply-To: <n2ea4PoUtsEtADcdUM3AkkrO22AT2Tn4nJo2TspgK54=.3d72d7f6-3ce5-4aa3-a2aa-3f49c51b83b1@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <RAdVAZpFjoxQnDj02FVOpgugTaQuNd-LMzpKXeu4VEU=.465404f4-4737-4ec2-b7b5-1681b6471698@github.com>
 <n2ea4PoUtsEtADcdUM3AkkrO22AT2Tn4nJo2TspgK54=.3d72d7f6-3ce5-4aa3-a2aa-3f49c51b83b1@github.com>
Message-ID: <iGSBNphHAu8InDARn6FJ76QIIZmc1bnN7gG4VqVJDsU=.37b6c36d-f2ed-406a-9fb8-7616e75da282@github.com>

On Fri, 13 Nov 2020 01:10:06 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java line 348:
>> 
>>> 346:                 String argVersion = arg.substring(arg.indexOf(":") + 1);
>>> 347:                 if (argVersion == null || !argVersion.equals("html5")) {
>>> 348:                     throw new IllegalArgumentException(argVersion);
>> 
>> These lines are only used when invoked from javac/javadoc etc, so it would be reasonable to delete them entirely, provided those tools never try and use this option.
>
> These lines are likely to be used as long as the "--doclint-format html5" option is permitted.  For example, this option is still used in the make/common/JavaCompilation.gmk.

1. we can update make/common/JavaCompilation.gmk
2. the option in javac/javadoc should be converted to a no-op so that it does not get passed down to doclint

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties line 32:
>> 
>>> 30: dc.attr.not.supported.html5 = attribute not supported in HTML5: {0}
>>> 31: dc.attr.obsolete = attribute obsolete: {0}
>>> 32: dc.attr.obsolete.use.css = attribute obsolete, use CSS instead: {0}
>> 
>> Is this still required?
>
> Do you mean ".html5" would be better to be removed?
> If so, yes.  I just left it because the message would be friendly if it still say "attribute not supported in HTML5".

Sorry, the comment is incorrectly focussed (and annoyingly cryptic: my apologies). 
I think I was referring to `dc.attr.obsolete.use.css`

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

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

From ysatowse at openjdk.java.net  Fri Dec 11 07:23:23 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Fri, 11 Dec 2020 07:23:23 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4
In-Reply-To: <mW_Qc1r_RiZySoSN9D-WeLYDALpejNnG_4Ocb2rrAcU=.22ce6aaf-5f4d-4326-8ef3-b19d42c2f6ad@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <RAdVAZpFjoxQnDj02FVOpgugTaQuNd-LMzpKXeu4VEU=.465404f4-4737-4ec2-b7b5-1681b6471698@github.com>
 <n2ea4PoUtsEtADcdUM3AkkrO22AT2Tn4nJo2TspgK54=.3d72d7f6-3ce5-4aa3-a2aa-3f49c51b83b1@github.com>
 <iGSBNphHAu8InDARn6FJ76QIIZmc1bnN7gG4VqVJDsU=.37b6c36d-f2ed-406a-9fb8-7616e75da282@github.com>
 <mW_Qc1r_RiZySoSN9D-WeLYDALpejNnG_4Ocb2rrAcU=.22ce6aaf-5f4d-4326-8ef3-b19d42c2f6ad@github.com>
Message-ID: <z0lA35ZUYIP6kf-awNNrhKELLpclGDAe55qsuYF4tnY=.81ee9176-db0b-47f9-a3d6-27943a07c65f@github.com>

On Fri, 13 Nov 2020 01:26:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> 1. we can update make/common/JavaCompilation.gmk
>> 2. the option in javac/javadoc should be converted to a no-op so that it does not get passed down to doclint
>
> (updating make/common/JavaCompilation.gmk should be done with a separate JBS issue, filed against the build.)

Filed as [JDK-8256313](https://bugs.openjdk.java.net/browse/JDK-8256313).

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

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

From ysatowse at openjdk.java.net  Fri Dec 11 07:23:24 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Fri, 11 Dec 2020 07:23:24 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4
In-Reply-To: <n2ea4PoUtsEtADcdUM3AkkrO22AT2Tn4nJo2TspgK54=.3d72d7f6-3ce5-4aa3-a2aa-3f49c51b83b1@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <RAdVAZpFjoxQnDj02FVOpgugTaQuNd-LMzpKXeu4VEU=.465404f4-4737-4ec2-b7b5-1681b6471698@github.com>
 <n2ea4PoUtsEtADcdUM3AkkrO22AT2Tn4nJo2TspgK54=.3d72d7f6-3ce5-4aa3-a2aa-3f49c51b83b1@github.com>
Message-ID: <bNGdCBxlZys-2-Pd3PHz77YC1ySn6y863sFFeuWlgKc=.d279693b-614b-4f84-81ce-595c695e3447@github.com>

On Fri, 13 Nov 2020 02:05:23 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> test/langtools/tools/doclint/tidy/InvalidName.out line 3:
>> 
>>> 1: InvalidName.java:17: error: invalid name for anchor: "foo()"
>>> 2:  * <a id="foo()">invalid</a>
>>> 3:       ^
>> 
>> This seems incorrect. In HTML5 all names are valid unless they contain whitespace.
>
> Understood.  Need to file it as another DocLint bug.

Filed as [JDK-8256312](https://bugs.openjdk.java.net/browse/JDK-8256312)

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

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

From jjg at openjdk.java.net  Fri Dec 11 07:23:23 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 11 Dec 2020 07:23:23 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4
In-Reply-To: <iGSBNphHAu8InDARn6FJ76QIIZmc1bnN7gG4VqVJDsU=.37b6c36d-f2ed-406a-9fb8-7616e75da282@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <RAdVAZpFjoxQnDj02FVOpgugTaQuNd-LMzpKXeu4VEU=.465404f4-4737-4ec2-b7b5-1681b6471698@github.com>
 <n2ea4PoUtsEtADcdUM3AkkrO22AT2Tn4nJo2TspgK54=.3d72d7f6-3ce5-4aa3-a2aa-3f49c51b83b1@github.com>
 <iGSBNphHAu8InDARn6FJ76QIIZmc1bnN7gG4VqVJDsU=.37b6c36d-f2ed-406a-9fb8-7616e75da282@github.com>
Message-ID: <mW_Qc1r_RiZySoSN9D-WeLYDALpejNnG_4Ocb2rrAcU=.22ce6aaf-5f4d-4326-8ef3-b19d42c2f6ad@github.com>

On Fri, 13 Nov 2020 01:25:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> These lines are likely to be used as long as the "--doclint-format html5" option is permitted.  For example, this option is still used in the make/common/JavaCompilation.gmk.
>
> 1. we can update make/common/JavaCompilation.gmk
> 2. the option in javac/javadoc should be converted to a no-op so that it does not get passed down to doclint

(updating make/common/JavaCompilation.gmk should be done with a separate JBS issue, filed against the build.)

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

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

From ysatowse at openjdk.java.net  Fri Dec 11 07:23:24 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Fri, 11 Dec 2020 07:23:24 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4
In-Reply-To: <iGSBNphHAu8InDARn6FJ76QIIZmc1bnN7gG4VqVJDsU=.37b6c36d-f2ed-406a-9fb8-7616e75da282@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <RAdVAZpFjoxQnDj02FVOpgugTaQuNd-LMzpKXeu4VEU=.465404f4-4737-4ec2-b7b5-1681b6471698@github.com>
 <n2ea4PoUtsEtADcdUM3AkkrO22AT2Tn4nJo2TspgK54=.3d72d7f6-3ce5-4aa3-a2aa-3f49c51b83b1@github.com>
 <iGSBNphHAu8InDARn6FJ76QIIZmc1bnN7gG4VqVJDsU=.37b6c36d-f2ed-406a-9fb8-7616e75da282@github.com>
Message-ID: <jxeGKX2d6p67pZZkVbEQt6eV6cmFIxp5SkOLTA1KuxU=.c998f8a6-cf1d-44d5-8a94-6afb22cf8ba2@github.com>

On Fri, 13 Nov 2020 01:32:18 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Do you mean ".html5" would be better to be removed?
>> If so, yes.  I just left it because the message would be friendly if it still say "attribute not supported in HTML5".
>
> Sorry, the comment is incorrectly focussed (and annoyingly cryptic: my apologies). 
> I think I was referring to `dc.attr.obsolete.use.css`

I got it.  Ok. Will remove it.

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

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

From jjg at openjdk.java.net  Fri Dec 11 07:23:25 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 11 Dec 2020 07:23:25 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4
In-Reply-To: <z0lA35ZUYIP6kf-awNNrhKELLpclGDAe55qsuYF4tnY=.81ee9176-db0b-47f9-a3d6-27943a07c65f@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <RAdVAZpFjoxQnDj02FVOpgugTaQuNd-LMzpKXeu4VEU=.465404f4-4737-4ec2-b7b5-1681b6471698@github.com>
 <n2ea4PoUtsEtADcdUM3AkkrO22AT2Tn4nJo2TspgK54=.3d72d7f6-3ce5-4aa3-a2aa-3f49c51b83b1@github.com>
 <iGSBNphHAu8InDARn6FJ76QIIZmc1bnN7gG4VqVJDsU=.37b6c36d-f2ed-406a-9fb8-7616e75da282@github.com>
 <mW_Qc1r_RiZySoSN9D-WeLYDALpejNnG_4Ocb2rrAcU=.22ce6aaf-5f4d-4326-8ef3-b19d42c2f6ad@github.com>
 <z0lA35ZUYIP6kf-awNNrhKELLpclGDAe55qsuYF4tnY=.81ee9176-db0b-47f9-a3d6-27943a07c65f@github.com>
Message-ID: <jDe1anz2EjUGL4guAqj9d8qGi-JbUGu_-I5JG4hPPxQ=.ef075371-bab5-4768-b1fd-92f440babe2e@github.com>

On Fri, 13 Nov 2020 02:49:40 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> (updating make/common/JavaCompilation.gmk should be done with a separate JBS issue, filed against the build.)
>
> Filed as [JDK-8256313](https://bugs.openjdk.java.net/browse/JDK-8256313).

In javac Arguments class, we should delete these lines at about 855

`
        String format = options.get(Option.DOCLINT_FORMAT);
        if (format != null) {
            doclintOpts.add(DocLint.XHTML_VERSION_PREFIX + format);
        }
`

This could be a separate JBS issue, if you prefer.

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

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

From ysatowse at openjdk.java.net  Fri Dec 11 07:23:25 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Fri, 11 Dec 2020 07:23:25 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4
In-Reply-To: <jDe1anz2EjUGL4guAqj9d8qGi-JbUGu_-I5JG4hPPxQ=.ef075371-bab5-4768-b1fd-92f440babe2e@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <RAdVAZpFjoxQnDj02FVOpgugTaQuNd-LMzpKXeu4VEU=.465404f4-4737-4ec2-b7b5-1681b6471698@github.com>
 <n2ea4PoUtsEtADcdUM3AkkrO22AT2Tn4nJo2TspgK54=.3d72d7f6-3ce5-4aa3-a2aa-3f49c51b83b1@github.com>
 <iGSBNphHAu8InDARn6FJ76QIIZmc1bnN7gG4VqVJDsU=.37b6c36d-f2ed-406a-9fb8-7616e75da282@github.com>
 <mW_Qc1r_RiZySoSN9D-WeLYDALpejNnG_4Ocb2rrAcU=.22ce6aaf-5f4d-4326-8ef3-b19d42c2f6ad@github.com>
 <z0lA35ZUYIP6kf-awNNrhKELLpclGDAe55qsuYF4tnY=.81ee9176-db0b-47f9-a3d6-27943a07c65f@github.com>
 <jDe1anz2EjUGL4guAqj9d8qGi-JbUGu_-I5JG4hPPxQ=.ef075371-bab5-4768-b1fd-92f440babe2e@github.com>
Message-ID: <lYprDse62HD_oaqKcwxoJu05q8A9A8_87a8ffaFFaQg=.f207077e-fdfa-4cd2-9064-1232775615c7@github.com>

On Thu, 26 Nov 2020 21:25:11 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Filed as [JDK-8256313](https://bugs.openjdk.java.net/browse/JDK-8256313).
>
> In javac Arguments class, we should delete these lines at about 855
> 
> `
>         String format = options.get(Option.DOCLINT_FORMAT);
>         if (format != null) {
>             doclintOpts.add(DocLint.XHTML_VERSION_PREFIX + format);
>         }
> `
> 
> This could be a separate JBS issue, if you prefer.

Filed as [JDK-8257204](https://bugs.openjdk.java.net/browse/JDK-8257204).

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Fri Dec 11 15:49:14 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Fri, 11 Dec 2020 15:49:14 GMT
Subject: RFR: 8254023: A module declaration is not allowed to be a target
 of an annotation that lacks an @Target meta-annotation [v3]
In-Reply-To: <wFdu9AyyNU2SB0nWx9mq_2syF2XyQIB0z6Rmc-r1fNc=.369439d1-385e-4fd1-aac1-72e48ac246e8@github.com>
References: <wFdu9AyyNU2SB0nWx9mq_2syF2XyQIB0z6Rmc-r1fNc=.369439d1-385e-4fd1-aac1-72e48ac246e8@github.com>
Message-ID: <uzhz9NKMGQaQyxkoR384sFA45wr4NZTWNzVUzmgRPwU=.088029af-25db-4936-96a3-620d7b79fade@github.com>

> Hi all,
> 
> The Java Language Specifications(JLS), from 8 to 13 included, state it as below:
> 
>> If an annotation of type java.lang.annotation.Target is not present on the
> declaration of an annotation type T , then T is applicable in all declaration contexts
> except type parameter declarations, and in no type contexts.
> These contexts are the syntactic locations where annotations were allowed in Java SE 7.
> 
> The JLS 14 and 15 state it as below:
> 
>>If an annotation of type java.lang.annotation.Target is not present on the
> declaration of an annotation type T , then T is applicable in all nine declaration
> contexts and in all 16 type contexts.
> 
> This patch adds `names.MODULE, names.TYPE_PARAMETER, names.TYPE_USE` to `com.sun.tools.javac.comp.Check.dfltTargetMeta` to fix this issue.
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision:

 - Polish.
 - Add two test cases.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/622/files
  - new: https://git.openjdk.java.net/jdk/pull/622/files/5ff3e252..d7777f4d

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

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Fri Dec 11 16:26:13 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Fri, 11 Dec 2020 16:26:13 GMT
Subject: RFR: 8254023: A module declaration is not allowed to be a target
 of an annotation that lacks an @Target meta-annotation [v4]
In-Reply-To: <wFdu9AyyNU2SB0nWx9mq_2syF2XyQIB0z6Rmc-r1fNc=.369439d1-385e-4fd1-aac1-72e48ac246e8@github.com>
References: <wFdu9AyyNU2SB0nWx9mq_2syF2XyQIB0z6Rmc-r1fNc=.369439d1-385e-4fd1-aac1-72e48ac246e8@github.com>
Message-ID: <ufKG7o3ORgA7Kh3RyrExcTKOV6Lm4b8xzJgclSyGl5Q=.925cf0f6-f86c-44a7-8be4-25d448a32043@github.com>

> Hi all,
> 
> The Java Language Specifications(JLS), from 8 to 13 included, state it as below:
> 
>> If an annotation of type java.lang.annotation.Target is not present on the
> declaration of an annotation type T , then T is applicable in all declaration contexts
> except type parameter declarations, and in no type contexts.
> These contexts are the syntactic locations where annotations were allowed in Java SE 7.
> 
> The JLS 14 and 15 state it as below:
> 
>>If an annotation of type java.lang.annotation.Target is not present on the
> declaration of an annotation type T , then T is applicable in all nine declaration
> contexts and in all 16 type contexts.
> 
> This patch adds `names.MODULE, names.TYPE_PARAMETER, names.TYPE_USE` to `com.sun.tools.javac.comp.Check.dfltTargetMeta` to fix this issue.
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge remote-tracking branch 'origin/master' into JDK-8254023
   
   # Conflicts:
   #	test/langtools/tools/javac/modules/AnnotationProcessing.java
 - Polish.
 - Add two test cases.
 - Remove TYPE_PARAMETER and TYPE_USE
 - 8254023: A module declaration is not allowed to be a target of an annotation that lacks an @Target meta-annotation

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

Changes: https://git.openjdk.java.net/jdk/pull/622/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=622&range=03
  Stats: 180 lines in 6 files changed: 177 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/622.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/622/head:pull/622

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Fri Dec 11 16:35:01 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Fri, 11 Dec 2020 16:35:01 GMT
Subject: RFR: 8254023: A module declaration is not allowed to be a target
 of an annotation that lacks an @Target meta-annotation
In-Reply-To: <DYE5Xh2_FehT4qZpjTdxeNSd57IGxB0cpVVIQP0g-5o=.55c2c0b8-f9b9-4ce1-a834-6538a1cc3ecf@github.com>
References: <wFdu9AyyNU2SB0nWx9mq_2syF2XyQIB0z6Rmc-r1fNc=.369439d1-385e-4fd1-aac1-72e48ac246e8@github.com>
 <pqSfmocPi4AJGQJEJl4j6UgITEL0f62TKSVpxwOer6w=.49e74a9b-ecb0-4a13-9dfc-93c27fd5149a@github.com>
 <5_HZhCK8rd2yWcf4XzGa_N50I1Xl3CMmUXSugfoJIUk=.379b61e3-e4a3-4509-ac7b-940a25ae4609@github.com>
 <6VDsNZKAYnkmm_YsLRjClBhqPMPPqy4d3TrWLcElkOU=.3f9b9d49-4e49-4574-a07c-6f72acefcfd2@github.com>
 <tBB2q0ATDEr8k86St14cqLVTAwy2CH34WolOWfPH1bw=.e9a456ad-28c8-4e36-9eb4-62024a96c0e4@github.com>
 <55-uvNq2QGWKbTD3uVotqaRdbInO5Ih0L462CR7cnGc=.4a2912dd-6868-4290-9e39-2c5f50cf4ca2@github.com>
 <CMHxOHQvUOHVPAkk0TR1N5pyLFoWN6wlDDX4y-vs5Q8=.b3da3476-d256-4011-afae-f6235bbcee45@github.com>
 <DYE5Xh2_FehT4qZpjTdxeNSd57IGxB0cpVVIQP0g-5o=.55c2c0b8-f9b9-4ce1-a834-6538a1cc3ecf@github.com>
Message-ID: <QzcPBDfL1gbJ27__AzwRzYJ2g_LSBpXY_feRiGsg0Aw=.b92150d1-8906-45d5-aa58-08b04ab6cd70@github.com>

On Thu, 10 Dec 2020 19:34:01 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Hi,
>> 
>> I don't think TargetAnnoCombo should be updated, at least not for this fix. It is an old hard to understand test that predates modules.
>> 
>> It would be good to do further testing as Vicente writes. I suggest:
>> 
>> 1) A test that the module info compiles, you already have this.
>> 2) A test that the class file contains the bytes for the annotation might make sense. As Jon has pointed out in different review threads there is the toolbox, perhaps that could be of use? There are some examples of toolbox tests in  `jdk/test/langtools/tools/javac/modules` though I don't have a good example of one that verifies the contents of the class file. Perhaps @vicente-romero-oracle can point to an example? 
>> 3) There should already be tests that annotation processing can pick up annotations on module declarations, it looks like `jdk/test/langtools/tools/javac/modules/AnnotationProcessing.java` contains some of this. See if you can add a case with an annotation without @Target.
>
>> Hi,
>> 
>> I don't think TargetAnnoCombo should be updated, at least not for this fix. It is an old hard to understand test that predates modules.
>> 
>> It would be good to do further testing as Vicente writes. I suggest:
>> 
>>     1. A test that the module info compiles, you already have this.
>> 
>>     2. A test that the class file contains the bytes for the annotation might make sense. As Jon has pointed out in different review threads there is the toolbox, perhaps that could be of use? There are some examples of toolbox tests in  `jdk/test/langtools/tools/javac/modules` though I don't have a good example of one that verifies the contents of the class file. Perhaps @vicente-romero-oracle can point to an example?
> 
> it is probably an overkill but method: `testAnnos` in test: `test/langtools/tools/javac/records/RecordCompilationTests.java` is an example applied to records that could be adapted to what we want here

I added two test cases. Thank you for taking the time to review.

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

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

From darcy at openjdk.java.net  Fri Dec 11 18:27:56 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 11 Dec 2020 18:27:56 GMT
Subject: [jdk16] RFR: 8258060: Update @jls tags for renamed/renumbered
 sections
In-Reply-To: <crb0yWrZFXGe1W1GLNvu9l1NfBskqRlf90ZazKKiDQU=.d7343840-29a9-4735-a013-2b9236c15546@github.com>
References: <YWZLQVS61WrZYBrlxT4af5se4AdLkQXlzFXyaGpKqpY=.81bd8c16-2127-4842-916e-987f51856bba@github.com>
 <crb0yWrZFXGe1W1GLNvu9l1NfBskqRlf90ZazKKiDQU=.d7343840-29a9-4735-a013-2b9236c15546@github.com>
Message-ID: <ol-IIUecmHvrnkRCz0lbyV7UepaZTNoBfii7z6JVuqs=.c5895c6f-1f33-4397-a901-f83e55d18163@github.com>

On Thu, 10 Dec 2020 22:58:55 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Given upcoming changes in the JLS terminology around the term "type", various sections were renamed:
>> 
>>     https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html
>> 
>> The @jls tags in the java.compiler module which refer to the renamed sections should be updated.
>
> src/java.compiler/share/classes/javax/lang/model/AnnotatedConstruct.java line 187:
> 
>> 185:      * @see MirroredTypeException
>> 186:      * @see MirroredTypesException
>> 187:      * @jls 9.6.1 Annotation Elements
> 
> Slightly surprising... but I agree that it matches JLS

Alex confirmed off-list that the intended title for that section is "Annotation Interface Elements"; I'll make the adjustment and get the change integrated.
Thanks.

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

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

From darcy at openjdk.java.net  Fri Dec 11 18:37:13 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 11 Dec 2020 18:37:13 GMT
Subject: [jdk16] RFR: 8258060: Update @jls tags for renamed/renumbered
 sections [v2]
In-Reply-To: <YWZLQVS61WrZYBrlxT4af5se4AdLkQXlzFXyaGpKqpY=.81bd8c16-2127-4842-916e-987f51856bba@github.com>
References: <YWZLQVS61WrZYBrlxT4af5se4AdLkQXlzFXyaGpKqpY=.81bd8c16-2127-4842-916e-987f51856bba@github.com>
Message-ID: <5WnTD0ebQQQS0UIxSvNWB1uvUVeU01WECmPbllpanCY=.54f482b3-8959-46b8-9d4d-b0c9bb4f93e7@github.com>

> Given upcoming changes in the JLS terminology around the term "type", various sections were renamed:
> 
>     https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html
> 
> The @jls tags in the java.compiler module which refer to the renamed sections should be updated.

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

  Change title of 9.6.1 to future section title.

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/4/files
  - new: https://git.openjdk.java.net/jdk16/pull/4/files/9985bdbd..867cd123

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

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

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

From darcy at openjdk.java.net  Fri Dec 11 18:42:57 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 11 Dec 2020 18:42:57 GMT
Subject: [jdk16] Integrated: 8258060: Update @jls tags for renamed/renumbered
 sections
In-Reply-To: <YWZLQVS61WrZYBrlxT4af5se4AdLkQXlzFXyaGpKqpY=.81bd8c16-2127-4842-916e-987f51856bba@github.com>
References: <YWZLQVS61WrZYBrlxT4af5se4AdLkQXlzFXyaGpKqpY=.81bd8c16-2127-4842-916e-987f51856bba@github.com>
Message-ID: <A6gw78a8XXOIYRL9glE2JiAfIACdjAMpLlhPbCbst5A=.f342f053-16a7-4903-a4b9-8a895fc84805@github.com>

On Thu, 10 Dec 2020 22:25:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Given upcoming changes in the JLS terminology around the term "type", various sections were renamed:
> 
>     https://download.java.net/java/early_access/jdk16/docs/specs/class-terminology-jls.html
> 
> The @jls tags in the java.compiler module which refer to the renamed sections should be updated.

This pull request has now been integrated.

Changeset: a2801829
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/a2801829
Stats:     12 lines in 6 files changed: 0 ins; 0 del; 12 mod

8258060: Update @jls tags for renamed/renumbered sections

Reviewed-by: jjg, abuckley

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

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

From herrick at openjdk.java.net  Fri Dec 11 18:43:55 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 11 Dec 2020 18:43:55 GMT
Subject: Withdrawn: JDK-8257539: tools/jpackage/windows/WinL10nTest.java
 unpack.bat failed with Exit code: 1618
In-Reply-To: <RB0t2t8DmPX1d5Xvhb6JqnSkROKwB31WL77I-8Pi3cU=.f6d55f17-bc58-4faa-a1ac-92bb6320a118@github.com>
References: <RB0t2t8DmPX1d5Xvhb6JqnSkROKwB31WL77I-8Pi3cU=.f6d55f17-bc58-4faa-a1ac-92bb6320a118@github.com>
Message-ID: <zvIFwgHB8DT-0za_g0T9Xn1U-7cYNuLgiPn_E9snb-Y=.79e4391c-1b4c-4cfd-8757-4649726edc17@github.com>

On Mon, 7 Dec 2020 20:29:56 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> increase retries and timeout increasing in runMsiexecWithRetries

This pull request has been closed without being integrated.

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

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

From darcy at openjdk.java.net  Sat Dec 12 19:28:01 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 12 Dec 2020 19:28:01 GMT
Subject: RFR: 8257457: Update --release 16 symbol information for JDK 16 build
 28
Message-ID: <Elq62hhHZUULrEc2m4n0EmQdr1xaqEVFfB3EPntDVVA=.4e4f7517-af96-4f2e-ab40-cf0a7e6962da@github.com>

Update symbol information for --release 16 to JDK 16 b28, includes updates for JEP 390.

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

Commit messages:
 - 8257457

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

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

From jjg at openjdk.java.net  Sun Dec 13 00:25:07 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sun, 13 Dec 2020 00:25:07 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search
Message-ID: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>

This is for JDK16, as a precursor to fixing JDK-8258002.

While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.

The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.

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

Commit messages:
 - JDK-8247994: Localize javadoc search

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

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

From jjg at openjdk.java.net  Sun Dec 13 00:25:08 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sun, 13 Dec 2020 00:25:08 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search
In-Reply-To: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
Message-ID: <Qw4H-xSPXjuND9jttEWDaJ3q_Fs3m0ckeMwtASd9KKQ=.3e47de4c-4090-4f8c-8f6b-5e15d8f4b077@github.com>

On Sun, 13 Dec 2020 00:19:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> This is for JDK16, as a precursor to fixing JDK-8258002.
> 
> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
> 
> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.

make/CompileInterimLangtools.gmk line 77:

> 75:           Standard.java, \
> 76:       EXTRA_FILES := $(BUILDTOOLS_OUTPUTDIR)/gensrc/$1.interim/module-info.java, \
> 77:       COPY := .gif .png .xml .css .js .js.template .txt javax.tools.JavaCompilerTool, \

Build-folk: it would be nice if this macro could use `$(jdk.javadoc_COPY)` instead of having to duplicate entries.
(Future RFE?)

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Sun Dec 13 14:25:03 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sun, 13 Dec 2020 14:25:03 GMT
Subject: RFR: 8230623: Extract command-line help for -Xlint sub-options to new
 --help-lint
Message-ID: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>

Hi all,

This patch splits out the concrete keys of -Xlint into a new option, --help-lint, 
so that the output of --help-extra is kept clean and concise.

Thank you for taking the time to review.

Best Regards.

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

Commit messages:
 - 8230623: Extract command-line help for -Xlint sub-options to new --help-lint

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

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

From hannesw at openjdk.java.net  Mon Dec 14 09:52:59 2020
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 14 Dec 2020 09:52:59 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search
In-Reply-To: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
Message-ID: <h4L7gwb3BEtV6LBW0MrXnCCuYsqclJw3czHLDHDzv2U=.e1a66d2b-7be5-41d7-90e5-be116ed55caf@github.com>

On Sun, 13 Dec 2020 00:19:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> This is for JDK16, as a precursor to fixing JDK-8258002.
> 
> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
> 
> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.

Looks good in general. `<Unnamed>` shouldn't be localized as it is an internal tag (see inline comment).

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js.template line 40:

> 38: var MIN_RESULTS = 3;
> 39: var MAX_RESULTS = 500;
> 40: var UNNAMED = "##REPLACE:doclet.search.unnamed##";

`<Unnamed>` is not a string that is ever shown to the user, it is what is used by javadoc to denote the default package (see `toolkit.util.DocletConstants.DEFAULT_PACKAGE_NAME`). This variable shouldn't be localized as that would break behaviour for code in the default package (and show the localized string as package name, instead of no package name).

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFile.java line 256:

> 254:                 sb.append(resources.getText(m.group("key")));
> 255:             } catch (MissingResourceException e) {
> 256:                 sb.append(m.group());

Shouldn't we propagate an error here, or issue a warning? If a key is missing localized properties the value from default properties should be used, so this should never happen, right?

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

Changes requested by hannesw (Reviewer).

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

From hannesw at openjdk.java.net  Mon Dec 14 09:58:56 2020
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 14 Dec 2020 09:58:56 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search
In-Reply-To: <h4L7gwb3BEtV6LBW0MrXnCCuYsqclJw3czHLDHDzv2U=.e1a66d2b-7be5-41d7-90e5-be116ed55caf@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
 <h4L7gwb3BEtV6LBW0MrXnCCuYsqclJw3czHLDHDzv2U=.e1a66d2b-7be5-41d7-90e5-be116ed55caf@github.com>
Message-ID: <KALg26trMSMSixmSapr3eujUWZE1bpeppZzzl6EzJF4=.0e009ea3-34b5-4730-a5e8-ddc99e9fb36b@github.com>

On Mon, 14 Dec 2020 09:34:31 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> This is for JDK16, as a precursor to fixing JDK-8258002.
>> 
>> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
>> 
>> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocFile.java line 256:
> 
>> 254:                 sb.append(resources.getText(m.group("key")));
>> 255:             } catch (MissingResourceException e) {
>> 256:                 sb.append(m.group());
> 
> Shouldn't we propagate an error here, or issue a warning? If a key is missing localized properties the value from default properties should be used, so this should never happen, right?

I see the added check for "##REPLACE:" in TestSearch.java will catch that case, so I guess it's ok.

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

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

From jwilhelm at openjdk.java.net  Tue Dec 15 03:43:15 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 15 Dec 2020 03:43:15 GMT
Subject: Integrated: Merge jdk16
In-Reply-To: <2Yx43vz64GrneweTv0nw17cuOAEzWPovF7LZ8AkDsME=.932a0aa9-2c4b-4949-bb66-c059f3942091@github.com>
References: <2Yx43vz64GrneweTv0nw17cuOAEzWPovF7LZ8AkDsME=.932a0aa9-2c4b-4949-bb66-c059f3942091@github.com>
Message-ID: <YDDhTdRzo8khlVw3vZZ6X1D0sz8g2OvS7GA8wJrT4jc=.bd8786cc-d03d-4a59-95b6-76df7f1fbfae@github.com>

On Tue, 15 Dec 2020 03:37:23 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Merge change from JDK 16

This pull request has now been integrated.

Changeset: 381021ae
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/381021ae
Stats:     875 lines in 42 files changed: 644 ins; 154 del; 77 mod

Merge

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

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

From jwilhelm at openjdk.java.net  Tue Dec 15 03:43:14 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 15 Dec 2020 03:43:14 GMT
Subject: Integrated: Merge jdk16
Message-ID: <2Yx43vz64GrneweTv0nw17cuOAEzWPovF7LZ8AkDsME=.932a0aa9-2c4b-4949-bb66-c059f3942091@github.com>

Merge change from JDK 16

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

Commit messages:
 - Merge
 - 8258094: AIX build fails after 8257602
 - 8258092: Link to early access platform documentation in TestHtmlTableTags.java
 - 8254350: CompletableFuture.get may swallow InterruptedException
 - 8258111: Problemlist compiler/blackhole tests for -Xcomp until JDK-8258101 is fixed
 - 8257596: Clarify trusted final fields for record classes
 - 8257919: [JVMCI] profiling info didn't change after reprofile
 - 8257598: Clarify what component values are used in Record::equals
 - 8258060: Update @jls tags for renamed/renumbered sections
 - 8256641: CDS VM operations do not lock the heap
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/2c3ae19a...b0ad1bcd

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

Changes: https://git.openjdk.java.net/jdk/pull/1775/files
  Stats: 875 lines in 42 files changed: 644 ins; 154 del; 77 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1775.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1775/head:pull/1775

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

From ysatowse at openjdk.java.net  Tue Dec 15 07:26:15 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Tue, 15 Dec 2020 07:26:15 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v2]
In-Reply-To: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
Message-ID: <HvlYLiUQXFTip93rpKXiNrJfbZeaFBZ-hvoqBR3OgTw=.f419490f-4206-4b52-85ee-f85d5eebd408@github.com>

> HTML4 is no longer supported in javadoc.
> 
> doclint needs to drop HTML4 support as well.
> The changes consist of:
> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
> * Modifying test code and expected outputs to be checked in HTML5

Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:

  8257204 and 8256313
  8257204: Remove usage of -Xhtmlversion option from javac
  8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/893/files
  - new: https://git.openjdk.java.net/jdk/pull/893/files/4b733399..294b3cce

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

  Stats: 182 lines in 9 files changed: 0 ins; 71 del; 111 mod
  Patch: https://git.openjdk.java.net/jdk/pull/893.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/893/head:pull/893

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

From ysatowse at openjdk.java.net  Tue Dec 15 07:30:59 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Tue, 15 Dec 2020 07:30:59 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v2]
In-Reply-To: <n2ea4PoUtsEtADcdUM3AkkrO22AT2Tn4nJo2TspgK54=.3d72d7f6-3ce5-4aa3-a2aa-3f49c51b83b1@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <RAdVAZpFjoxQnDj02FVOpgugTaQuNd-LMzpKXeu4VEU=.465404f4-4737-4ec2-b7b5-1681b6471698@github.com>
 <n2ea4PoUtsEtADcdUM3AkkrO22AT2Tn4nJo2TspgK54=.3d72d7f6-3ce5-4aa3-a2aa-3f49c51b83b1@github.com>
Message-ID: <49zhTArZTN6JEApqmuxnSz-_9Jdiuvu8WKuSOTd6fRk=.0345e583-8e0a-4589-8c89-92df7b164013@github.com>

On Fri, 11 Dec 2020 06:44:57 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> Please make the review non-draft as well
>
> Thanks for reviewing @jonathan-gibbons 
> This request should have got changed to "non-draft".
> 
> FYI. all tests in jdk-tier1 are still green with the latest changes.
> https://mach5.us.oracle.com/mdash/jobs/yoshiki-jdk-20201211-0555-16616611

This commit includes the changes for 
8257204: Remove usage of -Xhtmlversion option from javac
8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option

The changes presume the changes made by a 8247957.   And there is no need to separate them from 8247957, so I would like to pull all changes into this.

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

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

From ihse at openjdk.java.net  Tue Dec 15 09:24:01 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 09:24:01 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v2]
In-Reply-To: <HvlYLiUQXFTip93rpKXiNrJfbZeaFBZ-hvoqBR3OgTw=.f419490f-4206-4b52-85ee-f85d5eebd408@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <HvlYLiUQXFTip93rpKXiNrJfbZeaFBZ-hvoqBR3OgTw=.f419490f-4206-4b52-85ee-f85d5eebd408@github.com>
Message-ID: <Yfps7QXZ65d-qGqLGp30xpflAFAwxOXt0FCSPJCBZy4=.27fbdd12-998a-4dbe-8007-9fa02281505c@github.com>

On Tue, 15 Dec 2020 07:26:15 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> HTML4 is no longer supported in javadoc.
>> 
>> doclint needs to drop HTML4 support as well.
>> The changes consist of:
>> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
>> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
>> * Modifying test code and expected outputs to be checked in HTML5
>
> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8257204 and 8256313
>   8257204: Remove usage of -Xhtmlversion option from javac
>   8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option

Build change look fine. I have not looked at the other changes.

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

Marked as reviewed by ihse (Reviewer).

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

From ihse at openjdk.java.net  Tue Dec 15 09:27:59 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 09:27:59 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search
In-Reply-To: <Qw4H-xSPXjuND9jttEWDaJ3q_Fs3m0ckeMwtASd9KKQ=.3e47de4c-4090-4f8c-8f6b-5e15d8f4b077@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
 <Qw4H-xSPXjuND9jttEWDaJ3q_Fs3m0ckeMwtASd9KKQ=.3e47de4c-4090-4f8c-8f6b-5e15d8f4b077@github.com>
Message-ID: <Qa53ZO70gbtLBFhijs-2nPk-ZwMppxBjMZYBQiU4XGs=.54878d14-e980-43ea-8713-b0c27781f7a7@github.com>

On Sun, 13 Dec 2020 00:22:04 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This is for JDK16, as a precursor to fixing JDK-8258002.
>> 
>> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
>> 
>> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.
>
> make/CompileInterimLangtools.gmk line 77:
> 
>> 75:           Standard.java, \
>> 76:       EXTRA_FILES := $(BUILDTOOLS_OUTPUTDIR)/gensrc/$1.interim/module-info.java, \
>> 77:       COPY := .gif .png .xml .css .js .js.template .txt javax.tools.JavaCompilerTool, \
> 
> Build-folk: it would be nice if this macro could use `$(jdk.javadoc_COPY)` instead of having to duplicate entries.
> (Future RFE?)

I agree. The entire design of CompileJavaModules.gmk needs to be updated. I've been procrastinating on cleaning this up, maybe it's time to get going on it...

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

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

From ihse at openjdk.java.net  Tue Dec 15 09:27:57 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 09:27:57 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search
In-Reply-To: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
Message-ID: <EPayynUeJDI3wH52uEQvXuGsoroPkiJ8KkWEqlVo9N8=.dcb277f7-d889-4568-8157-b7f8d6214153@github.com>

On Sun, 13 Dec 2020 00:19:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> This is for JDK16, as a precursor to fixing JDK-8258002.
> 
> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
> 
> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.

Build changes look good.

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

Marked as reviewed by ihse (Reviewer).

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

From jfranck at openjdk.java.net  Tue Dec 15 15:04:57 2020
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Tue, 15 Dec 2020 15:04:57 GMT
Subject: RFR: 8254023: A module declaration is not allowed to be a target
 of an annotation that lacks an @Target meta-annotation
In-Reply-To: <QzcPBDfL1gbJ27__AzwRzYJ2g_LSBpXY_feRiGsg0Aw=.b92150d1-8906-45d5-aa58-08b04ab6cd70@github.com>
References: <wFdu9AyyNU2SB0nWx9mq_2syF2XyQIB0z6Rmc-r1fNc=.369439d1-385e-4fd1-aac1-72e48ac246e8@github.com>
 <pqSfmocPi4AJGQJEJl4j6UgITEL0f62TKSVpxwOer6w=.49e74a9b-ecb0-4a13-9dfc-93c27fd5149a@github.com>
 <5_HZhCK8rd2yWcf4XzGa_N50I1Xl3CMmUXSugfoJIUk=.379b61e3-e4a3-4509-ac7b-940a25ae4609@github.com>
 <6VDsNZKAYnkmm_YsLRjClBhqPMPPqy4d3TrWLcElkOU=.3f9b9d49-4e49-4574-a07c-6f72acefcfd2@github.com>
 <tBB2q0ATDEr8k86St14cqLVTAwy2CH34WolOWfPH1bw=.e9a456ad-28c8-4e36-9eb4-62024a96c0e4@github.com>
 <55-uvNq2QGWKbTD3uVotqaRdbInO5Ih0L462CR7cnGc=.4a2912dd-6868-4290-9e39-2c5f50cf4ca2@github.com>
 <CMHxOHQvUOHVPAkk0TR1N5pyLFoWN6wlDDX4y-vs5Q8=.b3da3476-d256-4011-afae-f6235bbcee45@github.com>
 <DYE5Xh2_FehT4qZpjTdxeNSd57IGxB0cpVVIQP0g-5o=.55c2c0b8-f9b9-4ce1-a834-6538a1cc3ecf@github.com>
 <QzcPBDfL1gbJ27__AzwRzYJ2g_LSBpXY_feRiGsg0Aw=.b92150d1-8906-45d5-aa58-08b04ab6cd70@github.com>
Message-ID: <TQrf2FfVIWQciI3F_lUKBzzPuESOQpcSQ9E6si9FWGI=.141de789-7622-40c5-9167-4bbc3dd8e0df@github.com>

On Fri, 11 Dec 2020 16:32:23 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>>> Hi,
>>> 
>>> I don't think TargetAnnoCombo should be updated, at least not for this fix. It is an old hard to understand test that predates modules.
>>> 
>>> It would be good to do further testing as Vicente writes. I suggest:
>>> 
>>>     1. A test that the module info compiles, you already have this.
>>> 
>>>     2. A test that the class file contains the bytes for the annotation might make sense. As Jon has pointed out in different review threads there is the toolbox, perhaps that could be of use? There are some examples of toolbox tests in  `jdk/test/langtools/tools/javac/modules` though I don't have a good example of one that verifies the contents of the class file. Perhaps @vicente-romero-oracle can point to an example?
>> 
>> it is probably an overkill but method: `testAnnos` in test: `test/langtools/tools/javac/records/RecordCompilationTests.java` is an example applied to records that could be adapted to what we want here
>
> I added two test cases. Thank you for taking the time to review.

Hi @lgxbslgx 

This looks good to me. Since this is targeted to Java 16 we need to close this PR and open a new PR towards the JDK16 project and finish the review there, add a link back to this PR would also be neat. Can you do that?

cheers

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

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

From jjg at openjdk.java.net  Tue Dec 15 17:15:57 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 15 Dec 2020 17:15:57 GMT
Subject: RFR: 8257457: Update --release 16 symbol information for JDK 16
 build 28
In-Reply-To: <Elq62hhHZUULrEc2m4n0EmQdr1xaqEVFfB3EPntDVVA=.4e4f7517-af96-4f2e-ab40-cf0a7e6962da@github.com>
References: <Elq62hhHZUULrEc2m4n0EmQdr1xaqEVFfB3EPntDVVA=.4e4f7517-af96-4f2e-ab40-cf0a7e6962da@github.com>
Message-ID: <2befjAuobDjYBkRwVwVioUPxe6zE0-FWNtHR2aeNAkA=.430f2144-5668-4427-8a94-503cf5f0fd51@github.com>

On Sat, 12 Dec 2020 19:23:31 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update symbol information for --release 16 to JDK 16 b28, includes updates for JEP 390.

Looks reasonable

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

Marked as reviewed by jjg (Reviewer).

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

From darcy at openjdk.java.net  Tue Dec 15 17:21:56 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 15 Dec 2020 17:21:56 GMT
Subject: Integrated: 8257457: Update --release 16 symbol information for JDK
 16 build 28
In-Reply-To: <Elq62hhHZUULrEc2m4n0EmQdr1xaqEVFfB3EPntDVVA=.4e4f7517-af96-4f2e-ab40-cf0a7e6962da@github.com>
References: <Elq62hhHZUULrEc2m4n0EmQdr1xaqEVFfB3EPntDVVA=.4e4f7517-af96-4f2e-ab40-cf0a7e6962da@github.com>
Message-ID: <VLTvk4mHpGRJHtGajIS8fmipoZOsl03J_hmVoMtMz-I=.6cbe7799-9240-4edd-896e-d499da815c98@github.com>

On Sat, 12 Dec 2020 19:23:31 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Update symbol information for --release 16 to JDK 16 b28, includes updates for JEP 390.

This pull request has now been integrated.

Changeset: da2415fe
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/da2415fe
Stats:     235 lines in 4 files changed: 149 ins; 2 del; 84 mod

8257457: Update --release 16 symbol information for JDK 16 build 28

Reviewed-by: jjg

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

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

From ihse at openjdk.java.net  Tue Dec 15 22:40:53 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 22:40:53 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v3]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <ZQKkeZnC0DkuVXm10pUBOC7eHbUSXleDRyOTUHMrW5k=.07290ec9-fd83-46bc-81bb-3b6423327507@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [ ] java.base
> - [ ] java.desktop
> - [x] jdk.compiler
> - [ ] java.se

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Move macosxicons from share to macosx

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/f0047704..00dc61c1

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

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

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

From ihse at openjdk.java.net  Tue Dec 15 22:56:15 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 22:56:15 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v4]
In-Reply-To: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
Message-ID: <P54jHV9ifEGcludGjn9XLu-RcsAVN-OkRKK7GgIeYwM=.d700b73e-5ce2-49d4-b247-1e7957828754@github.com>

> A lot (but not all) of the data in make/data is tied to a specific module. For instance, the publicsuffixlist is used by java.base, and fontconfig by java.desktop. (A few directories, like mainmanifest, is *actually* used by make for the whole build.) 
> 
> These data files should move to the module they belong to. The are, after all, "source code" for that module that is "compiler" into resulting deliverables, for that module. (But the "source code" language is not Java or C, but typically a highly domain specific language or data format, and the "compilation" is, often, a specialized transformation.) 
> 
> This misplacement of the data directory is most visible at code review time. When such data is changed, most of the time build-dev (or the new build label) is involved, even though this has nothing to do with the build. While this is annoying, a worse problem is if the actual team that needs to review the patch (i.e., the team owning the module) is missed in the review.
> 
> ### Modules reviewed
> 
> - [x] java.base
> - [ ] java.desktop
> - [x] jdk.compiler
> - [x] java.se

Magnus Ihse Bursie 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 eight additional commits since the last revision:

 - Update comment refering to "make" dir
 - Move new symbols to jdk.compiler
 - Merge branch 'master' into shuffle-data
 - Move macosxicons from share to macosx
 - Move to share/data, and move jdwp.spec to java.se
 - Update references in test
 - Step 2: Update references
 - First stage, move actual data files

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1611/files
  - new: https://git.openjdk.java.net/jdk/pull/1611/files/00dc61c1..68b252b5

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

  Stats: 38451 lines in 948 files changed: 28535 ins; 6611 del; 3305 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1611.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1611/head:pull/1611

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

From ihse at openjdk.java.net  Tue Dec 15 22:56:16 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 15 Dec 2020 22:56:16 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>
Message-ID: <DiSgNY-0Nd9gh1-fjY4t8pB-85UZVXoYtWw7XQOdaVs=.33f97c0a-0be0-4f5a-9ffc-e4c0f831072f@github.com>

On Thu, 10 Dec 2020 23:07:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move to share/data, and move jdwp.spec to java.se
>
> Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`, `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good overall.

I think this is almost ready to be pushed, but I'd like to have someone from the client team review the changes for java.desktop as well. @prrace Any change you can have a look at this?

> test/jdk/java/util/Locale/LSRDataTest.java line 57:
> 
>> 55:     // path to the lsr file from the make folder, this test relies on the
>> 56:     // relative path to the file in the make folder, considering
>> 57:     // test and make will always exist in the same jdk layout
> 
> The comment refers to the "make" folder. (line 55 as well).

Fixed. Thank you for noticing!

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

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

From jjg at openjdk.java.net  Wed Dec 16 00:52:02 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 16 Dec 2020 00:52:02 GMT
Subject: [jdk16] RFR: JDK-8241353: NPE in ToolProvider.getSystemJavaCompiler
Message-ID: <8ukjRsTwt_ErlBVJ8zPoauFkZy35iI-Ejo2teLhttKc=.57c8a70e-35ad-4aa6-ae74-f8a95f4e5cfb@github.com>

Trivial fix to avoid NPE by using `Objects.equals` instead of direct `String.equals`

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

Commit messages:
 - JDK-8241353: NPE in ToolProvider.getSystemJavaCompiler

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

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

From vromero at openjdk.java.net  Wed Dec 16 01:22:56 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 16 Dec 2020 01:22:56 GMT
Subject: [jdk16] RFR: JDK-8241353: NPE in
 ToolProvider.getSystemJavaCompiler
In-Reply-To: <8ukjRsTwt_ErlBVJ8zPoauFkZy35iI-Ejo2teLhttKc=.57c8a70e-35ad-4aa6-ae74-f8a95f4e5cfb@github.com>
References: <8ukjRsTwt_ErlBVJ8zPoauFkZy35iI-Ejo2teLhttKc=.57c8a70e-35ad-4aa6-ae74-f8a95f4e5cfb@github.com>
Message-ID: <ZvpJsbYcgMdagHp_hEntpoYigu3IrSRMbwk5BDg_k8Q=.524c48e5-941c-4b37-96d7-74078c0cf660@github.com>

On Wed, 16 Dec 2020 00:46:38 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Trivial fix to avoid NPE by using `Objects.equals` instead of direct `String.equals`

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From ysatowse at openjdk.java.net  Wed Dec 16 02:09:00 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Wed, 16 Dec 2020 02:09:00 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v2]
In-Reply-To: <Yfps7QXZ65d-qGqLGp30xpflAFAwxOXt0FCSPJCBZy4=.27fbdd12-998a-4dbe-8007-9fa02281505c@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <HvlYLiUQXFTip93rpKXiNrJfbZeaFBZ-hvoqBR3OgTw=.f419490f-4206-4b52-85ee-f85d5eebd408@github.com>
 <Yfps7QXZ65d-qGqLGp30xpflAFAwxOXt0FCSPJCBZy4=.27fbdd12-998a-4dbe-8007-9fa02281505c@github.com>
Message-ID: <8zKt8T3B6UDl5dUP47zJZXAj9PDCuZkO3AsrK1qmfHg=.50d5af51-f1bd-42e8-9852-983ae52a2390@github.com>

On Tue, 15 Dec 2020 09:20:44 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8257204 and 8256313
>>   8257204: Remove usage of -Xhtmlversion option from javac
>>   8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option
>
> Build change look fine. I have not looked at the other changes.

I found an issue when called from javac, so will convert to draft until the issue resolved.

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

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

From smarks at openjdk.java.net  Wed Dec 16 03:38:01 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 16 Dec 2020 03:38:01 GMT
Subject: RFR: 8258455: problem list
 =?UTF-8?B?dG9vbHMvamRlcHJzY2FuL3Rlc3RzL2pkay9qZGVwcnNjYW4vVGVzdFJlbGVhc2XigKY=?=
Message-ID: <pOgyhnxVdoKQirtHvS4SQiWUUZsKnOXlWY3LhZCLmCk=.37a9d6fc-a6e0-4ca8-bb50-cc7dc5c4b6c9@github.com>

?.java

Add to problem list to avoid tier1 CI failures.

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

Commit messages:
 - 8258455: problem list tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java

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

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

From dholmes at openjdk.java.net  Wed Dec 16 04:06:56 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 16 Dec 2020 04:06:56 GMT
Subject: RFR: 8258455: problem list
 =?UTF-8?B?dG9vbHMvamRlcHJzY2FuL3Rlc3RzL2pkay9qZGVwcnNjYW4vVGVzdFJlbGVhc2XigKY=?=
In-Reply-To: <pOgyhnxVdoKQirtHvS4SQiWUUZsKnOXlWY3LhZCLmCk=.37a9d6fc-a6e0-4ca8-bb50-cc7dc5c4b6c9@github.com>
References: <pOgyhnxVdoKQirtHvS4SQiWUUZsKnOXlWY3LhZCLmCk=.37a9d6fc-a6e0-4ca8-bb50-cc7dc5c4b6c9@github.com>
Message-ID: <CjkfQtmewJhGbr_4X9_3yc2oxsbo4YMdGvxuAuRH0l8=.127e1262-96af-446f-8552-6fc9f0b63e86@github.com>

On Wed, 16 Dec 2020 03:33:01 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> ?.java
> 
> Add to problem list to avoid tier1 CI failures.

Looks good.

Thanks for fixing.

David

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

Marked as reviewed by dholmes (Reviewer).

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

From darcy at openjdk.java.net  Wed Dec 16 04:10:55 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 16 Dec 2020 04:10:55 GMT
Subject: RFR: 8258455: problem list
 =?UTF-8?B?dG9vbHMvamRlcHJzY2FuL3Rlc3RzL2pkay9qZGVwcnNjYW4vVGVzdFJlbGVhc2XigKY=?=
In-Reply-To: <pOgyhnxVdoKQirtHvS4SQiWUUZsKnOXlWY3LhZCLmCk=.37a9d6fc-a6e0-4ca8-bb50-cc7dc5c4b6c9@github.com>
References: <pOgyhnxVdoKQirtHvS4SQiWUUZsKnOXlWY3LhZCLmCk=.37a9d6fc-a6e0-4ca8-bb50-cc7dc5c4b6c9@github.com>
Message-ID: <J_01S1Ypy-nMOkZob7v-RCqzWrTYg_Vjj9io4UsPX4Y=.cd68d490-ca7f-4d62-9f83-380f92bb493c@github.com>

On Wed, 16 Dec 2020 03:33:01 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> ?.java
> 
> Add to problem list to avoid tier1 CI failures.

Marked as reviewed by darcy (Reviewer).

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

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

From smarks at openjdk.java.net  Wed Dec 16 04:16:55 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 16 Dec 2020 04:16:55 GMT
Subject: Integrated: 8258455: problem list
 tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java
In-Reply-To: <pOgyhnxVdoKQirtHvS4SQiWUUZsKnOXlWY3LhZCLmCk=.37a9d6fc-a6e0-4ca8-bb50-cc7dc5c4b6c9@github.com>
References: <pOgyhnxVdoKQirtHvS4SQiWUUZsKnOXlWY3LhZCLmCk=.37a9d6fc-a6e0-4ca8-bb50-cc7dc5c4b6c9@github.com>
Message-ID: <TbYXwEjehHEou2pngFSUoHLngQl4XBT_2kcOG7Qfqqo=.b3734f5d-6ec5-43d7-9fbd-7b76ebd8c8f4@github.com>

On Wed, 16 Dec 2020 03:33:01 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Add to problem list to avoid tier1 CI failures.

This pull request has now been integrated.

Changeset: 47ba652d
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/47ba652d
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8258455: problem list tools/jdeprscan/tests/jdk/jdeprscan/TestRelease.java

Reviewed-by: dholmes, darcy

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

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

From alanb at openjdk.java.net  Wed Dec 16 10:15:56 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 16 Dec 2020 10:15:56 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <DiSgNY-0Nd9gh1-fjY4t8pB-85UZVXoYtWw7XQOdaVs=.33f97c0a-0be0-4f5a-9ffc-e4c0f831072f@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>
 <DiSgNY-0Nd9gh1-fjY4t8pB-85UZVXoYtWw7XQOdaVs=.33f97c0a-0be0-4f5a-9ffc-e4c0f831072f@github.com>
Message-ID: <uvB3UkBf7i3AU7udOQzQDjSYNngy6SwXTLJ1xiD8iXA=.aa3c5c81-e6c9-4ca2-a39f-c9918e61648d@github.com>

On Tue, 15 Dec 2020 22:52:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`, `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good overall.
>
> I think this is almost ready to be pushed, but I'd like to have someone from the client team review the changes for java.desktop as well. @prrace Any change you can have a look at this?

I think it will be annoying to have the charset mapping tables and other data in the src tree, have you looked at other alternatives?

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Wed Dec 16 12:08:10 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Wed, 16 Dec 2020 12:08:10 GMT
Subject: [jdk16] RFR: 8254023: A module declaration is not allowed to be a
 target of an annotation that lacks an @Target meta-annotation
Message-ID: <BzOpe0tf6KMcHXh9WLjl91lVXtsLg-4YhC5evsVskM8=.cffed619-e078-4be1-88bd-d969d9981088@github.com>

Hi all,

This patch adds `names.MODULE` to `com.sun.tools.javac.comp.Check.dfltTargetMeta` to fix this issue. And it also adds some corresponding tests.

The previous discussion is in https://github.com/openjdk/jdk/pull/622.

Best Regards.

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

Commit messages:
 - 8254023: A module declaration is not allowed to be a target of an annotation that lacks an @Target meta-annotation

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Wed Dec 16 12:09:55 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Wed, 16 Dec 2020 12:09:55 GMT
Subject: RFR: 8254023: A module declaration is not allowed to be a target
 of an annotation that lacks an @Target meta-annotation
In-Reply-To: <TQrf2FfVIWQciI3F_lUKBzzPuESOQpcSQ9E6si9FWGI=.141de789-7622-40c5-9167-4bbc3dd8e0df@github.com>
References: <wFdu9AyyNU2SB0nWx9mq_2syF2XyQIB0z6Rmc-r1fNc=.369439d1-385e-4fd1-aac1-72e48ac246e8@github.com>
 <pqSfmocPi4AJGQJEJl4j6UgITEL0f62TKSVpxwOer6w=.49e74a9b-ecb0-4a13-9dfc-93c27fd5149a@github.com>
 <5_HZhCK8rd2yWcf4XzGa_N50I1Xl3CMmUXSugfoJIUk=.379b61e3-e4a3-4509-ac7b-940a25ae4609@github.com>
 <6VDsNZKAYnkmm_YsLRjClBhqPMPPqy4d3TrWLcElkOU=.3f9b9d49-4e49-4574-a07c-6f72acefcfd2@github.com>
 <tBB2q0ATDEr8k86St14cqLVTAwy2CH34WolOWfPH1bw=.e9a456ad-28c8-4e36-9eb4-62024a96c0e4@github.com>
 <55-uvNq2QGWKbTD3uVotqaRdbInO5Ih0L462CR7cnGc=.4a2912dd-6868-4290-9e39-2c5f50cf4ca2@github.com>
 <CMHxOHQvUOHVPAkk0TR1N5pyLFoWN6wlDDX4y-vs5Q8=.b3da3476-d256-4011-afae-f6235bbcee45@github.com>
 <DYE5Xh2_FehT4qZpjTdxeNSd57IGxB0cpVVIQP0g-5o=.55c2c0b8-f9b9-4ce1-a834-6538a1cc3ecf@github.com>
 <QzcPBDfL1gbJ27__AzwRzYJ2g_LSBpXY_feRiGsg0Aw=.b92150d1-8906-45d5-aa58-08b04ab6cd70@github.com>
 <TQrf2FfVIWQciI3F_lUKBzzPuESOQpcSQ9E6si9FWGI=.141de789-7622-40c5-9167-4bbc3dd8e0df@github.com>
Message-ID: <UXI2qajwXtoo7GuuzpSZhpYqFaX6UgaptH6Ihe9iM6s=.d9218019-f413-4515-9088-65f1006ab13c@github.com>

On Tue, 15 Dec 2020 15:02:08 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:

>> I added two test cases. Thank you for taking the time to review.
>
> Hi @lgxbslgx 
> 
> This looks good to me. Since this is targeted to Java 16 we need to close this PR and open a new PR towards the JDK16 project and finish the review there, add a link back to this PR would also be neat. Can you do that?
> 
> cheers

@jbf I open a new PR in JDK 16. Please see https://github.com/openjdk/jdk16/pull/34

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

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

From ihse at openjdk.java.net  Wed Dec 16 14:02:57 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 16 Dec 2020 14:02:57 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <uvB3UkBf7i3AU7udOQzQDjSYNngy6SwXTLJ1xiD8iXA=.aa3c5c81-e6c9-4ca2-a39f-c9918e61648d@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>
 <DiSgNY-0Nd9gh1-fjY4t8pB-85UZVXoYtWw7XQOdaVs=.33f97c0a-0be0-4f5a-9ffc-e4c0f831072f@github.com>
 <uvB3UkBf7i3AU7udOQzQDjSYNngy6SwXTLJ1xiD8iXA=.aa3c5c81-e6c9-4ca2-a39f-c9918e61648d@github.com>
Message-ID: <F1TBC8SJ4UagUp3gvVlBcWOmsIHsG6yqbF9-PUFI2mQ=.7ef21145-157f-4871-8045-979284284dce@github.com>

On Wed, 16 Dec 2020 10:12:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I think this is almost ready to be pushed, but I'd like to have someone from the client team review the changes for java.desktop as well. @prrace Any change you can have a look at this?
>
> I think it will be annoying to have the charset mapping tables and other data in the src tree, have you looked at other alternatives?

@AlanBateman Let me re-iterate: the data files are *not* "make" files. It is just as annoying to have team-specific data files in the make tree! So to keep things as they are is not an option. The fact that they currently reside there is just a continuation of the old view of make as a general dumping ground. I've requested this change since before Project Jigsaw. In fact, I opposed Erik's original Jigsaw patch on this ground, among other things. As a compromise, we agreed that it was to be fixed *after* Jigsaw, since that project had already dragged out in time for so long and was blocking the release. (See https://bugs.openjdk.java.net/browse/JDK-8055193 for details.)

So what do you propose for alternative? A new top-level data directory? I mean, sure, we could have like `data/java.base/share/charsetmapping` instead. I personally think that makes less sense. I also think that the person most qualified to judge about charsetmapping is @naotoj, which has already accepted this review as it is.

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

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

From jfranck at openjdk.java.net  Wed Dec 16 14:41:57 2020
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Wed, 16 Dec 2020 14:41:57 GMT
Subject: [jdk16] RFR: 8254023: A module declaration is not allowed to be a
 target of an annotation that lacks an @Target meta-annotation
In-Reply-To: <BzOpe0tf6KMcHXh9WLjl91lVXtsLg-4YhC5evsVskM8=.cffed619-e078-4be1-88bd-d969d9981088@github.com>
References: <BzOpe0tf6KMcHXh9WLjl91lVXtsLg-4YhC5evsVskM8=.cffed619-e078-4be1-88bd-d969d9981088@github.com>
Message-ID: <uLlt-rshFC9WfQCYWEyWltN1drxr8xHY5b0VQ8eiv8E=.d7ef5a3b-0575-49d2-8dab-6575d2d411fa@github.com>

On Wed, 16 Dec 2020 12:02:58 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> This patch adds `names.MODULE` to `com.sun.tools.javac.comp.Check.dfltTargetMeta` to fix this issue. And it also adds some corresponding tests.
> 
> The previous discussion is in https://github.com/openjdk/jdk/pull/622.
> 
> Best Regards.

Can you update your fork to do pre-submit tests and trigger a manual run?

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

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

From jfranck at openjdk.java.net  Wed Dec 16 14:48:59 2020
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Wed, 16 Dec 2020 14:48:59 GMT
Subject: [jdk16] RFR: 8254023: A module declaration is not allowed to be a
 target of an annotation that lacks an @Target meta-annotation
In-Reply-To: <BzOpe0tf6KMcHXh9WLjl91lVXtsLg-4YhC5evsVskM8=.cffed619-e078-4be1-88bd-d969d9981088@github.com>
References: <BzOpe0tf6KMcHXh9WLjl91lVXtsLg-4YhC5evsVskM8=.cffed619-e078-4be1-88bd-d969d9981088@github.com>
Message-ID: <oPMBLcmWB6RX_FwBwn9UUgtZYuO-QYkh4ZmrxlTH4b8=.06c5909f-1a3a-476f-af3f-3357ef552423@github.com>

On Wed, 16 Dec 2020 12:02:58 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> This patch adds `names.MODULE` to `com.sun.tools.javac.comp.Check.dfltTargetMeta` to fix this issue. And it also adds some corresponding tests.
> 
> The previous discussion is in https://github.com/openjdk/jdk/pull/622.
> 
> Best Regards.

Marked as reviewed by jfranck (Reviewer).

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Wed Dec 16 16:35:02 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Wed, 16 Dec 2020 16:35:02 GMT
Subject: [jdk16] RFR: 8254023: A module declaration is not allowed to be a
 target of an annotation that lacks an @Target meta-annotation
In-Reply-To: <oPMBLcmWB6RX_FwBwn9UUgtZYuO-QYkh4ZmrxlTH4b8=.06c5909f-1a3a-476f-af3f-3357ef552423@github.com>
References: <BzOpe0tf6KMcHXh9WLjl91lVXtsLg-4YhC5evsVskM8=.cffed619-e078-4be1-88bd-d969d9981088@github.com>
 <oPMBLcmWB6RX_FwBwn9UUgtZYuO-QYkh4ZmrxlTH4b8=.06c5909f-1a3a-476f-af3f-3357ef552423@github.com>
Message-ID: <kAB2VkpXPmRIuvsJZfVNvgZGlS8g-OgpoN5aQKizhAk=.769ba49f-2f35-4f4a-ba06-90525cad4d78@github.com>

On Wed, 16 Dec 2020 14:46:36 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch adds `names.MODULE` to `com.sun.tools.javac.comp.Check.dfltTargetMeta` to fix this issue. And it also adds some corresponding tests.
>> 
>> The previous discussion is in https://github.com/openjdk/jdk/pull/622.
>> 
>> Best Regards.
>
> Marked as reviewed by jfranck (Reviewer).

> Can you update your fork to do pre-submit tests and trigger a manual run?

Get!

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

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

From vromero at openjdk.java.net  Wed Dec 16 16:59:03 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 16 Dec 2020 16:59:03 GMT
Subject: [jdk16] RFR: 8254023: A module declaration is not allowed to be a
 target of an annotation that lacks an @Target meta-annotation
In-Reply-To: <BzOpe0tf6KMcHXh9WLjl91lVXtsLg-4YhC5evsVskM8=.cffed619-e078-4be1-88bd-d969d9981088@github.com>
References: <BzOpe0tf6KMcHXh9WLjl91lVXtsLg-4YhC5evsVskM8=.cffed619-e078-4be1-88bd-d969d9981088@github.com>
Message-ID: <5o_y97pESv9CctLnboE7joKz1p7C78ww1ch_VCaWJus=.d329d4fe-7474-47f8-acc2-bf9e10ef2a8f@github.com>

On Wed, 16 Dec 2020 12:02:58 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> This patch adds `names.MODULE` to `com.sun.tools.javac.comp.Check.dfltTargetMeta` to fix this issue. And it also adds some corresponding tests.
> 
> The previous discussion is in https://github.com/openjdk/jdk/pull/622.
> 
> Best Regards.

looks good

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

Marked as reviewed by vromero (Reviewer).

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

From jjg at openjdk.java.net  Wed Dec 16 18:29:00 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 16 Dec 2020 18:29:00 GMT
Subject: RFR: JDK-6251738: Want a top-level summary page that itemizes all
 spec documents referenced from javadocs (OEM spec) [v2]
In-Reply-To: <GEwkDW5Hm6vl7P3oQXO80jukkmydlyx4v4rXba7-f3E=.36cc3952-8017-46dc-bfd3-177bcbabe960@github.com>
References: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com>
 <nj16p9kuRLdEcRSAfX6hjkiETqLFM3XJgHzSep950jg=.3b870729-a855-4cae-b510-520d0166ffb3@github.com>
 <GEwkDW5Hm6vl7P3oQXO80jukkmydlyx4v4rXba7-f3E=.36cc3952-8017-46dc-bfd3-177bcbabe960@github.com>
Message-ID: <C1yKyssMIqT_8tC1_JlpF1hMlDBpONw1FjOmPJuY6YA=.9db2227d-fccb-4cc5-8fe8-4da49c1da40c@github.com>

On Thu, 5 Nov 2020 16:16:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Fix merge issues; review feedback
>>  - Merge with master
>>  - allow rich content in createAnchorAndSearchIndex
>>  - update Docs.gmk to stop disabling spec tag
>>  - fix TestSpecTag.testEncodedURI
>>  - fix tests
>>  - remove support to workaround legacy @spec tag
>>  - Merge remote-tracking branch 'upstream/master' into new-spec-tag
>>  - fix trailing whitespace in test
>>  - temporarily allow existing legacy usage `@spec JPMS` `@spec jsr-51`
>>  - ... and 1 more: https://git.openjdk.java.net/jdk/compare/804bd725...ed5512d9
>
> 1. Thanks for incorporating my previous offline feedback.
> 2. Since Hannes and Erik seem to have looked at everything else, I looked mostly at changes in `src/jdk.compiler/share/classes/com/sun/source/**`, which are good!
> 3. There should be a corresponding but separate change to "Documentation Comment Specification for the Standard Doclet".
> 4. Can we use this new `@since` tag to refer to the spec at `com/sun/tools/javac/parser/DocCommentParser.java:1116`?
> 5. Should we specify in `com.sun.source.doctree.SpecTree` that both `url` and `label` parts are mandatory?
> 6. `DCSpec extends DCEndPosTree`, sigh... Although that is not a public API, this design suggests we could improve that abstraction sometime later.

Closing pull request, until we better decide the contents of the spec page

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

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

From jjg at openjdk.java.net  Wed Dec 16 18:29:02 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 16 Dec 2020 18:29:02 GMT
Subject: Withdrawn: JDK-6251738: Want a top-level summary page that itemizes
 all spec documents referenced from javadocs (OEM spec)
In-Reply-To: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com>
References: <6T_odbmLeZsI2_G8H7bcfL8jLi8TUAxc_u6g6OvUBjU=.76eff40f-10f7-4b16-a605-718f528b3e03@github.com>
Message-ID: <_5FMfeDyMMGcBlb5BSM-cA0LsrrJYnIcvggWuUy-yf0=.3e55f9e7-ece2-4809-93bc-6afd433c49e7@github.com>

On Thu, 22 Oct 2020 02:40:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> This introduces support for a new `@spec` tag that can be used as either an inline tag or as a block tag. It is used to identify references to external specifications, in such a way that the references can be collected together on a new summary page, called "Other Specifications", available from either the static INDEX page or the interactive search box.
> 
> As an inline tag, the format is `{@spec url label}`, which is roughly translated to `<a href="url">label</a>` in the generated docs.
> 
> As a block tag, the format is simply
> 
>     @spec url label
> 
> which is handled in a manner analogous to
> 
>     @see <a href="url">label</a>
> 
> The tag is notable for being the first standard/supported tag that can be used as either an inline or block tag. (We have had support for bimodal non-standard/custom tags for a while, such as `{@jls}` and `{@jvms}`.) To support bimodal standard tags, some changes to `DocCommentParser` are incorporated here.
> 
> This change is only the _support_ for the new tag;  it does _not_ include any changes to API docs to _use_ the new tag.

This pull request has been closed without being integrated.

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

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

From jjg at openjdk.java.net  Wed Dec 16 18:36:57 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 16 Dec 2020 18:36:57 GMT
Subject: RFR: 8230623: Extract command-line help for -Xlint sub-options to
 new --help-lint
In-Reply-To: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
References: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
Message-ID: <YaYuftm4bh3S-3UshM52qRWTRA_cAQB9hYMW2NslKhw=.dd050375-8db8-4af6-a1e8-2f625d6d4b3c@github.com>

On Sun, 13 Dec 2020 14:20:45 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> This patch splits out the concrete keys of -Xlint into a new option, --help-lint, 
> so that the output of --help-extra is kept clean and concise.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

Because a new option is being added, a CSR approval is required.

src/jdk.compiler/share/man/javac.1 line 643:

> 641: .RS
> 642: .RE
> 643: .TP

This change is somewhat problematic. The nroff man files are generated from Markdown files which are not (yet) open source. Don't ask: long story; we're working on it.

The bottom line is that this change should really be made to the upstream Markdown file.  Direct changes to this file are at risk of being overwritten at some point in the future.

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

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

From naoto at openjdk.java.net  Wed Dec 16 18:37:00 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 16 Dec 2020 18:37:00 GMT
Subject: RFR: 8257733: Move module-specific data from make to respective
 module [v2]
In-Reply-To: <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>
References: <hO-d5CMFwQ0WKlQJpNcd0dT9YiuLeCeDeaKWD4yv96k=.4c04580f-5d3e-4315-958f-b8bf3e8fd47d@github.com>
 <9kDHi3GQvAgEtzouYcyzozui9T5-lmSWZEt026DPA-Q=.8b665b02-8c89-43fd-97bf-7f842ad17eb5@github.com>
 <d2m3ofq8QTd7qVrYxhohpEEktBzx_Pah1xcgdsTvlRY=.fd22beda-e27a-485f-b862-46cdb044c24f@github.com>
Message-ID: <qWfRMXCZQRc38lL3CnICumC8ASqtFw-D52PmWzNXQ_M=.f618debd-e14b-4182-b5b4-be2f01b90817@github.com>

On Thu, 10 Dec 2020 23:07:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move to share/data, and move jdwp.spec to java.se
>
> Reviewed changes to `characterdata`, `charsetmapping`, `cldr`, `currency`, `lsrdata`, `tzdata`, and `unicodedata` with minor comment. Looks good overall.

>I also think that the person most qualified to judge about charsetmapping is @naotoj, which has already accepted this review as it is.

Although I am the current RE for the charsets component, I succeeded it from Alan/Sherman, so I would like to hear Alan's opinion on this.

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

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

From jjg at openjdk.java.net  Wed Dec 16 22:25:00 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 16 Dec 2020 22:25:00 GMT
Subject: [jdk16] Integrated: JDK-8241353: NPE in
 ToolProvider.getSystemJavaCompiler
In-Reply-To: <8ukjRsTwt_ErlBVJ8zPoauFkZy35iI-Ejo2teLhttKc=.57c8a70e-35ad-4aa6-ae74-f8a95f4e5cfb@github.com>
References: <8ukjRsTwt_ErlBVJ8zPoauFkZy35iI-Ejo2teLhttKc=.57c8a70e-35ad-4aa6-ae74-f8a95f4e5cfb@github.com>
Message-ID: <V0LNuq3-nHMI6wy992fllpau0-SJKYrWokMNUEI2Fy0=.53fa31c8-345a-442f-9dbb-10a5050b92e3@github.com>

On Wed, 16 Dec 2020 00:46:38 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Trivial fix to avoid NPE by using `Objects.equals` instead of direct `String.equals`

This pull request has now been integrated.

Changeset: 6b4b6765
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/6b4b6765
Stats:     4 lines in 1 file changed: 0 ins; 1 del; 3 mod

8241353: NPE in ToolProvider.getSystemJavaCompiler

Reviewed-by: vromero

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

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

From jjg at openjdk.java.net  Wed Dec 16 22:30:56 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 16 Dec 2020 22:30:56 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search
In-Reply-To: <h4L7gwb3BEtV6LBW0MrXnCCuYsqclJw3czHLDHDzv2U=.e1a66d2b-7be5-41d7-90e5-be116ed55caf@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
 <h4L7gwb3BEtV6LBW0MrXnCCuYsqclJw3czHLDHDzv2U=.e1a66d2b-7be5-41d7-90e5-be116ed55caf@github.com>
Message-ID: <n4TZRZAE4icwhh4C0YbnPciLYpJRyUFF8TRu5B1OrDo=.7d5d8fa5-a681-4160-9d7e-5768a5a1efad@github.com>

On Mon, 14 Dec 2020 09:11:31 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

>> This is for JDK16, as a precursor to fixing JDK-8258002.
>> 
>> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
>> 
>> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js.template line 40:
> 
>> 38: var MIN_RESULTS = 3;
>> 39: var MAX_RESULTS = 500;
>> 40: var UNNAMED = "##REPLACE:doclet.search.unnamed##";
> 
> `<Unnamed>` is not a string that is ever shown to the user, it is what is used by javadoc to denote the default package (see `toolkit.util.DocletConstants.DEFAULT_PACKAGE_NAME`). This variable shouldn't be localized as that would break behaviour for code in the default package (and show the localized string as package name, instead of no package name).

Noted, thanks

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

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

From jjg at openjdk.java.net  Wed Dec 16 23:21:11 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 16 Dec 2020 23:21:11 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search [v2]
In-Reply-To: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
Message-ID: <1GIodXJQxB1mO27Of0bxkkihV_wRhbb3EoGTnCFWG3w=.f927c17d-3653-4d58-9210-dc5b692386b8@github.com>

> This is for JDK16, as a precursor to fixing JDK-8258002.
> 
> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
> 
> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.

Jonathan Gibbons 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 remote-tracking branch 'upstream/master' into localize.search.js
 - JDK-8247994: Localize javadoc search

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/16/files
  - new: https://git.openjdk.java.net/jdk16/pull/16/files/8eb7f27b..ec111185

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

  Stats: 1532 lines in 52 files changed: 1207 ins; 121 del; 204 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/16.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/16/head:pull/16

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

From jjg at openjdk.java.net  Thu Dec 17 00:30:58 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 17 Dec 2020 00:30:58 GMT
Subject: RFR: 8231622: SuppressWarning("serial") ignored on field
 serialVersionUID [v4]
In-Reply-To: <pAZwuCZyGdGLQ1Hk165sxorpi-S4qq2LDutt2ZUSnvM=.c2c59d4d-d830-45f9-803d-10e2b5cd5cb9@github.com>
References: <_2Z8RhLQo1F6ddk2cZS5J_hoRMPLCe5ssVMeyyscFnc=.d267dddd-12d6-4968-a32d-6bd3510daf45@github.com>
 <pAZwuCZyGdGLQ1Hk165sxorpi-S4qq2LDutt2ZUSnvM=.c2c59d4d-d830-45f9-803d-10e2b5cd5cb9@github.com>
Message-ID: <l9Z3mt7m92ML2Kf68Ed-1BH50dO-KycVHS7jC0YEdxY=.77e6e84d-b27b-4771-bfeb-ac307405546e@github.com>

On Wed, 9 Dec 2020 08:04:46 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi all,
>> 
>> Currently, a warning is generated when compiling the following code by using the option `-Xlint`.
>> 
>> import java.io.Serializable;
>> class B implements Serializable {
>>     @SuppressWarnings("serial")
>>     private static final byte serialVersionUID = 5;
>> }
>> 
>> output:
>> B.java:4: warning: [serial] serialVersionUID must be of type long in class B
>>     private static final byte serialVersionUID = 5;
>>                               ^
>> 1 warning
>> 
>> The annotation `@SuppressWarnings("serial")` on  field serialVersionUID is ignored by the compiler.
>> This patch fixes it and adds some tests.
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use method ToolBox.checkEqual

Latest change looks good

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

Marked as reviewed by jjg (Reviewer).

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

From ysatowse at openjdk.java.net  Thu Dec 17 01:40:14 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Thu, 17 Dec 2020 01:40:14 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v3]
In-Reply-To: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
Message-ID: <198fmbGGxYO2VRc3gAVf89rYSoQFlnKyThNUzvuI5uk=.da1f6607-9e2e-48c2-8ab3-833f207a960c@github.com>

> HTML4 is no longer supported in javadoc.
> 
> doclint needs to drop HTML4 support as well.
> The changes consist of:
> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
> * Modifying test code and expected outputs to be checked in HTML5

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

  8257204 and 8256313
  8257204: Remove usage of -Xhtmlversion option from javac
  8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/893/files
  - new: https://git.openjdk.java.net/jdk/pull/893/files/294b3cce..30db3882

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

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

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

From jwilhelm at openjdk.java.net  Thu Dec 17 02:59:10 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 17 Dec 2020 02:59:10 GMT
Subject: RFR: Merge jdk16
Message-ID: <McqAH5-R-bb_iCp28M-rz3l1FgelG-P-leUREc2C2d8=.c6cb6368-a6f4-43c1-86d7-cdad7caf236d@github.com>

Merge JDK 16 -> JDK 17

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

Commit messages:
 - Merge
 - 8258338: Support deprecated records
 - 8241353: NPE in ToolProvider.getSystemJavaCompiler
 - 8255880: UI of Swing components is not redrawn after their internal state changed
 - 8257637: Update usage of "type" terminology in java.lang.annotation
 - 8258236: Segfault in ClassListParser::resolve_indy dumping static AppCDS archive
 - 8258419: RSA cipher buffer cleanup
 - 8258380: [JVMCI] don't clear InstalledCode reference when unloading JVMCI nmethods
 - 8258427: Problem List some tests related to FileDialog for MacOS
 - 8258140: Update @jls tags in java.base for renamed/renumbered sections
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/b2f03554...951fc9c0

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

Changes: https://git.openjdk.java.net/jdk/pull/1812/files
  Stats: 882 lines in 41 files changed: 659 ins; 30 del; 193 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1812.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1812/head:pull/1812

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

From jwilhelm at openjdk.java.net  Thu Dec 17 03:08:57 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 17 Dec 2020 03:08:57 GMT
Subject: Integrated: Merge jdk16
In-Reply-To: <McqAH5-R-bb_iCp28M-rz3l1FgelG-P-leUREc2C2d8=.c6cb6368-a6f4-43c1-86d7-cdad7caf236d@github.com>
References: <McqAH5-R-bb_iCp28M-rz3l1FgelG-P-leUREc2C2d8=.c6cb6368-a6f4-43c1-86d7-cdad7caf236d@github.com>
Message-ID: <6qEv2eY0O11uVLbYwNrAVT7U4LFVK5INiyqa2hByAyQ=.5b8cb7e1-d127-487a-91fc-a1a65e4786b3@github.com>

On Thu, 17 Dec 2020 02:48:38 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Merge JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: 11bd7a81
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/11bd7a81
Stats:     882 lines in 41 files changed: 659 ins; 30 del; 193 mod

Merge

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

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

From jjg at openjdk.java.net  Thu Dec 17 05:01:03 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 17 Dec 2020 05:01:03 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v3]
In-Reply-To: <n2ea4PoUtsEtADcdUM3AkkrO22AT2Tn4nJo2TspgK54=.3d72d7f6-3ce5-4aa3-a2aa-3f49c51b83b1@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <RAdVAZpFjoxQnDj02FVOpgugTaQuNd-LMzpKXeu4VEU=.465404f4-4737-4ec2-b7b5-1681b6471698@github.com>
 <n2ea4PoUtsEtADcdUM3AkkrO22AT2Tn4nJo2TspgK54=.3d72d7f6-3ce5-4aa3-a2aa-3f49c51b83b1@github.com>
Message-ID: <utC2G0Ga3tAOMc2s-SPwbfinJD5P8fyxUHnM23lJOp4=.6cf5de97-58c8-40a3-8265-3a52eff785df@github.com>

On Thu, 12 Nov 2020 03:10:01 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java line 410:
>> 
>>> 408:         OBSOLETE,
>>> 409:         UNSUPPORTED
>>> 410:     }
>> 
>> On one hand, I don't think we need this level of detail, but on the other, I see it closely matches `AttrKind`, so OK.
>> 
>> Is there are useful distinction between INVALID / OBSOLETE / UNSUPPORTED ?
>
> OK: valid
> OBSOLETE: obsolete, deprecated, but still supported (valid)
> UNSUPPORTED: ever supported but no longer supported (invalid)
> INVALID: the rest of others (invalid)
> 
> UNSUPPORTED can be used if we would like to choose a friendly message instead of saying "unknown tag" only.
> OBSOLETE is not used anywhere in this commit.  Although HTML5 has some obsolete features, [JDK-8215577](https://bugs.openjdk.java.net/browse/JDK-8215577) didn't define them as valid features if my understanding is correct.  So I chose not to allow obsolete features in order to avoid inconsistency.

For both `ElemKind` and `AttrKind` there only seem to be two kinds:
* valid
* previously valid

For these two cases, `OK` is obviously reasonable for `valid`, but `OBSOLETE` seems a better fit than `UNSUPPORTED`, but you could also use `HTML4` or `OLD_HTML4` or something like that to indicate why we're keeping the name around for better messages.  Or, stay with `UNSUPPORTED` but add a doc comment explaining that it was previously supported but no longer supported

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

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

From jjg at openjdk.java.net  Thu Dec 17 05:01:03 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 17 Dec 2020 05:01:03 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v3]
In-Reply-To: <198fmbGGxYO2VRc3gAVf89rYSoQFlnKyThNUzvuI5uk=.da1f6607-9e2e-48c2-8ab3-833f207a960c@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <198fmbGGxYO2VRc3gAVf89rYSoQFlnKyThNUzvuI5uk=.da1f6607-9e2e-48c2-8ab3-833f207a960c@github.com>
Message-ID: <BLs1ScSdxGuJRpKnq8ofPhBe5NMV0oV8lb-u-bLpAg0=.9e77a827-999f-4e56-9d29-9d23dc164d50@github.com>

On Thu, 17 Dec 2020 01:40:14 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> HTML4 is no longer supported in javadoc.
>> 
>> doclint needs to drop HTML4 support as well.
>> The changes consist of:
>> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
>> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
>> * Modifying test code and expected outputs to be checked in HTML5
>
> Yoshiki Sato has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   8257204 and 8256313
>   8257204: Remove usage of -Xhtmlversion option from javac
>   8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option

Mostly OK; some minor suggestions

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties line 36:

> 34: dc.attr.img.border.not.number = attribute "border" for img is not a number
> 35: dc.attr.table.border.not.valid = attribute "border" for table only accepts "" or "1", use CSS instead: {0}
> 36: dc.attr.table.border.not.number = attribute "border" for table is not a number

suggest dropping "use CSS instead"

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

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

From jjg at openjdk.java.net  Thu Dec 17 05:01:04 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 17 Dec 2020 05:01:04 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v3]
In-Reply-To: <BLs1ScSdxGuJRpKnq8ofPhBe5NMV0oV8lb-u-bLpAg0=.9e77a827-999f-4e56-9d29-9d23dc164d50@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <198fmbGGxYO2VRc3gAVf89rYSoQFlnKyThNUzvuI5uk=.da1f6607-9e2e-48c2-8ab3-833f207a960c@github.com>
 <BLs1ScSdxGuJRpKnq8ofPhBe5NMV0oV8lb-u-bLpAg0=.9e77a827-999f-4e56-9d29-9d23dc164d50@github.com>
Message-ID: <ct3G5aCjd2l1ULLxIeslbJeu_pdn7Y9XrUo3iALSTdM=.8ca1e3d4-6fc0-4929-ba6d-b9055b5f7093@github.com>

On Thu, 17 Dec 2020 04:50:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Yoshiki Sato has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   8257204 and 8256313
>>   8257204: Remove usage of -Xhtmlversion option from javac
>>   8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties line 36:
> 
>> 34: dc.attr.img.border.not.number = attribute "border" for img is not a number
>> 35: dc.attr.table.border.not.valid = attribute "border" for table only accepts "" or "1", use CSS instead: {0}
>> 36: dc.attr.table.border.not.number = attribute "border" for table is not a number
> 
> suggest dropping "use CSS instead"

The wording of `attribute "border" for img is not a number` seems strange.
Suggest something like `invalid value for attribute "border": {0}`

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Dec 17 05:06:13 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 17 Dec 2020 05:06:13 GMT
Subject: RFR: 8258525: Some existing tests should use /nodynamiccopyright/
 instead of the standard header
Message-ID: <epkxwkylg6_rkP9V3hrA3VaZOCJmmY51bgICJN_y5wg=.f2805d11-4bd9-4f4a-a477-d94452aad2e9@github.com>

Hi all,

This is the background of this patch. According to the comments[1] written by Jonathan Gibbons during the review of JDK-8231622[2], I want to solve previous tests that used the bad style. I wrote a python script[3] to find the bad style tests. But it is not precise and complete.

[1] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015542.html
[2] https://github.com/openjdk/jdk/pull/1626
[3] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015619.html

Currently, I write another python script that can accurately check all the bad style tests. The procedure of this script is shown below.
1.  Add a blank line at the head of the java source files(exclude the files contain `/nodynamiccopyright/`) in directory `test/langtools/tools/javac`. This step simulates the changes of the length in the legal header.
2. Run the test by using the command `make test CONF=linux-x86_64-server-release JOBS=4 TEST=test/langtools/tools/javac`. This step checks whether the tests can be comfortable to the changes of the length in legal header. If a test failed, it means the test style is bad and need to be revised.
3. Delete the blank line at the head of the java source files(exclude the files contain `/nodynamiccopyright/`) in directory `test/langtools/tools/javac`. This step recovers the modified files.

If all the tests are in good style,  all the tests in step 2 will passed. I use this script to test the branch `master` locally. 129 tests failed. I fixed them. Currently, I use this script to test the branch `test-copyright-clean` of this patch locally. All the tests passed.

I think this patch solves all the bad style tests if my script has no bugs and no new bad style tests were integrated to branch `master` recently.

The code of the new python script is shown below. You maybe need to revise the options `CONF=linux-x86_64-server-release` and `JOBS=4` when testing locally.

#!/usr/bin/python
import os


def runTests(find_dir):
    os.system('make test CONF=linux-x86_64-server-release JOBS=4 TEST=' + find_dir)
    return


def addBlankLinePerFile(full_path):
    search_file = open(full_path, 'r+')
    content = search_file.read()
    if content.find("/nodynamiccopyright/") < 0 and full_path.endswith(".java"):
        search_file.seek(0)
        search_file.write("\n")
        search_file.write(content)
    search_file.close()


def deleteBlankLinePerFile(full_path):
    search_file = open(full_path, 'r')
    old_content = search_file.readlines()
    search_file.close()
    search_file = open(full_path, 'w')
    if ''.join(old_content).find("/nodynamiccopyright/") < 0 and full_path.endswith(".java"):
        new_content = ''.join(old_content[1:])
        search_file.write(new_content)
    else:
        search_file.write(''.join(old_content))
    search_file.close()


def addBlankLine(find_dir):
    for dir_path, dir_names, file_names in os.walk(find_dir):
        for file_name in file_names:
            full_path = os.path.join(dir_path, file_name)
            addBlankLinePerFile(full_path)


def deleteBlankLine(find_dir):
    for dir_path, dir_names, file_names in os.walk(find_dir):
        for file_name in file_names:
            full_path = os.path.join(dir_path, file_name)
            deleteBlankLinePerFile(full_path)


if __name__ == "__main__":
    findDir = "test/langtools/tools/javac"
    addBlankLine(findDir)
    runTests(findDir)
    deleteBlankLine(findDir)


Thank you for taking the time to review.
And could I ask your help to create a new issue in the bug tracker? Thanks again.

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

Commit messages:
 - Some tests should use /nodynamiccopyright/ instead of the copyright header.

Changes: https://git.openjdk.java.net/jdk/pull/1732/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1732&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258525
  Stats: 3411 lines in 267 files changed: 50 ins; 2821 del; 540 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1732.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1732/head:pull/1732

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

From jjg at openjdk.java.net  Thu Dec 17 05:06:14 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 17 Dec 2020 05:06:14 GMT
Subject: RFR: 8258525: Some existing tests should use /nodynamiccopyright/
 instead of the standard header
In-Reply-To: <epkxwkylg6_rkP9V3hrA3VaZOCJmmY51bgICJN_y5wg=.f2805d11-4bd9-4f4a-a477-d94452aad2e9@github.com>
References: <epkxwkylg6_rkP9V3hrA3VaZOCJmmY51bgICJN_y5wg=.f2805d11-4bd9-4f4a-a477-d94452aad2e9@github.com>
Message-ID: <7hafV_O2jHgs64xzjogkbZbfzpBvXvYkjisQEveKXCo=.6f8df181-19b8-4716-885b-1eb249c4080a@github.com>

On Thu, 10 Dec 2020 13:02:28 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> This is the background of this patch. According to the comments[1] written by Jonathan Gibbons during the review of JDK-8231622[2], I want to solve previous tests that used the bad style. I wrote a python script[3] to find the bad style tests. But it is not precise and complete.
> 
> [1] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015542.html
> [2] https://github.com/openjdk/jdk/pull/1626
> [3] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015619.html
> 
> Currently, I write another python script that can accurately check all the bad style tests. The procedure of this script is shown below.
> 1.  Add a blank line at the head of the java source files(exclude the files contain `/nodynamiccopyright/`) in directory `test/langtools/tools/javac`. This step simulates the changes of the length in the legal header.
> 2. Run the test by using the command `make test CONF=linux-x86_64-server-release JOBS=4 TEST=test/langtools/tools/javac`. This step checks whether the tests can be comfortable to the changes of the length in legal header. If a test failed, it means the test style is bad and need to be revised.
> 3. Delete the blank line at the head of the java source files(exclude the files contain `/nodynamiccopyright/`) in directory `test/langtools/tools/javac`. This step recovers the modified files.
> 
> If all the tests are in good style,  all the tests in step 2 will passed. I use this script to test the branch `master` locally. 129 tests failed. I fixed them. Currently, I use this script to test the branch `test-copyright-clean` of this patch locally. All the tests passed.
> 
> I think this patch solves all the bad style tests if my script has no bugs and no new bad style tests were integrated to branch `master` recently.
> 
> The code of the new python script is shown below. You maybe need to revise the options `CONF=linux-x86_64-server-release` and `JOBS=4` when testing locally.
> 
> #!/usr/bin/python
> import os
> 
> 
> def runTests(find_dir):
>     os.system('make test CONF=linux-x86_64-server-release JOBS=4 TEST=' + find_dir)
>     return
> 
> 
> def addBlankLinePerFile(full_path):
>     search_file = open(full_path, 'r+')
>     content = search_file.read()
>     if content.find("/nodynamiccopyright/") < 0 and full_path.endswith(".java"):
>         search_file.seek(0)
>         search_file.write("\n")
>         search_file.write(content)
>     search_file.close()
> 
> 
> def deleteBlankLinePerFile(full_path):
>     search_file = open(full_path, 'r')
>     old_content = search_file.readlines()
>     search_file.close()
>     search_file = open(full_path, 'w')
>     if ''.join(old_content).find("/nodynamiccopyright/") < 0 and full_path.endswith(".java"):
>         new_content = ''.join(old_content[1:])
>         search_file.write(new_content)
>     else:
>         search_file.write(''.join(old_content))
>     search_file.close()
> 
> 
> def addBlankLine(find_dir):
>     for dir_path, dir_names, file_names in os.walk(find_dir):
>         for file_name in file_names:
>             full_path = os.path.join(dir_path, file_name)
>             addBlankLinePerFile(full_path)
> 
> 
> def deleteBlankLine(find_dir):
>     for dir_path, dir_names, file_names in os.walk(find_dir):
>         for file_name in file_names:
>             full_path = os.path.join(dir_path, file_name)
>             deleteBlankLinePerFile(full_path)
> 
> 
> if __name__ == "__main__":
>     findDir = "test/langtools/tools/javac"
>     addBlankLine(findDir)
>     runTests(findDir)
>     deleteBlankLine(findDir)
> 
> 
> Thank you for taking the time to review.
> And could I ask your help to create a new issue in the bug tracker? Thanks again.

Filed JBS issue: https://bugs.openjdk.java.net/browse/JDK-8258525

test/langtools/tools/javac/lambda/methodReference/MethodRefStuck.java line 2:

> 1: /*
> 2:  * Copyright (c) 2018, Google LLC. All rights reserved.

Since this file is copyright Google, this file and related files should not be modified without additional checking.

test/langtools/tools/javac/patterns/CastConversionMatch.java line 2:

> 1: /*
> 2:  * @test /nodynamicopyright/

oops

test/langtools/tools/javac/warnings/MaxWarnsRecompile.java line 2:

> 1: /*
> 2:  * Copyright (c) 2019, Google LLC. All rights reserved.

Another Google copyright

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

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

From jjg at openjdk.java.net  Thu Dec 17 05:06:15 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 17 Dec 2020 05:06:15 GMT
Subject: RFR: 8258525: Some existing tests should use /nodynamiccopyright/
 instead of the standard header
In-Reply-To: <7hafV_O2jHgs64xzjogkbZbfzpBvXvYkjisQEveKXCo=.6f8df181-19b8-4716-885b-1eb249c4080a@github.com>
References: <epkxwkylg6_rkP9V3hrA3VaZOCJmmY51bgICJN_y5wg=.f2805d11-4bd9-4f4a-a477-d94452aad2e9@github.com>
 <7hafV_O2jHgs64xzjogkbZbfzpBvXvYkjisQEveKXCo=.6f8df181-19b8-4716-885b-1eb249c4080a@github.com>
Message-ID: <-_LQhyFiYWgqUwwvr4yQuwdzUrhfef8ryPgOvuwZYwg=.64a37358-4973-4c1d-a218-80293d83366a@github.com>

On Wed, 16 Dec 2020 21:19:25 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Hi all,
>> 
>> This is the background of this patch. According to the comments[1] written by Jonathan Gibbons during the review of JDK-8231622[2], I want to solve previous tests that used the bad style. I wrote a python script[3] to find the bad style tests. But it is not precise and complete.
>> 
>> [1] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015542.html
>> [2] https://github.com/openjdk/jdk/pull/1626
>> [3] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015619.html
>> 
>> Currently, I write another python script that can accurately check all the bad style tests. The procedure of this script is shown below.
>> 1.  Add a blank line at the head of the java source files(exclude the files contain `/nodynamiccopyright/`) in directory `test/langtools/tools/javac`. This step simulates the changes of the length in the legal header.
>> 2. Run the test by using the command `make test CONF=linux-x86_64-server-release JOBS=4 TEST=test/langtools/tools/javac`. This step checks whether the tests can be comfortable to the changes of the length in legal header. If a test failed, it means the test style is bad and need to be revised.
>> 3. Delete the blank line at the head of the java source files(exclude the files contain `/nodynamiccopyright/`) in directory `test/langtools/tools/javac`. This step recovers the modified files.
>> 
>> If all the tests are in good style,  all the tests in step 2 will passed. I use this script to test the branch `master` locally. 129 tests failed. I fixed them. Currently, I use this script to test the branch `test-copyright-clean` of this patch locally. All the tests passed.
>> 
>> I think this patch solves all the bad style tests if my script has no bugs and no new bad style tests were integrated to branch `master` recently.
>> 
>> The code of the new python script is shown below. You maybe need to revise the options `CONF=linux-x86_64-server-release` and `JOBS=4` when testing locally.
>> 
>> #!/usr/bin/python
>> import os
>> 
>> 
>> def runTests(find_dir):
>>     os.system('make test CONF=linux-x86_64-server-release JOBS=4 TEST=' + find_dir)
>>     return
>> 
>> 
>> def addBlankLinePerFile(full_path):
>>     search_file = open(full_path, 'r+')
>>     content = search_file.read()
>>     if content.find("/nodynamiccopyright/") < 0 and full_path.endswith(".java"):
>>         search_file.seek(0)
>>         search_file.write("\n")
>>         search_file.write(content)
>>     search_file.close()
>> 
>> 
>> def deleteBlankLinePerFile(full_path):
>>     search_file = open(full_path, 'r')
>>     old_content = search_file.readlines()
>>     search_file.close()
>>     search_file = open(full_path, 'w')
>>     if ''.join(old_content).find("/nodynamiccopyright/") < 0 and full_path.endswith(".java"):
>>         new_content = ''.join(old_content[1:])
>>         search_file.write(new_content)
>>     else:
>>         search_file.write(''.join(old_content))
>>     search_file.close()
>> 
>> 
>> def addBlankLine(find_dir):
>>     for dir_path, dir_names, file_names in os.walk(find_dir):
>>         for file_name in file_names:
>>             full_path = os.path.join(dir_path, file_name)
>>             addBlankLinePerFile(full_path)
>> 
>> 
>> def deleteBlankLine(find_dir):
>>     for dir_path, dir_names, file_names in os.walk(find_dir):
>>         for file_name in file_names:
>>             full_path = os.path.join(dir_path, file_name)
>>             deleteBlankLinePerFile(full_path)
>> 
>> 
>> if __name__ == "__main__":
>>     findDir = "test/langtools/tools/javac"
>>     addBlankLine(findDir)
>>     runTests(findDir)
>>     deleteBlankLine(findDir)
>> 
>> 
>> Thank you for taking the time to review.
>> And could I ask your help to create a new issue in the bug tracker? Thanks again.
>
> Filed JBS issue: https://bugs.openjdk.java.net/browse/JDK-8258525

I'm ready to approve this change, once the issue has been set correctly

> test/langtools/tools/javac/warnings/MaxWarnsRecompile.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2019, Google LLC. All rights reserved.
> 
> Another Google copyright

Verified OK to change

> test/langtools/tools/javac/lambda/methodReference/MethodRefStuck.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, Google LLC. All rights reserved.
> 
> Since this file is copyright Google, this file and related files should not be modified without additional checking.

Verified OK to change

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Dec 17 05:07:01 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 17 Dec 2020 05:07:01 GMT
Subject: RFR: 8230623: Extract command-line help for -Xlint sub-options to
 new --help-lint
In-Reply-To: <YaYuftm4bh3S-3UshM52qRWTRA_cAQB9hYMW2NslKhw=.dd050375-8db8-4af6-a1e8-2f625d6d4b3c@github.com>
References: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
 <YaYuftm4bh3S-3UshM52qRWTRA_cAQB9hYMW2NslKhw=.dd050375-8db8-4af6-a1e8-2f625d6d4b3c@github.com>
Message-ID: <-bpF5C_9OiEIIffvMVqMGaU-K-wp3XzI10CI68s8cOI=.5f9eb819-a8a6-4b35-b330-ba81a5d9bcdd@github.com>

On Wed, 16 Dec 2020 18:34:01 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Hi all,
>> 
>> This patch splits out the concrete keys of -Xlint into a new option, --help-lint, 
>> so that the output of --help-extra is kept clean and concise.
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Because a new option is being added, a CSR approval is required.

@jonathan-gibbons Could I ask your help to create the CSR request in the bug tracker?

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Dec 17 05:08:54 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 17 Dec 2020 05:08:54 GMT
Subject: RFR: 8254023: A module declaration is not allowed to be a target
 of an annotation that lacks an @Target meta-annotation
In-Reply-To: <UXI2qajwXtoo7GuuzpSZhpYqFaX6UgaptH6Ihe9iM6s=.d9218019-f413-4515-9088-65f1006ab13c@github.com>
References: <wFdu9AyyNU2SB0nWx9mq_2syF2XyQIB0z6Rmc-r1fNc=.369439d1-385e-4fd1-aac1-72e48ac246e8@github.com>
 <pqSfmocPi4AJGQJEJl4j6UgITEL0f62TKSVpxwOer6w=.49e74a9b-ecb0-4a13-9dfc-93c27fd5149a@github.com>
 <5_HZhCK8rd2yWcf4XzGa_N50I1Xl3CMmUXSugfoJIUk=.379b61e3-e4a3-4509-ac7b-940a25ae4609@github.com>
 <6VDsNZKAYnkmm_YsLRjClBhqPMPPqy4d3TrWLcElkOU=.3f9b9d49-4e49-4574-a07c-6f72acefcfd2@github.com>
 <tBB2q0ATDEr8k86St14cqLVTAwy2CH34WolOWfPH1bw=.e9a456ad-28c8-4e36-9eb4-62024a96c0e4@github.com>
 <55-uvNq2QGWKbTD3uVotqaRdbInO5Ih0L462CR7cnGc=.4a2912dd-6868-4290-9e39-2c5f50cf4ca2@github.com>
 <CMHxOHQvUOHVPAkk0TR1N5pyLFoWN6wlDDX4y-vs5Q8=.b3da3476-d256-4011-afae-f6235bbcee45@github.com>
 <DYE5Xh2_FehT4qZpjTdxeNSd57IGxB0cpVVIQP0g-5o=.55c2c0b8-f9b9-4ce1-a834-6538a1cc3ecf@github.com>
 <QzcPBDfL1gbJ27__AzwRzYJ2g_LSBpXY_feRiGsg0Aw=.b92150d1-8906-45d5-aa58-08b04ab6cd70@github.com>
 <TQrf2FfVIWQciI3F_lUKBzzPuESOQpcSQ9E6si9FWGI=.141de789-7622-40c5-9167-4bbc3dd8e0df@github.com>
 <UXI2qajwXtoo7GuuzpSZhpYqFaX6UgaptH6
 Ihe9iM6s=.d9218019-f413-4515-9088-65f1006ab13c@github.com>
Message-ID: <7UYEKsAP2zEZb5fxRZ7LRNmZBXVJFrOLEuVm09J3G1g=.dc22776b-daa6-47f1-ab3f-d3780a2dc0a4@github.com>

On Wed, 16 Dec 2020 12:07:14 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi @lgxbslgx 
>> 
>> This looks good to me. Since this is targeted to Java 16 we need to close this PR and open a new PR towards the JDK16 project and finish the review there, add a link back to this PR would also be neat. Can you do that?
>> 
>> cheers
>
> @jbf I open a new PR in JDK 16. Please see https://github.com/openjdk/jdk16/pull/34

The later work will be completed in JDK 16.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Dec 17 05:08:55 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 17 Dec 2020 05:08:55 GMT
Subject: Withdrawn: 8254023: A module declaration is not allowed to be a
 target of an annotation that lacks an @Target meta-annotation
In-Reply-To: <wFdu9AyyNU2SB0nWx9mq_2syF2XyQIB0z6Rmc-r1fNc=.369439d1-385e-4fd1-aac1-72e48ac246e8@github.com>
References: <wFdu9AyyNU2SB0nWx9mq_2syF2XyQIB0z6Rmc-r1fNc=.369439d1-385e-4fd1-aac1-72e48ac246e8@github.com>
Message-ID: <Ke3o3w0ARX0ws1SW5X-XrfSuZK0OG9Mu3QbcX_eeosI=.0a3823bf-b32b-474a-9ef8-f131cccb2e95@github.com>

On Tue, 13 Oct 2020 04:02:36 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> The Java Language Specifications(JLS), from 8 to 13 included, state it as below:
> 
>> If an annotation of type java.lang.annotation.Target is not present on the
> declaration of an annotation type T , then T is applicable in all declaration contexts
> except type parameter declarations, and in no type contexts.
> These contexts are the syntactic locations where annotations were allowed in Java SE 7.
> 
> The JLS 14 and 15 state it as below:
> 
>>If an annotation of type java.lang.annotation.Target is not present on the
> declaration of an annotation type T , then T is applicable in all nine declaration
> contexts and in all 16 type contexts.
> 
> This patch adds `names.MODULE, names.TYPE_PARAMETER, names.TYPE_USE` to `com.sun.tools.javac.comp.Check.dfltTargetMeta` to fix this issue.
> Thank you for taking the time to review.
> 
> Best Regards.

This pull request has been closed without being integrated.

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

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

From ysatowse at openjdk.java.net  Thu Dec 17 06:37:00 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Thu, 17 Dec 2020 06:37:00 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v3]
In-Reply-To: <ct3G5aCjd2l1ULLxIeslbJeu_pdn7Y9XrUo3iALSTdM=.8ca1e3d4-6fc0-4929-ba6d-b9055b5f7093@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <198fmbGGxYO2VRc3gAVf89rYSoQFlnKyThNUzvuI5uk=.da1f6607-9e2e-48c2-8ab3-833f207a960c@github.com>
 <BLs1ScSdxGuJRpKnq8ofPhBe5NMV0oV8lb-u-bLpAg0=.9e77a827-999f-4e56-9d29-9d23dc164d50@github.com>
 <ct3G5aCjd2l1ULLxIeslbJeu_pdn7Y9XrUo3iALSTdM=.8ca1e3d4-6fc0-4929-ba6d-b9055b5f7093@github.com>
Message-ID: <LaPvn9zXOCuv3dabCWRzTvMc_Qmch_-YLBUnkrS1Njw=.6f56b3b4-1382-49b5-845c-3250c591143f@github.com>

On Thu, 17 Dec 2020 04:52:48 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties line 36:
>> 
>>> 34: dc.attr.img.border.not.number = attribute "border" for img is not a number
>>> 35: dc.attr.table.border.not.valid = attribute "border" for table only accepts "" or "1", use CSS instead: {0}
>>> 36: dc.attr.table.border.not.number = attribute "border" for table is not a number
>> 
>> suggest dropping "use CSS instead"
>
> The wording of `attribute "border" for img is not a number` seems strange.
> Suggest something like `invalid value for attribute "border": {0}`

Ok, I will fix that.

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

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

From ysatowse at openjdk.java.net  Thu Dec 17 06:42:01 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Thu, 17 Dec 2020 06:42:01 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v3]
In-Reply-To: <utC2G0Ga3tAOMc2s-SPwbfinJD5P8fyxUHnM23lJOp4=.6cf5de97-58c8-40a3-8265-3a52eff785df@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <RAdVAZpFjoxQnDj02FVOpgugTaQuNd-LMzpKXeu4VEU=.465404f4-4737-4ec2-b7b5-1681b6471698@github.com>
 <n2ea4PoUtsEtADcdUM3AkkrO22AT2Tn4nJo2TspgK54=.3d72d7f6-3ce5-4aa3-a2aa-3f49c51b83b1@github.com>
 <utC2G0Ga3tAOMc2s-SPwbfinJD5P8fyxUHnM23lJOp4=.6cf5de97-58c8-40a3-8265-3a52eff785df@github.com>
Message-ID: <nIfzA3CWPNH4afTxI1eBE303Bsj6gINA4pYPe5dOpu8=.2d5bdda8-f220-4b47-ad76-44e83405bb35@github.com>

On Thu, 17 Dec 2020 04:48:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> OK: valid
>> OBSOLETE: obsolete, deprecated, but still supported (valid)
>> UNSUPPORTED: ever supported but no longer supported (invalid)
>> INVALID: the rest of others (invalid)
>> 
>> UNSUPPORTED can be used if we would like to choose a friendly message instead of saying "unknown tag" only.
>> OBSOLETE is not used anywhere in this commit.  Although HTML5 has some obsolete features, [JDK-8215577](https://bugs.openjdk.java.net/browse/JDK-8215577) didn't define them as valid features if my understanding is correct.  So I chose not to allow obsolete features in order to avoid inconsistency.
>
> For both `ElemKind` and `AttrKind` there only seem to be two kinds:
> * valid
> * previously valid
> 
> For these two cases, `OK` is obviously reasonable for `valid`, but `OBSOLETE` seems a better fit than `UNSUPPORTED`, but you could also use `HTML4` or `OLD_HTML4` or something like that to indicate why we're keeping the name around for better messages.  Or, stay with `UNSUPPORTED` but add a doc comment explaining that it was previously supported but no longer supported

Ok, I will use `HTML4`.

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

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

From vromero at openjdk.java.net  Thu Dec 17 06:52:57 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 17 Dec 2020 06:52:57 GMT
Subject: Withdrawn: 8213032: program fails with LambdaConversionException at
 execution time
In-Reply-To: <jLIRTBFpU4XTDpE6CRerwdQK8zCzM7y5Vklm5sNIxMc=.ec7905fa-91bf-4e97-aef2-0d24dbf565d5@github.com>
References: <jLIRTBFpU4XTDpE6CRerwdQK8zCzM7y5Vklm5sNIxMc=.ec7905fa-91bf-4e97-aef2-0d24dbf565d5@github.com>
Message-ID: <wB8PTKqPqqmgb4yTcXBqKFun-3MdDAZR-ChiIvIle_0=.3ca38072-0d80-4bbe-bc81-7982a2716664@github.com>

On Thu, 22 Oct 2020 03:55:01 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> I'm still doing some research on this one. I realized of a present issue in LambdaToMethod, will update the review after doing some more investigation

This pull request has been closed without being integrated.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Dec 17 08:10:05 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 17 Dec 2020 08:10:05 GMT
Subject: [jdk16] Integrated: 8254023: A module declaration is not allowed to
 be a target of an annotation that lacks an @Target meta-annotation
In-Reply-To: <BzOpe0tf6KMcHXh9WLjl91lVXtsLg-4YhC5evsVskM8=.cffed619-e078-4be1-88bd-d969d9981088@github.com>
References: <BzOpe0tf6KMcHXh9WLjl91lVXtsLg-4YhC5evsVskM8=.cffed619-e078-4be1-88bd-d969d9981088@github.com>
Message-ID: <alA7uUso6ZKEjx7kY0WnKGUyQu6kQWfzloXHvts3gR8=.7179b2db-2e01-4e64-8e28-44308482d1fa@github.com>

On Wed, 16 Dec 2020 12:02:58 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> This patch adds `names.MODULE` to `com.sun.tools.javac.comp.Check.dfltTargetMeta` to fix this issue. And it also adds some corresponding tests.
> 
> The previous discussion is in https://github.com/openjdk/jdk/pull/622.
> 
> Best Regards.

This pull request has now been integrated.

Changeset: 41f312eb
Author:    Guoxiong Li <lgxbslgx at gmail.com>
Committer: Joel Borggr?n-Franck <jfranck at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/41f312eb
Stats:     180 lines in 6 files changed: 177 ins; 0 del; 3 mod

8254023: A module declaration is not allowed to be a target of an annotation that lacks an @Target meta-annotation

Reviewed-by: jfranck, vromero

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

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

From vromero at openjdk.java.net  Thu Dec 17 15:34:07 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 17 Dec 2020 15:34:07 GMT
Subject: [jdk16] RFR: 8258515: javac should issue an error if an annotation is
 nested in a local class or interface
Message-ID: <V58aeoUjf0GHDSwCgzhKxPWBKpuuBFiZQFbCkWPzUMQ=.f2ec5dee-cc91-4aac-980c-d27df1c12836@github.com>

Spec [1](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html), section 9.6 Annotation Interfaces states that:

"It is a compile-time error if an annotation declaration is nested within the body of a local class or interface declaration (14.3), or within the body of an anonymous class"

javac is not implementing this assertion. The proposed patch is fixing this issue,

TIA

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

Commit messages:
 - 8258515: No compilation error thrown when an annotation is declared within body of a local class

Changes: https://git.openjdk.java.net/jdk16/pull/43/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=43&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258515
  Stats: 129 lines in 10 files changed: 105 ins; 0 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/43.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/43/head:pull/43

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

From jjg at openjdk.java.net  Thu Dec 17 16:39:17 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 17 Dec 2020 16:39:17 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search [v3]
In-Reply-To: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
Message-ID: <yNCZp72SmLyGtISZOHf03lrmZWaObtajWmXyeNZITqc=.caba81f4-e70b-42a2-b92c-3d93bcf5b377@github.com>

> This is for JDK16, as a precursor to fixing JDK-8258002.
> 
> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
> 
> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.

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

  Address review comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/16/files
  - new: https://git.openjdk.java.net/jdk16/pull/16/files/ec111185..1a406f35

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

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

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

From hannesw at openjdk.java.net  Thu Dec 17 17:06:00 2020
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 17 Dec 2020 17:06:00 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search [v3]
In-Reply-To: <yNCZp72SmLyGtISZOHf03lrmZWaObtajWmXyeNZITqc=.caba81f4-e70b-42a2-b92c-3d93bcf5b377@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
 <yNCZp72SmLyGtISZOHf03lrmZWaObtajWmXyeNZITqc=.caba81f4-e70b-42a2-b92c-3d93bcf5b377@github.com>
Message-ID: <-H-OPr6wCQeLESYlsa7aQTVJjtzxeknaqJRpy0-s0L8=.af6de1b0-749d-4cf4-898b-2f4284db3ebd@github.com>

On Thu, 17 Dec 2020 16:39:17 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This is for JDK16, as a precursor to fixing JDK-8258002.
>> 
>> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
>> 
>> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/search.js.template line 40:

> 38: var MIN_RESULTS = 3;
> 39: var MAX_RESULTS = 500;
> 40: var UNNAMED = "<Unnamed>>";

Oops, an additional closing angle bracket slipped there.

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

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

From jjg at openjdk.java.net  Thu Dec 17 17:13:14 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 17 Dec 2020 17:13:14 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search [v4]
In-Reply-To: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
Message-ID: <z4c0UByrdXBXCUoBX41qx9nJJVh0XOUynSgF9mAFt4Q=.70d8db98-dc89-4883-96aa-eb1f8c8770fc@github.com>

> This is for JDK16, as a precursor to fixing JDK-8258002.
> 
> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
> 
> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.

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

  Address review comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/16/files
  - new: https://git.openjdk.java.net/jdk16/pull/16/files/1a406f35..de6802c0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=16&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=16&range=02-03

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

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

From hannesw at openjdk.java.net  Thu Dec 17 17:13:15 2020
From: hannesw at openjdk.java.net (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 17 Dec 2020 17:13:15 GMT
Subject: [jdk16] RFR: JDK-8247994: Localize javadoc search [v4]
In-Reply-To: <z4c0UByrdXBXCUoBX41qx9nJJVh0XOUynSgF9mAFt4Q=.70d8db98-dc89-4883-96aa-eb1f8c8770fc@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
 <z4c0UByrdXBXCUoBX41qx9nJJVh0XOUynSgF9mAFt4Q=.70d8db98-dc89-4883-96aa-eb1f8c8770fc@github.com>
Message-ID: <6teL5P5Sg13pNY0zUuTF-wQc5a_rr8zrq4xNAxoGJL0=.5d6444e0-66d4-43ee-aa80-5ac2bfa9fc75@github.com>

On Thu, 17 Dec 2020 17:10:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This is for JDK16, as a precursor to fixing JDK-8258002.
>> 
>> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
>> 
>> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment

Marked as reviewed by hannesw (Reviewer).

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

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

From jjg at openjdk.java.net  Thu Dec 17 18:08:57 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 17 Dec 2020 18:08:57 GMT
Subject: [jdk16] RFR: 8258515: javac should issue an error if an
 annotation is nested in a local class or interface
In-Reply-To: <V58aeoUjf0GHDSwCgzhKxPWBKpuuBFiZQFbCkWPzUMQ=.f2ec5dee-cc91-4aac-980c-d27df1c12836@github.com>
References: <V58aeoUjf0GHDSwCgzhKxPWBKpuuBFiZQFbCkWPzUMQ=.f2ec5dee-cc91-4aac-980c-d27df1c12836@github.com>
Message-ID: <L8KJFGfprqJA_0y66ItdqqX0BqvrcVUAjjb_6kgXNVg=.109c23e9-7e43-467f-8cbd-e7193ae166fe@github.com>

On Thu, 17 Dec 2020 15:27:48 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Spec [1](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html), section 9.6 Annotation Interfaces states that:
> 
> "It is a compile-time error if an annotation declaration is nested within the body of a local class or interface declaration (14.3), or within the body of an anonymous class"
> 
> javac is not implementing this assertion. The proposed patch is fixing this issue,
> 
> TIA

Marked as reviewed by jjg (Reviewer).

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

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

From vromero at openjdk.java.net  Thu Dec 17 18:11:59 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 17 Dec 2020 18:11:59 GMT
Subject: [jdk16] Integrated: 8258515: javac should issue an error if an
 annotation is nested in a local class or interface
In-Reply-To: <V58aeoUjf0GHDSwCgzhKxPWBKpuuBFiZQFbCkWPzUMQ=.f2ec5dee-cc91-4aac-980c-d27df1c12836@github.com>
References: <V58aeoUjf0GHDSwCgzhKxPWBKpuuBFiZQFbCkWPzUMQ=.f2ec5dee-cc91-4aac-980c-d27df1c12836@github.com>
Message-ID: <tT6jiaZOSYkk0SCU9acy99hkDX6NDIgOdhJYc8ALpzg=.c06c615d-4f7e-47f9-96de-6419218b24c4@github.com>

On Thu, 17 Dec 2020 15:27:48 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Spec [1](http://cr.openjdk.java.net/~gbierman/8246771/8246771-20200928/specs/local-statics-jls.html), section 9.6 Annotation Interfaces states that:
> 
> "It is a compile-time error if an annotation declaration is nested within the body of a local class or interface declaration (14.3), or within the body of an anonymous class"
> 
> javac is not implementing this assertion. The proposed patch is fixing this issue,
> 
> TIA

This pull request has now been integrated.

Changeset: 47c180da
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/47c180da
Stats:     129 lines in 10 files changed: 105 ins; 0 del; 24 mod

8258515: javac should issue an error if an annotation is nested in a local class or interface

Reviewed-by: jjg

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

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

From jjg at openjdk.java.net  Thu Dec 17 18:36:58 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 17 Dec 2020 18:36:58 GMT
Subject: [jdk16] Integrated: JDK-8247994: Localize javadoc search
In-Reply-To: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
References: <z3KZ-s7GOAJs559ZzG72xKfifl6AnB9raU6UvxMizt4=.c9c8dd11-5c19-4efd-a358-a8f0c0cdc196@github.com>
Message-ID: <mLgRaQMV52_N_PKjfTsigoc0sYxYeecyxktxV7i98-A=.7f258a87-60b0-4a0d-a25e-b45d4ad3a3e1@github.com>

On Sun, 13 Dec 2020 00:19:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> This is for JDK16, as a precursor to fixing JDK-8258002.
> 
> While it is good to be using localized strings in the generated output, the significance for JDK-8258002 is that the strings are now obtained from a resource file, and not hardcoded in JavaScript file itself.
> 
> The source file `search.js` is renamed to `search.js.template`, and (unlike other template files) is copied as-is into the generated image. The values in the template are resolved when javadoc is executed, depending on the locale in use at the time. Because of the change in the file's extension, two makefiles are updated to accommodate the new extension: one is for the "interim" javadoc used to generate the API docs; the other is for the primary javadoc in the main JDK image.

This pull request has now been integrated.

Changeset: 30ca0a5d
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/30ca0a5d
Stats:     120 lines in 9 files changed: 87 ins; 6 del; 27 mod

8247994: Localize javadoc search

Reviewed-by: hannesw, ihse

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

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

From vicente.romero at oracle.com  Thu Dec 17 20:14:13 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 17 Dec 2020 15:14:13 -0500
Subject: Records, Intersection type and lambda
In-Reply-To: <CAEgw74DK6=Hvehk+GxVL8TcKeMFxUsHevSU0ATzTJQzGB-AoaA@mail.gmail.com>
References: <1634118475.2157445.1605459778491.JavaMail.zimbra@u-pem.fr>
 <CAEgw74At3W0manZ4yQsUewZz8iYJ5D136MXLw_nfR6OzjjYUcA@mail.gmail.com>
 <1485898290.1122166.1605599180102.JavaMail.zimbra@u-pem.fr>
 <CAEgw74DK6=Hvehk+GxVL8TcKeMFxUsHevSU0ATzTJQzGB-AoaA@mail.gmail.com>
Message-ID: <ce41110b-757d-b1f0-7358-a3a716ef52a4@oracle.com>

Hi,

There was a review that got closed bc nobody reviewed it. I will prepare 
another PR targeting 16,

Vicente

On 11/18/20 10:21 AM, B. Blaser wrote:
> On Tue, 17 Nov 2020 at 08:46, <forax at univ-mlv.fr> wrote:
>> yes, thanks !
>> still not fixed :(
> Probably not a frequent issue with usual classes but I believe this
> might be a rather common use case with records, so I verified that my
> initial fix is still working fine with your latest example.
> However, Vicente seems to be investigating something else in the same
> area but I'd suggest to eventually file a separate issue for that in
> order to go ahead with my proposal, what do you think?
>
> Thanks,
> Bernard


From jwilhelm at openjdk.java.net  Thu Dec 17 20:44:15 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 17 Dec 2020 20:44:15 GMT
Subject: Integrated: Merge jdk16
Message-ID: <LD8ANDgogS-bx4izFlwhL_9-MwiCI2jNn6a4Ehb2wmA=.80d8ff3d-e60b-4634-bcce-943c96d6edbd@github.com>

Forwardport JDK 16 -> JDK 17

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

Commit messages:
 - Merge
 - 8247994: Localize javadoc search
 - 8258515: javac should issue an error if an annotation is nested in a local class or interface
 - 8258225: compiler/c2/cr6340864/TestIntVect.java runs faster in interpreter
 - 8258293: tools/jpackage/share/RuntimePackageTest.java#id0 with RuntimePackageTest.testUsrInstallDir2
 - 8257621: JFR StringPool misses cached items across consecutive recordings
 - 8257999: Parallel GC crash in gc/parallel/TestDynShrinkHeap.java: new region is not in covered_region
 - 8257636: Update usage of "type" terminology in java.lang.Class and java.lang.reflect
 - 8258505: [TESTBUG] TestDivZeroWithSplitIf.java fails due to missing UnlockDiagnosticVMOptions
 - 8254023: A module declaration is not allowed to be a target of an annotation that lacks an @Target meta-annotation

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

Changes: https://git.openjdk.java.net/jdk/pull/1827/files
  Stats: 773 lines in 63 files changed: 449 ins; 124 del; 200 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1827.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1827/head:pull/1827

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

From jwilhelm at openjdk.java.net  Thu Dec 17 20:44:15 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 17 Dec 2020 20:44:15 GMT
Subject: Integrated: Merge jdk16
In-Reply-To: <LD8ANDgogS-bx4izFlwhL_9-MwiCI2jNn6a4Ehb2wmA=.80d8ff3d-e60b-4634-bcce-943c96d6edbd@github.com>
References: <LD8ANDgogS-bx4izFlwhL_9-MwiCI2jNn6a4Ehb2wmA=.80d8ff3d-e60b-4634-bcce-943c96d6edbd@github.com>
Message-ID: <Rb-Ei4T62YffDeV4VkDR96LjtERDt8U5cJKXE0Vk7kY=.67f13552-6ea7-4be4-a61d-d546c313b68f@github.com>

On Thu, 17 Dec 2020 20:38:45 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: f15528eb
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f15528eb
Stats:     773 lines in 63 files changed: 449 ins; 124 del; 200 mod

Merge

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

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

From vromero at openjdk.java.net  Thu Dec 17 23:47:05 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 17 Dec 2020 23:47:05 GMT
Subject: [jdk16] RFR: 8213032: program fails with LambdaConversionException at
 execution time
Message-ID: <HZyfDgw8f2jrX2tBCmAlzkkIKrF7pMd_ssnts-bVSyk=.2c6bfd8c-6304-4a0e-9c5c-88a6c8cef96d@github.com>

Hi,

Currently javac is accepting this code:

import java.util.stream.*;

public class Test {
    interface I {}
    static abstract class C { }
    static class A extends C implements I { }
    static class B extends C implements I { }

    static String f(I i) { return null; }

    public static void main(String[] args) {
        Stream.of(new A(), new B()).map(Test::f).forEach(System.out::println);
    }
}

the line with the method reference can also be written using a lambda expression like in:

        Stream.of(new A(), new B()).map(i -> f(i)).forEach(System.out::println);
but the code with the method reference, is failing later at execution time with `LambdaConversionException`. Currently javac is desugaring the method reference to the equivalent lambda but the argument of generated lambda is: `Test$I` at the same time the target type of the method reference has argument with type `C & I` which will be desugared by the compiler to `C`. This is the reason for the runtime error. The right type for the argument of the desugared method generated by javac is `C` which is what this patch is doing. The change to method `ReferenceTranslationContext::bridgedRefSig` has been done in order to obtain a more exact version of the target type, as the current implementation is returning `Object` in most cases, which is OK, but I think that we could generate a better, more accurate, type.

TIA for the review

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

Commit messages:
 - 8213032: program fails with LambdaConversionException at execution time

Changes: https://git.openjdk.java.net/jdk16/pull/49/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=49&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8213032
  Stats: 61 lines in 2 files changed: 54 ins; 4 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/49.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/49/head:pull/49

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

From ysatowse at openjdk.java.net  Fri Dec 18 01:34:15 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Fri, 18 Dec 2020 01:34:15 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v4]
In-Reply-To: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
Message-ID: <vZkUHKS22sXksvEkZIlwencSsNSc0HTcCR-5Mp71daQ=.06eeb39b-39c4-4854-861d-432a4b95e946@github.com>

> HTML4 is no longer supported in javadoc.
> 
> doclint needs to drop HTML4 support as well.
> The changes consist of:
> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
> * Modifying test code and expected outputs to be checked in HTML5

Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:

  5th: 8257204 and 8256313
  8257204: Remove usage of -Xhtmlversion option from javac
  8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/893/files
  - new: https://git.openjdk.java.net/jdk/pull/893/files/30db3882..f9ae0c5f

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

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

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

From ysatowse at openjdk.java.net  Fri Dec 18 02:34:16 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Fri, 18 Dec 2020 02:34:16 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
Message-ID: <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>

> HTML4 is no longer supported in javadoc.
> 
> doclint needs to drop HTML4 support as well.
> The changes consist of:
> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
> * Modifying test code and expected outputs to be checked in HTML5

Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:

  5th: 8258460: Remove --doclint-format option from javac

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/893/files
  - new: https://git.openjdk.java.net/jdk/pull/893/files/f9ae0c5f..261f207a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=893&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=893&range=03-04

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

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

From ysatowse at openjdk.java.net  Fri Dec 18 02:42:00 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Fri, 18 Dec 2020 02:42:00 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v3]
In-Reply-To: <BLs1ScSdxGuJRpKnq8ofPhBe5NMV0oV8lb-u-bLpAg0=.9e77a827-999f-4e56-9d29-9d23dc164d50@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <198fmbGGxYO2VRc3gAVf89rYSoQFlnKyThNUzvuI5uk=.da1f6607-9e2e-48c2-8ab3-833f207a960c@github.com>
 <BLs1ScSdxGuJRpKnq8ofPhBe5NMV0oV8lb-u-bLpAg0=.9e77a827-999f-4e56-9d29-9d23dc164d50@github.com>
Message-ID: <rY5rzSkeAG6Y5_HV9oA4UW_wY0957Dk7nvE6fSdY-ws=.02fe43aa-e5ae-425b-beb3-23d414423408@github.com>

On Thu, 17 Dec 2020 04:58:21 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Yoshiki Sato has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   8257204 and 8256313
>>   8257204: Remove usage of -Xhtmlversion option from javac
>>   8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option
>
> Mostly OK; some minor suggestions

Some related changes to 8258460 in closed repo is here.
https://orahub.oci.oraclecorp.com/yoshiki_sato/jdk/-/merge_requests/new?merge_request%5Bsource_branch%5D=JDK-8247957_2

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

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

From lgxbslgx at gmail.com  Fri Dec 18 14:38:52 2020
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Fri, 18 Dec 2020 22:38:52 +0800
Subject: Potential bugs when using the JavaCompiler API.
Message-ID: <CAPSsVqh3Udm7wim117v10030nueODOLKLd3SjmNTUkfE_CcXbw@mail.gmail.com>

Hi all,

When I was working on the JDK-8232939[1], I found some strange points and
suspicious bugs. The origin of the issues is the `Context` of
`StandardJavaFileManager`(eg: JavacFileManager) and the `Context` of
`CompilationTask`(eg: JavacTaskImpl) is not same. As we can see in class
`JavacTool`, the methods `getStandardFileManager` and `getTask` both create
its new `Context`.

When creating its new `Context` to isolate. We can call it as the
*decoupled* part of `StandardJavaFileManager` and `CompilationTask`.
When using `getTask` with a file manager to get a `CompilationTask`, the
`getTask` will set some properties of the file manager. We can call it as
the *coupled* part of `StandardJavaFileManager` and `CompilationTask`.

The decoupled and coupled part of `StandardJavaFileManager` and
`CompilationTask` are strange and both have suspicious bugs which are shown
below.

1. Bugs about the decoupled part.
    The properties of `JavacFileManager`, especially  `Log` and `Options`,
are not same as the corresponding items of `JavacTaskImpl`. Some issues
will occur.

    The first example is that the OptionGroup.FILEMANAGER options won't be
validated. This is a bug about the different `Options`.
    As you can see the test code[2]. `--module-source-path` and
`--source-path` are both set. It is wrong because the man document states
that users can use only one of `--module-source-path` and `--source-path`,
and can't use both. These wrong code are accepted by the compiler now.
Because when using the compiler API, the options property of file manager
only contain the OptionGroup.FILEMANAGER options and the options property
of compiler task only contain the OptionGroup.BASIC options. When
validating options[3], only the options of compiler task will be validated.
That is said, the OptionGroup.FILEMANAGER options won't be validated. It is
unacceptable because the manner of compiler API is different from the
compiler command line.

    The second example is JDK-8232939[1]. It is a bug about the different
`Log.`
    The file manager generates the errors during the parse stage and
reports the error by using its own `Log`. After the parse stage, the
compiler uses `stopIfError` to check if the errors occur and will stop the
later stages if any error occurs. Unfortunately, the method `stopIfError`
checks the `Log` of the compiler instead of the `Log` of the file manager
so that it can't find any error generated by the file manager. So the
compiler continues the later stages unexpectedly.

    These two bugs(one about `Options`, another about `Log`) show that
current decoupled way is not so good. If we deep into all the properties of
these two different context, some more bugs may be found.

2. Bugs about the coupled way.
    This aspect are more important and more unacceptable. As you can see
the code snippet below.
        ```
        var compiler = ToolProvider.getSystemJavaCompiler();
        var fm = compiler.getStandardFileManager(null, null, null);
        var files = fm.getJavaFileObjects(Path.of("Test.java"));
        JavaCompiler.CompilationTask task1 = compiler.getTask(null, fm,
null, List.of("-XDrawDiagnostics", "-encoding", "ASCII"), null, files);
        JavaCompiler.CompilationTask task2 = compiler.getTask(null, fm,
null, List.of("-XDrawDiagnostics"/*some more options*/), null, files);
        System.out.println(task1.call());
        System.out.println(task2.call());
        ```
    The OptionGroup.FILEMANAGER options of `task1`("-encoding", "ASCII")
will be taken to `task2` and  vice versa. Because the options of file
manager won't be cleared. It required the users clear the options manually.
Unfortunately, the users, included me, use it incorrectly. The probably
correct usage is shown below: run the first task and clear the information
of previous task before getting another task. As you can see, the clear
work is hard because the users don't know the internal of the compiler.
Currently I can't find a good way to clear, too.
        ```
        var compiler = ToolProvider.getSystemJavaCompiler();
        var fm = compiler.getStandardFileManager(null, null, null);
        var files = fm.getJavaFileObjects(Path.of("Test.java"));
        JavaCompiler.CompilationTask task1 = compiler.getTask(null, fm,
null, List.of("-XDrawDiagnostics", "-encoding", "ASCII"), null, files);
        System.out.println(task1.call());
        // Do some clear work. Omit.
        JavaCompiler.CompilationTask task2 = compiler.getTask(null, fm,
null, List.of("-XDrawDiagnostics"), null, files);
        System.out.println(task2.call());
        ```
    As the document stated:
    > The standard file manager serves two purposes:
    >     basic building block for customizing how a compiler reads and
writes files
    >     sharing between multiple compilation tasks
    But the options and task's own individual other information perhaps
shouldn't be shared.


To solve the problem completely, we should find a better way to
decouple file manager and compilation task instead of using the new
`Context` directly and simply.
I have been thinking of a better solution these days but I can't find a
satisfying solution. I want to share the problem with you to see your
opinions. This is the reason of this email.

Any opinion or idea are appreciated!

[1] https://bugs.openjdk.java.net/browse/JDK-8232939
[2]
https://github.com/openjdk/jdk/blob/853c04712d24788b6d30d54443ac9277a898311b/test/langtools/tools/javac/modules/AnnotationProcessing.java#L1607
[3]
https://github.com/openjdk/jdk/blob/853c04712d24788b6d30d54443ac9277a898311b/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java#L409
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20201218/ea5bb476/attachment.htm>

From wmdietl at openjdk.java.net  Fri Dec 18 18:20:56 2020
From: wmdietl at openjdk.java.net (Werner Dietl)
Date: Fri, 18 Dec 2020 18:20:56 GMT
Subject: [jdk16] RFR: 8254023: A module declaration is not allowed to be a
 target of an annotation that lacks an @Target meta-annotation
In-Reply-To: <BzOpe0tf6KMcHXh9WLjl91lVXtsLg-4YhC5evsVskM8=.cffed619-e078-4be1-88bd-d969d9981088@github.com>
References: <BzOpe0tf6KMcHXh9WLjl91lVXtsLg-4YhC5evsVskM8=.cffed619-e078-4be1-88bd-d969d9981088@github.com>
Message-ID: <xqnX0_rtKyjIvPSlotQiVp8wh4fZGxkM2dhNcGeJhzA=.9be23924-6363-4423-bf3c-451f63442ba4@github.com>

On Wed, 16 Dec 2020 12:02:58 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> This patch adds `names.MODULE` to `com.sun.tools.javac.comp.Check.dfltTargetMeta` to fix this issue. And it also adds some corresponding tests.
> 
> The previous discussion is in https://github.com/openjdk/jdk/pull/622.
> 
> Best Regards.

test/langtools/tools/javac/annotations/8254023/T8254023.java line 27:

> 25:  * @test
> 26:  * @bug 8254023
> 27:  * @summary A module declaration is not allowed to be a target of an annotation that lacks an (at)Target meta-annotation

@lgxbslgx I'm confused by the "is not allowed". Isn't this testing that this is allowed without an error?
I realize that that is in the tile of JDK-8254023, but the resolution is to allow such annotations, right?

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

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

From jonathan.gibbons at oracle.com  Fri Dec 18 22:17:09 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 18 Dec 2020 14:17:09 -0800
Subject: Potential bugs when using the JavaCompiler API.
In-Reply-To: <CAPSsVqh3Udm7wim117v10030nueODOLKLd3SjmNTUkfE_CcXbw@mail.gmail.com>
References: <CAPSsVqh3Udm7wim117v10030nueODOLKLd3SjmNTUkfE_CcXbw@mail.gmail.com>
Message-ID: <8e5d881e-c3ec-231e-a296-e3b906844ce8@oracle.com>

Hi,

Thanks for your interest in this area.

The bugs, such as they are, are more in the specification than the 
implementation, and are somewhat tricky to fix as well as might be 
expected. There is one task that is part bug, part enhancement, 
depending on your point of view, and equally tricky to figure out, which 
is one of the reasons it has not been? done before now.

Generally, you should not think of the `JavaFileManager` API and 
`JavaCompiler.getTask` options as equivalent. The file manager is a 
lower level abstraction than the compiler, and applicable in more 
contexts than `javac`.? By itself, it is not wrong for a file manager to 
have combinations of locations set, because there may be situations 
(i.e. some tools) where that is desirable and appropriate. And, 
incorrect settings for a file manager are generally reported by throwing 
`IllegalArgumentException` in preference to using a diagnostic 
listener.? And, while it does not make sense to allow conflicting 
options like `--source-path` and `--module-source-path` on the javac 
command line, it seemed better to permit file managers with both set and 
to figure a reasonable policy to handle that situation.

Also, note that when using the Compiler API and `JavaCompiler.getTask`, 
the compiler has to be able to accept any suitable implementation of a 
file manager, and not just the standard one returned by the JDK 
implementation of 
`ToolProvider.getSystemJavaCompiler().getStandardJavaFileManager`. And, 
for better or worse, there is no API on a file manager to determine if 
errors have occurred, in a way that would be reasonable for the 
internals of javac to detect and react to.

Your comments related to your example with `task1` and `task2` are 
somewhat reasonable. Although it is on one hand not surprising that 
options to getTask affect the file manager, on the other, it would be 
nice if the changes were transient. The general idea we have had in the 
past is to create a temporary file manager inside the compiler that 
wraps and delegates to the given file manager, except for the arguments 
given to the options. However we have not thought through any detailed 
design to make that happen.

As for the specification, yes, the API in this area is somewhat 
under-specified. Part of it is a general problem with JDK API 
specifications: both JavaCompiler and JavaFileManager are 
service-provider interfaces, and while it is easy enough to specify the 
common properties of all implementations of these interfaces, there is 
not a good way/place to specify the additional characteristics and 
properties of specific implementations. For the JavaCompiler API, we 
want to allow other vendors to provide alternate implementations of a 
Java Compiler (subject to all the appropriate conformance rules), and so 
it is inappropriate in the Java SE class `javax.tools.JavaCompiler` to 
give JDK-specific details of the JDK implementation of that interface.? 
And, for any implementations of `JavaFileManager`, we don't want to 
over-specify it and so restrict the kinds of implementations anyone can 
provide.? The one thing of note is that whereas there was no good 
solution to this specification problem in JDK 6, since JDK 9, and the 
Java Platform Module System, we do have a reasonable place to put some 
of this specification, and that is the module documentation for the 
`jdk.compiler` module. In that module, we could write paragraphs that 
give additional specification details for the implementation of the 
`JavaCompiler` interface provided by the module, and for the standard 
file manager returned by the `getStandardJavaFileManager` method of that 
implementation. It's "not great" that the documentation with be 
narrative paragraphs not directly linked into the shared documentation 
in the `javax.tools` interface, but at least it would be somewhere, 
which is better than now.

-- Jon

On 12/18/20 6:38 AM, Guoxiong Li wrote:
> Hi all,
>
> When I was working on?the JDK-8232939[1], I found some strange points 
> and suspicious bugs. The origin of the issues is the `Context` of 
> `StandardJavaFileManager`(eg: JavacFileManager) and the `Context` of 
> `CompilationTask`(eg: JavacTaskImpl) is not same. As we can see in 
> class `JavacTool`, the?methods `getStandardFileManager` and `getTask` 
> both create its new `Context`.
>
> When creating its new `Context` to?isolate. We can call it as the 
> *decoupled*?part of `StandardJavaFileManager` and `CompilationTask`.
> When using `getTask` with a file manager to get a `CompilationTask`, 
> the `getTask` will set some properties of the file manager. We can 
> call it as the *coupled* part of?`StandardJavaFileManager` and 
> `CompilationTask`.
>
> The?decoupled and coupled part of `StandardJavaFileManager` and 
> `CompilationTask` are strange and both have suspicious bugs which are 
> shown below.
>
> 1. Bugs about the decoupled part.
> ? ? The properties of `JavacFileManager`, especially? `Log` and 
> `Options`, are not same as the corresponding items of `JavacTaskImpl`. 
> Some issues will occur.
>
> ? ? The first example is that the OptionGroup.FILEMANAGER options 
> won't be validated. This is a bug about the different `Options`.
> ? ? As you can see the test code[2]. `--module-source-path` and 
> `--source-path` are both set. It is wrong because the man document 
> states that users can use?only one of `--module-source-path` and 
> `--source-path`, and can't use both. These wrong code are accepted by 
> the compiler now. Because when using the compiler API, the options 
> property of file manager only contain the?OptionGroup.FILEMANAGER 
> options and the options?property of compiler task only contain 
> the?OptionGroup.BASIC options. When validating options[3], only the 
> options of compiler task will be validated. That is said, 
> the?OptionGroup.FILEMANAGER options won't be validated. It is 
> unacceptable because the manner of compiler API is different from the 
> compiler command line.
>
> ? ? The second example is?JDK-8232939[1]. It is a bug about the 
> different `Log.`
> ? ? The file manager generates the errors during the parse stage and 
> reports the error by using its own `Log`. After the parse stage, the 
> compiler uses `stopIfError` to check if the errors occur and will stop 
> the later stages if any error occurs. Unfortunately, the method 
> `stopIfError` checks the `Log` of the compiler instead of the `Log` of 
> the file manager so that it can't find any error generated by the file 
> manager. So the compiler continues the later stages unexpectedly.
>
> ? ? These two bugs(one about `Options`, another about `Log`) show that 
> current decoupled way is not so good. If we deep into all the 
> properties of these two different context, some more bugs may be found.
>
> 2. Bugs about the coupled way.
> ? ? This aspect are more important and more unacceptable. As you can 
> see the code snippet below.
> ? ? ? ? ```
> ? ? ? ? var compiler = ToolProvider.getSystemJavaCompiler();
> ? ? ? ? var fm = compiler.getStandardFileManager(null, null, null);
> ? ? ? ? var files = fm.getJavaFileObjects(Path.of("Test.java"));
> ? ? ? ? JavaCompiler.CompilationTask task1 = compiler.getTask(null, 
> fm, null, List.of("-XDrawDiagnostics", "-encoding", "ASCII"), null, 
> files);
> ? ? ? ? JavaCompiler.CompilationTask task2 = compiler.getTask(null, 
> fm, null, List.of("-XDrawDiagnostics"/*some more options*/), null, files);
> ? ? ? ? System.out.println(task1.call());
> ? ? ? ? System.out.println(task2.call());
> ? ? ? ? ```
> ? ??The?OptionGroup.FILEMANAGER options of `task1`("-encoding", 
> "ASCII") will be taken to `task2` and vice versa. Because the options 
> of file manager won't be cleared. It required the users clear the 
> options manually. Unfortunately, the users, included me, use it 
> incorrectly. The probably correct usage is shown below: run the first 
> task and clear the information of previous task before getting another 
> task. As you can see, the clear work is hard because the users don't 
> know the internal of the compiler. Currently I can't find a good way 
> to clear, too.
> ? ? ? ? ```
> ? ? ? ? var compiler = ToolProvider.getSystemJavaCompiler();
> ? ? ? ? var fm = compiler.getStandardFileManager(null, null, null);
> ? ? ? ? var files = fm.getJavaFileObjects(Path.of("Test.java"));
> ? ? ? ? JavaCompiler.CompilationTask task1 = compiler.getTask(null, 
> fm, null, List.of("-XDrawDiagnostics", "-encoding", "ASCII"), null, 
> files);
> ? ? ? ? System.out.println(task1.call());
> ? ? ? ? // Do some clear work. Omit.
> ? ? ? ? JavaCompiler.CompilationTask task2 = compiler.getTask(null, 
> fm, null, List.of("-XDrawDiagnostics"), null, files);
> ? ? ? ? System.out.println(task2.call());
> ? ? ? ? ```
> ? ? As the document stated:
> ? ? >?The standard file manager serves two purposes:
> ? ? >? ? ?basic building block for customizing how a compiler reads 
> and writes files
> ? ? >? ? ?sharing between multiple compilation tasks
> ? ? But the options and task's own?individual other information 
> perhaps shouldn't be shared.
>
>
> To solve the problem completely, we should find a better way to 
> decouple?file manager and compilation task instead of using the new 
> `Context` directly and simply.
> I have been thinking of a better solution these days but I can't find 
> a satisfying solution. I want to share the problem with you to see 
> your opinions. This is the reason of this email.
>
> Any opinion or idea are appreciated!
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8232939 
> <https://bugs.openjdk.java.net/browse/JDK-8232939>
> [2] 
> https://github.com/openjdk/jdk/blob/853c04712d24788b6d30d54443ac9277a898311b/test/langtools/tools/javac/modules/AnnotationProcessing.java#L1607 
> <https://github.com/openjdk/jdk/blob/853c04712d24788b6d30d54443ac9277a898311b/test/langtools/tools/javac/modules/AnnotationProcessing.java#L1607>
> [3] 
> https://github.com/openjdk/jdk/blob/853c04712d24788b6d30d54443ac9277a898311b/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java#L409 
> <https://github.com/openjdk/jdk/blob/853c04712d24788b6d30d54443ac9277a898311b/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java#L409>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20201218/ab928e39/attachment-0001.htm>

From jjg at openjdk.java.net  Sat Dec 19 01:14:00 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sat, 19 Dec 2020 01:14:00 GMT
Subject: [jdk16] RFR: JDK-8258443: doclint should be service-loaded with
 system class loader
Message-ID: <Mvlw9FnB-ia4ub0bid0tgiYcCCevRZ-LJBZhwWRa1i8=.93855ab3-6d56-4269-919e-26858a851249@github.com>

Trivial fix to use the system class loader when loading doclint for javac

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

Commit messages:
 - JDK-8258443: doclint should be service-loaded with system class loader

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

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

From bsrbnd at gmail.com  Sat Dec 19 12:37:13 2020
From: bsrbnd at gmail.com (B. Blaser)
Date: Sat, 19 Dec 2020 13:37:13 +0100
Subject: Records, Intersection type and lambda
In-Reply-To: <ce41110b-757d-b1f0-7358-a3a716ef52a4@oracle.com>
References: <1634118475.2157445.1605459778491.JavaMail.zimbra@u-pem.fr>
 <CAEgw74At3W0manZ4yQsUewZz8iYJ5D136MXLw_nfR6OzjjYUcA@mail.gmail.com>
 <1485898290.1122166.1605599180102.JavaMail.zimbra@u-pem.fr>
 <CAEgw74DK6=Hvehk+GxVL8TcKeMFxUsHevSU0ATzTJQzGB-AoaA@mail.gmail.com>
 <ce41110b-757d-b1f0-7358-a3a716ef52a4@oracle.com>
Message-ID: <CAEgw74Azjxk34K0Mo5b9-UxDCBDT6tE1M0K9sZ837aSi28LdxA@mail.gmail.com>

Thanks Vicente.

I guess I see the idea with the line you added to my original patch.
However, I still believe it's not necessary for the purpose of this
fix targeted to 16.
So, I'd suggest to file a separate issue for that (to 17?) as it might
have some side effects.

What do you think?
Bernard

On Thu, 17 Dec 2020 at 21:14, Vicente Romero <vicente.romero at oracle.com> wrote:
>
> Hi,
>
> There was a review that got closed bc nobody reviewed it. I will prepare
> another PR targeting 16,
>
> Vicente
>
> On 11/18/20 10:21 AM, B. Blaser wrote:
> > On Tue, 17 Nov 2020 at 08:46, <forax at univ-mlv.fr> wrote:
> >> yes, thanks !
> >> still not fixed :(
> > Probably not a frequent issue with usual classes but I believe this
> > might be a rather common use case with records, so I verified that my
> > initial fix is still working fine with your latest example.
> > However, Vicente seems to be investigating something else in the same
> > area but I'd suggest to eventually file a separate issue for that in
> > order to go ahead with my proposal, what do you think?
> >
> > Thanks,
> > Bernard
>

From github.com+13688759+lgxbslgx at openjdk.java.net  Sat Dec 19 13:54:05 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sat, 19 Dec 2020 13:54:05 GMT
Subject: RFR: 8258662: JDK 17ea: Crash compiling instanceof check involving
 sealed interface
Message-ID: <NLtC9dIs-LiSiV5DFhmE7PcGsm2xhvG-n63_UnlELbw=.c2702d23-38ee-428f-9136-d0de5bbaf9f0@github.com>

Hi all,

The method `Types.isCastable` uses method `Types.areDisjoint` to do some check. But `Types.isCastable` doesn't check the type of the parameter before invoking method `Types.areDisjoint`. This patch adds the corresponding check and add a test case.

Thank you for taking the time to review.

Best Regards.

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

Commit messages:
 - 8258662: JDK 17ea: Crash compiling instanceof check involving sealed interface

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Sat Dec 19 15:10:59 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sat, 19 Dec 2020 15:10:59 GMT
Subject: RFR: 8258525: Some existing tests should use /nodynamiccopyright/
 instead of the standard header
In-Reply-To: <-_LQhyFiYWgqUwwvr4yQuwdzUrhfef8ryPgOvuwZYwg=.64a37358-4973-4c1d-a218-80293d83366a@github.com>
References: <epkxwkylg6_rkP9V3hrA3VaZOCJmmY51bgICJN_y5wg=.f2805d11-4bd9-4f4a-a477-d94452aad2e9@github.com>
 <7hafV_O2jHgs64xzjogkbZbfzpBvXvYkjisQEveKXCo=.6f8df181-19b8-4716-885b-1eb249c4080a@github.com>
 <-_LQhyFiYWgqUwwvr4yQuwdzUrhfef8ryPgOvuwZYwg=.64a37358-4973-4c1d-a218-80293d83366a@github.com>
Message-ID: <T2k3qsT52MFCumh3VnJuj51YB3-A4mrVBSGfmjQYtOA=.a8a5c937-2c47-48ae-89c2-4e89bd429bb7@github.com>

On Thu, 17 Dec 2020 00:20:11 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Filed JBS issue: https://bugs.openjdk.java.net/browse/JDK-8258525
>
> I'm ready to approve this change, once the issue has been set correctly

The issue was set correctly. It is good to go on now.

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

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

From jjg at openjdk.java.net  Sun Dec 20 02:48:56 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sun, 20 Dec 2020 02:48:56 GMT
Subject: RFR: 8258662: JDK 17ea: Crash compiling instanceof check
 involving sealed interface
In-Reply-To: <NLtC9dIs-LiSiV5DFhmE7PcGsm2xhvG-n63_UnlELbw=.c2702d23-38ee-428f-9136-d0de5bbaf9f0@github.com>
References: <NLtC9dIs-LiSiV5DFhmE7PcGsm2xhvG-n63_UnlELbw=.c2702d23-38ee-428f-9136-d0de5bbaf9f0@github.com>
Message-ID: <CfBzGbv09RoitEkBPSXBxtNBjw-nhfeWQgObP-YmbiM=.1df84535-3fc8-4f47-bc3e-0891be65b071@github.com>

On Sat, 19 Dec 2020 13:49:43 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> The method `Types.isCastable` uses method `Types.areDisjoint` to do some check. But `Types.isCastable` doesn't check the type of the parameter before invoking method `Types.areDisjoint`. This patch adds the corresponding check and add a test case.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

In general, the coding style in javac is to use methods and/or the kind to determine whether is symbol is the symbol for a class or not.

I'll leave it to others to recommend the current best practice for a change like this.

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

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Sun Dec 20 03:31:55 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sun, 20 Dec 2020 03:31:55 GMT
Subject: RFR: 8231622: SuppressWarning("serial") ignored on field
 serialVersionUID [v4]
In-Reply-To: <l9Z3mt7m92ML2Kf68Ed-1BH50dO-KycVHS7jC0YEdxY=.77e6e84d-b27b-4771-bfeb-ac307405546e@github.com>
References: <_2Z8RhLQo1F6ddk2cZS5J_hoRMPLCe5ssVMeyyscFnc=.d267dddd-12d6-4968-a32d-6bd3510daf45@github.com>
 <pAZwuCZyGdGLQ1Hk165sxorpi-S4qq2LDutt2ZUSnvM=.c2c59d4d-d830-45f9-803d-10e2b5cd5cb9@github.com>
 <l9Z3mt7m92ML2Kf68Ed-1BH50dO-KycVHS7jC0YEdxY=.77e6e84d-b27b-4771-bfeb-ac307405546e@github.com>
Message-ID: <BRU-8YQlOjcxVbOE2ze8bjT0oFo8RogmB515EBLcWAo=.0f42a433-6a1d-4549-9fb8-c9dac02a94d9@github.com>

On Thu, 17 Dec 2020 00:27:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use method ToolBox.checkEqual
>
> Latest change looks good

Could I ask your help to sponsor this patch? Thanks a lot.

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

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

From jiaywe at gmail.com  Sun Dec 20 09:49:03 2020
From: jiaywe at gmail.com (JiaYanwei)
Date: Sun, 20 Dec 2020 17:49:03 +0800
Subject: [Ask for sponsoring] Fix another NPE in
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:571)
Message-ID: <CAM1U-w_DyumchOqfy5Hn4FwWtW-e7p=o399neaHXcS_ZAL9H4Q@mail.gmail.com>

Hi all,

I had found & fixed a javac issue like
https://bugs.openjdk.java.net/browse/JDK-8229862 , and created a PR on
Github: https://github.com/openjdk/jdk/pull/1479 .

I have no account to create JIRA issue, and I'm not sure whether the code
style as well as the solution itself are appropriate. Could anyone sponsor
me? Thanks a lot.

Best Regards.

---

The Issue:
javac crashes with a NPE when compiling such code:

- a local class captured a reference type local variable of a enclosed
lambda (which contains multiple local variables with different types)
- instance the local class in a nested lambda
Affects all versions from Java 8 to 16-ea, here is a example output with
OpenJDK 15.0.1:

An exception has occurred in the compiler (15.0.1). Please file a bug
against the Java compiler via the Java bug reporting page (
http://bugreport.java.com) after checking the Bug Database (
http://bugs.java.com) for duplicates. Include your program, the following
diagnostic, and the parameters passed to the Java compiler in your report.
Thank you.
java.lang.NullPointerException: Cannot read field "sym" because
"this.lvar[1]" is null
    at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:571)
    at
jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.load(Items.java:399)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:889)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:1942)
    at
jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1800)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:864)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1723)
    at
jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1532)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:618)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:669)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1084)
    at
jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1047)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:954)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:917)
    at
jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:893)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2395)
    at
jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:756)
    at
jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1644)
    at
jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1612)
    at
jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973)
    at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317)
    at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
    at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:59)
    at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:45)
printing javac parameters to: /tmp/javac.20201126_141249.args

The minimal reproducing code is:

class Main {
    static Runnable runnable = () -> {
        boolean b0 = false;
        String s0 = "hello";

        class Local {
            int i = s0.length();
        }

        Runnable dummy = () -> new Local();
    };
}

If the captured variable is a primitive type, the code will compile but
cause a runtime crash at startup. e.g.:

public class CaptureInt {
    static Runnable runnable = () -> {
        boolean b0 = false;
        int i0 = 5;

        class Local {
            int i = i0 + 2;
        }

        Runnable dummy = () -> new Local();
    };

    public static void main(String args[]) {
    }
}

Reason & Solution:

During compilation, the captured variable was correctly synthetized as a
synthetic argument in the synthetic methods for the nested lambda after
desugar().
But the synthetic argument was not used when loading free variables, and it
always use the original symbol for the original variable as if not in a
nested lambda.
My experimental solution is substituting the symbols in free variables that
were captured as synthetic arguments in nested lambda.
Welcome any advice and better solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20201220/84021a8a/attachment-0001.htm>

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 13:18:01 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 13:18:01 GMT
Subject: RFR: 8066694: Strange code in JavacParser.java
Message-ID: <sJOs1F9eRA5wwzx488HkuQcEVdaqlRctC4aH5Eninrk=.6705cef5-c630-441f-8f46-8fd2acb0403f@github.com>

This code was introduced in main repository under https://bugs.openjdk.java.net/browse/JDK-8006775
I checked original commit in `type-annotations/langtools` repository: https://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/71f35e4b93a5
Looks like it's not a merge problem.

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

Commit messages:
 - 8066694: Strange code in JavacParser.java

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

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

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 17:10:02 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 17:10:02 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
Message-ID: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>

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

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

Commit messages:
 - 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
 - 8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo

Changes: https://git.openjdk.java.net/jdk/pull/1853/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8080272
  Stats: 319 lines in 26 files changed: 1 ins; 248 del; 70 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

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

From github.com+13688759+lgxbslgx at openjdk.java.net  Sun Dec 20 17:39:02 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sun, 20 Dec 2020 17:39:02 GMT
Subject: RFR: 8255729:
 com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient
Message-ID: <lPSFGsaxcZ_GipYihdGoOmSvnHPK7saOxBDsejkVFT8=.9f37d2a7-369d-44f0-a2a7-5afddcdc0960@github.com>

Hi all,

`FilerOutputStream` extends `FilterOutputStream` without overwriting the method `write(byte b[], int off, int len)` which would suffer from the performance problem.
This patch fixes it and adds some `@Override` to polish the code. But I can't find a good way to write a corresponding test case. Maybe it doesn't need a test case. And all existing tests in `test/langtools/tools/javac` passed locally.

Thank you for taking the time to review.

Best Regards.

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

Commit messages:
 - Modify copyright.
 - 8255729: com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient

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

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

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 17:46:10 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 17:46:10 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v2]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <hY6bq5j7bf8POwY5aKS87ncspu7iRgBq-8N8PZsW6Os=.e4ecc2ff-a299-4221-92be-6f98756c933e@github.com>

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

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

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  revert changes in JrtPath. They compiled with java 8 language level

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/fa3ae201..90b1a455

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

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

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

From alanb at openjdk.java.net  Sun Dec 20 19:45:54 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 20 Dec 2020 19:45:54 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>

On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

jrtfs is compiled twice, the second is to --release 8 so it can be packaged into jrt-fs.jar for use by IDEs/tools running on older JDK releases. So need to be careful with the changes here as it will likely causing build breakage.

We try to keep the changes to ASM to a minimum, might be better to leave this change out of the patch.

One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1853

From jjg at openjdk.java.net  Sun Dec 20 20:04:54 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sun, 20 Dec 2020 20:04:54 GMT
Subject: RFR: 8255729:
 com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient
In-Reply-To: <lPSFGsaxcZ_GipYihdGoOmSvnHPK7saOxBDsejkVFT8=.9f37d2a7-369d-44f0-a2a7-5afddcdc0960@github.com>
References: <lPSFGsaxcZ_GipYihdGoOmSvnHPK7saOxBDsejkVFT8=.9f37d2a7-369d-44f0-a2a7-5afddcdc0960@github.com>
Message-ID: <Qt7_eNilaKkkOPap3BYdiHDtKMLRMwse2eMOBrwwFQU=.28d33208-a42f-49ab-9342-eb7cd72214dc@github.com>

On Sun, 20 Dec 2020 17:29:59 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> `FilerOutputStream` extends `FilterOutputStream` without overwriting the method `write(byte b[], int off, int len)` which would suffer from the performance problem.
> This patch fixes it and adds some `@Override` to polish the code. But I can't find a good way to write a corresponding test case. Maybe it doesn't need a test case. And all existing tests in `test/langtools/tools/javac` passed locally.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

Normally, I would leave this to @jddarcy, who wrote this code, but he is currently on vacation.

I'll approve it with the understanding that I'll help make changes if Joe thinks that any are necessary.

src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacFiler.java line 281:

> 279:         public void write(byte b[], int off, int len) throws IOException {
> 280:             if ((off | len | (b.length - (len + off)) | (off + len)) < 0)
> 281:                 throw new IndexOutOfBoundsException();

This code is pretty ugly, treating integers as bit-wise values. However, I see it is the same as in FilterOutputStream itself.

-------------

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1854

From jjg at openjdk.java.net  Sun Dec 20 20:04:55 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sun, 20 Dec 2020 20:04:55 GMT
Subject: RFR: 8255729:
 com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient
In-Reply-To: <Qt7_eNilaKkkOPap3BYdiHDtKMLRMwse2eMOBrwwFQU=.28d33208-a42f-49ab-9342-eb7cd72214dc@github.com>
References: <lPSFGsaxcZ_GipYihdGoOmSvnHPK7saOxBDsejkVFT8=.9f37d2a7-369d-44f0-a2a7-5afddcdc0960@github.com>
 <Qt7_eNilaKkkOPap3BYdiHDtKMLRMwse2eMOBrwwFQU=.28d33208-a42f-49ab-9342-eb7cd72214dc@github.com>
Message-ID: <jqwbbBMPiSfHfXOZ4I3eiBazJTv6wS5GppSV4ctdIFw=.55a051c3-e399-47c1-8592-561f0af829de@github.com>

On Sun, 20 Dec 2020 20:00:34 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Hi all,
>> 
>> `FilerOutputStream` extends `FilterOutputStream` without overwriting the method `write(byte b[], int off, int len)` which would suffer from the performance problem.
>> This patch fixes it and adds some `@Override` to polish the code. But I can't find a good way to write a corresponding test case. Maybe it doesn't need a test case. And all existing tests in `test/langtools/tools/javac` passed locally.
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Normally, I would leave this to @jddarcy, who wrote this code, but he is currently on vacation.
> 
> I'll approve it with the understanding that I'll help make changes if Joe thinks that any are necessary.

Regarding a test, I agree that one is not practical or necessary. The policy in this case is to mark the JBS issue with one of the `noreg-*` series on labels. `noreg-cleanup` is the appropriate one in this case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1854

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 20:09:12 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 20:09:12 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v3]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <oNRktI1p1Z3VLqIBLK6yPqk-mDMFmh8EzMrRuHmtp8w=.cdd1f3fe-c7ba-4e83-8220-da2e2582004f@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  revert changes in ASM
  use Files.copy in sjavac

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/90b1a455..2ae88471

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=01-02

  Stats: 18 lines in 2 files changed: 8 ins; 6 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 20:15:09 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 20:15:09 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v4]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <F5_oGJSwGgKTiBxBuzIa3DietHA6DAukNrG1tKXMwzQ=.89920e48-6c93-4ea9-b383-63dc9ba58fa9@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  use Files.copy in MLet too

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/2ae88471..c4133d32

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 20:22:10 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 20:22:10 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v5]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <vAvbxQL52sRM-zF5IuAEfbLXaj-8xfux8XNvlDyQTno=.f1389529-1b8c-4d5a-a335-bea8d182586f@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  use Files.copy in Win32PrintJob too

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/c4133d32..ec602c1a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=03-04

  Stats: 14 lines in 1 file changed: 2 ins; 10 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Sun Dec 20 20:25:52 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 20 Dec 2020 20:25:52 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
Message-ID: <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>

On Sun, 20 Dec 2020 19:43:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.

Good idea! Replaced in few places. But not in ZipPath: it's actually implementation of underlying call from Files.copy: `jdk.nio.zipfs.ZipFileSystemProvider#copy`. So, `Files.copy` call will be recursive.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1853

From prr at openjdk.java.net  Sun Dec 20 20:36:56 2020
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 20 Dec 2020 20:36:56 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
 <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
Message-ID: <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>

On Sun, 20 Dec 2020 20:22:48 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> jrtfs is compiled twice, the second is to --release 8 so it can be packaged into jrt-fs.jar for use by IDEs/tools running on older JDK releases. So need to be careful with the changes here as it will likely causing build breakage.
>> 
>> We try to keep the changes to ASM to a minimum, might be better to leave this change out of the patch.
>> 
>> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.
>
>> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.
> 
> Good idea! Replaced in few places. But not in ZipPath: it's actually implementation of underlying call from Files.copy: `jdk.nio.zipfs.ZipFileSystemProvider#copy`. So, `Files.copy` call will be recursive.

So these changes are all over the place which means no one person knows how to test all of it.
Have you run the sound, swing tests, and the  printing tests on unix and windows ?
For printing for sure you'll need to do some manual testing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1853

From serb at openjdk.java.net  Sun Dec 20 22:50:55 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 20 Dec 2020 22:50:55 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
 <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
 <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>
Message-ID: <o_p9tWNfFIDxXClJaRduO_aWzk4zT3Uu2H74D1xKCjQ=.6cb9095d-1e58-4493-b750-5c38b4036b2d@github.com>

On Sun, 20 Dec 2020 20:33:43 GMT, Phil Race <prr at openjdk.org> wrote:

>>> One or two of the sources changes should probably uses Files.copy, e.g. ZipPath, sjavac/CopyFile.java.
>> 
>> Good idea! Replaced in few places. But not in ZipPath: it's actually implementation of underlying call from Files.copy: `jdk.nio.zipfs.ZipFileSystemProvider#copy`. So, `Files.copy` call will be recursive.
>
> So these changes are all over the place which means no one person knows how to test all of it.
> Have you run the sound, swing tests, and the  printing tests on unix and windows ?
> For printing for sure you'll need to do some manual testing.

I already suggested this, but anyway please always extract the changes to the java.desktop module to the separate PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec 21 07:52:10 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 21 Dec 2020 07:52:10 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v6]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <egekHLmTMOf1zvpBGHF6ho4g2MWS1mY0c_g4elVAGUs=.ba8b3b7f-7b6a-4f4a-95f1-bdc73c7b74db@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/ec602c1a..6f8ec711

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=04-05

  Stats: 135 lines in 13 files changed: 102 ins; 2 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec 21 07:58:59 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 21 Dec 2020 07:58:59 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <o_p9tWNfFIDxXClJaRduO_aWzk4zT3Uu2H74D1xKCjQ=.6cb9095d-1e58-4493-b750-5c38b4036b2d@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
 <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
 <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>
 <o_p9tWNfFIDxXClJaRduO_aWzk4zT3Uu2H74D1xKCjQ=.6cb9095d-1e58-4493-b750-5c38b4036b2d@github.com>
Message-ID: <r2-QsyunAq_hdTrYeewnQ-S2gD5xP-EApScn7JhFPc0=.9d8ffec4-84f5-4478-b2fb-8a25b4bfc176@github.com>

On Sun, 20 Dec 2020 22:48:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> So these changes are all over the place which means no one person knows how to test all of it.
>> Have you run the sound, swing tests, and the  printing tests on unix and windows ?
>> For printing for sure you'll need to do some manual testing.
>
> I already suggested this, but anyway please always extract the changes to the java.desktop module to the separate PR.

I've extracted changes in java.desktop into separate PR #1856
Reverted this changes from current PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec 21 08:19:08 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 21 Dec 2020 08:19:08 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v7]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <PncFUlxLFmz5-8oLVuhmy3aRoi6dM3FVbLLHhWWYdvA=.5693ccd6-7e39-4118-9d86-3d05a0597d31@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/6f8ec711..fceb20e3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=05-06

  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

PR: https://git.openjdk.java.net/jdk/pull/1853

From alanb at openjdk.java.net  Mon Dec 21 08:36:56 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 21 Dec 2020 08:36:56 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo
In-Reply-To: <r2-QsyunAq_hdTrYeewnQ-S2gD5xP-EApScn7JhFPc0=.9d8ffec4-84f5-4478-b2fb-8a25b4bfc176@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <kwDtUxxmfemL9wpSWkN-rGTrdX9ZcpU4r6AGQmBNShQ=.96de4bd6-cf8f-491b-b6dd-6689bdd70f1e@github.com>
 <e9BATv20rsi2ozsHSlkRxaY7SOB4kfP0-3x7vldMVNI=.73fbe606-1508-4f76-8351-50e81569ee56@github.com>
 <kCDDTR52ZEYEVfagEmig8DQJZOzGxCMpgmNTy3OBlws=.34b101de-c752-4a00-9edf-09d63e2ea4c1@github.com>
 <o_p9tWNfFIDxXClJaRduO_aWzk4zT3Uu2H74D1xKCjQ=.6cb9095d-1e58-4493-b750-5c38b4036b2d@github.com>
 <r2-QsyunAq_hdTrYeewnQ-S2gD5xP-EApScn7JhFPc0=.9d8ffec4-84f5-4478-b2fb-8a25b4bfc176@github.com>
Message-ID: <2PqLx13nZz23evPEzR9WEuwRg0PsfxgrHzly7VbuCrE=.3d1d0fd0-6b91-48b5-9dd1-ba6834cc6bbd@github.com>

On Mon, 21 Dec 2020 07:55:06 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> I already suggested this, but anyway please always extract the changes to the java.desktop module to the separate PR.
>
> I've extracted changes in java.desktop into separate PR #1856
> Reverted this changes from current PR.

Probably best to drop the changes to src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/** too as it gets refreshed periodically from the upstream Apache Santuario project.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1853

From alanb at openjdk.java.net  Mon Dec 21 08:59:59 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 21 Dec 2020 08:59:59 GMT
Subject: [jdk16] RFR: JDK-8258443: doclint should be service-loaded with
 system class loader
In-Reply-To: <Mvlw9FnB-ia4ub0bid0tgiYcCCevRZ-LJBZhwWRa1i8=.93855ab3-6d56-4269-919e-26858a851249@github.com>
References: <Mvlw9FnB-ia4ub0bid0tgiYcCCevRZ-LJBZhwWRa1i8=.93855ab3-6d56-4269-919e-26858a851249@github.com>
Message-ID: <YpOMFuDOqegtFpBBCovd-x76dYHhfjrcSYhwPv43mQQ=.ea10b809-32ca-4c58-9f7c-8031f9d7f3c9@github.com>

On Sat, 19 Dec 2020 01:08:36 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Trivial fix to use the system class loader when loading doclint for javac

Looks good, should allow JDK-8253996 to be closed too.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/54

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec 21 09:16:11 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 21 Dec 2020 09:16:11 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>

> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
  revert changes in Apache Santuario

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/fceb20e3..94e99817

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=06-07

  Stats: 42 lines in 3 files changed: 35 ins; 1 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

PR: https://git.openjdk.java.net/jdk/pull/1853

From jfranck at openjdk.java.net  Mon Dec 21 09:37:55 2020
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Mon, 21 Dec 2020 09:37:55 GMT
Subject: RFR: 8255729:
 com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient
In-Reply-To: <lPSFGsaxcZ_GipYihdGoOmSvnHPK7saOxBDsejkVFT8=.9f37d2a7-369d-44f0-a2a7-5afddcdc0960@github.com>
References: <lPSFGsaxcZ_GipYihdGoOmSvnHPK7saOxBDsejkVFT8=.9f37d2a7-369d-44f0-a2a7-5afddcdc0960@github.com>
Message-ID: <tMoprAu5uwBo45blKWeh95jUMwhQn38gxOQe_0mh8c4=.1bfbdfa3-a671-4285-bdab-847e97398a8c@github.com>

On Sun, 20 Dec 2020 17:29:59 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> `FilerOutputStream` extends `FilterOutputStream` without overwriting the method `write(byte b[], int off, int len)` which would suffer from the performance problem.
> This patch fixes it and adds some `@Override` to polish the code. But I can't find a good way to write a corresponding test case. Maybe it doesn't need a test case. And all existing tests in `test/langtools/tools/javac` passed locally.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

I'd like to see some kind of evidence that performance was actually improved. I realise this might be hard to make a good standalone test for, but it should be doable as an experiment observing how many times write(int) is called for a huge file.

src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacFiler.java line 282:

> 280:             if ((off | len | (b.length - (len + off)) | (off + len)) < 0)
> 281:                 throw new IndexOutOfBoundsException();
> 282:             out.write(b, off, len);

If I understand this `out` is the underlying `OutputStream` and calling `write(byte[], int, int)` performs the same one-byte-at-a-time write as without the override.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1854

From github.com+10835776+stsypanov at openjdk.java.net  Mon Dec 21 09:47:59 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 21 Dec 2020 09:47:59 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
Message-ID: <mO-oTZhUgrhkzY_mWGBYjao5z8M3pOPUlYaEqq5m30E=.4f228545-d235-45ec-b5fe-423b9649f8ed@github.com>

On Mon, 21 Dec 2020 09:16:11 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> 8080272  Refactor I/O stream copying to use java.io.InputStream.transferTo
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>   revert changes in Apache Santuario

I'm not a reviewer, but still think we could simplify `sun.security.tools.keytool.Main`

src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2459:

> 2457:                 byte[] bytes = in.readAllBytes();
> 2458:                 return CertificateFactory.getInstance("X509").generateCRLs(
> 2459:                         new ByteArrayInputStream(bytes));

Let's just pass `in` into `generateCRLs` instead of reading all bytes and rewrapping them into `InputStream` again?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+741251+turbanoff at openjdk.java.net  Mon Dec 21 09:53:57 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 21 Dec 2020 09:53:57 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <mO-oTZhUgrhkzY_mWGBYjao5z8M3pOPUlYaEqq5m30E=.4f228545-d235-45ec-b5fe-423b9649f8ed@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <mO-oTZhUgrhkzY_mWGBYjao5z8M3pOPUlYaEqq5m30E=.4f228545-d235-45ec-b5fe-423b9649f8ed@github.com>
Message-ID: <XfB_QACZhLUMnJ8FPDmzPh4EETBRXOepQiV0G4zzLgQ=.a50c4eaf-e931-4e74-8663-1653e12a53cb@github.com>

On Mon, 21 Dec 2020 09:40:39 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8080272: Refactor I/O stream copying to use java.io.InputStream.transferTo
>>   revert changes in Apache Santuario
>
> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2459:
> 
>> 2457:                 byte[] bytes = in.readAllBytes();
>> 2458:                 return CertificateFactory.getInstance("X509").generateCRLs(
>> 2459:                         new ByteArrayInputStream(bytes));
> 
> Let's just pass `in` into `generateCRLs` instead of reading all bytes and rewrapping them into `InputStream` again?

Looks like it was done intentionally by original author of the code.
Check comment above:

                // Read the full stream before feeding to X509Factory,
                // otherwise, keytool -gencrl | keytool -printcrl
                // might not work properly, since -gencrl is slow
                // and there's no data in the pipe at the beginning.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1853

From github.com+13688759+lgxbslgx at openjdk.java.net  Mon Dec 21 09:57:54 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Mon, 21 Dec 2020 09:57:54 GMT
Subject: RFR: 8255729:
 com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient
In-Reply-To: <tMoprAu5uwBo45blKWeh95jUMwhQn38gxOQe_0mh8c4=.1bfbdfa3-a671-4285-bdab-847e97398a8c@github.com>
References: <lPSFGsaxcZ_GipYihdGoOmSvnHPK7saOxBDsejkVFT8=.9f37d2a7-369d-44f0-a2a7-5afddcdc0960@github.com>
 <tMoprAu5uwBo45blKWeh95jUMwhQn38gxOQe_0mh8c4=.1bfbdfa3-a671-4285-bdab-847e97398a8c@github.com>
Message-ID: <xxaXD9eA6GA-IESOutTmoCLXU2BYY4yT5ha8B6mnTRs=.921709d3-5e2e-437b-be27-214debb1803a@github.com>

On Mon, 21 Dec 2020 09:29:46 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:

>> Hi all,
>> 
>> `FilerOutputStream` extends `FilterOutputStream` without overwriting the method `write(byte b[], int off, int len)` which would suffer from the performance problem.
>> This patch fixes it and adds some `@Override` to polish the code. But I can't find a good way to write a corresponding test case. Maybe it doesn't need a test case. And all existing tests in `test/langtools/tools/javac` passed locally.
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacFiler.java line 282:
> 
>> 280:             if ((off | len | (b.length - (len + off)) | (off + len)) < 0)
>> 281:                 throw new IndexOutOfBoundsException();
>> 282:             out.write(b, off, len);
> 
> If I understand this `out` is the underlying `OutputStream` and calling `write(byte[], int, int)` performs the same one-byte-at-a-time write as without the override.

In my opinion, the `out` depends on the `FileObject.openOutputStream` which differ depending on the implementation of `FileObject` and  can be set by users in the implementation of `FileObject`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1854

From github.com+10835776+stsypanov at openjdk.java.net  Mon Dec 21 10:06:01 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 21 Dec 2020 10:06:01 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 java.io.InputStream.transferTo [v8]
In-Reply-To: <XfB_QACZhLUMnJ8FPDmzPh4EETBRXOepQiV0G4zzLgQ=.a50c4eaf-e931-4e74-8663-1653e12a53cb@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <KcO_olP0uhrkPxSvala6b0MN3zsFy0_Skl06Oq6Gla0=.398341c8-a9c6-4186-ab43-df19bec9d544@github.com>
 <mO-oTZhUgrhkzY_mWGBYjao5z8M3pOPUlYaEqq5m30E=.4f228545-d235-45ec-b5fe-423b9649f8ed@github.com>
 <XfB_QACZhLUMnJ8FPDmzPh4EETBRXOepQiV0G4zzLgQ=.a50c4eaf-e931-4e74-8663-1653e12a53cb@github.com>
Message-ID: <m7_aUO_Qf7tKkUNuihCnh8Lh83xzYp3AOANwFucPBsE=.201f4482-bd10-4936-b58c-9148b3dd18d3@github.com>

On Mon, 21 Dec 2020 09:51:25 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 2459:
>> 
>>> 2457:                 byte[] bytes = in.readAllBytes();
>>> 2458:                 return CertificateFactory.getInstance("X509").generateCRLs(
>>> 2459:                         new ByteArrayInputStream(bytes));
>> 
>> Let's just pass `in` into `generateCRLs` instead of reading all bytes and rewrapping them into `InputStream` again?
>
> Looks like it was done intentionally by original author of the code.
> Check comment above:
> 
>                 // Read the full stream before feeding to X509Factory,
>                 // otherwise, keytool -gencrl | keytool -printcrl
>                 // might not work properly, since -gencrl is slow
>                 // and there's no data in the pipe at the beginning.

Let's keep it then

-------------

PR: https://git.openjdk.java.net/jdk/pull/1853

From sergei.tsypanov at yandex.ru  Mon Dec 21 10:10:27 2020
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Mon, 21 Dec 2020 12:10:27 +0200
Subject: @SuppressWarning doesn't suppress the warning for invoking method
Message-ID: <7442321608544714@mail.yandex.ru>

Hello,

I've created a PR https://github.com/openjdk/jdk/pull/1764 to solve JDK-8193031. Originally I haven't put @SuppressWarnings("varargs") over the method as the body only contains the invocation of Arrays.asList() which is already annotated with @SuppressWarnings("varargs").

The build however failed with error

src/java.base/share/classes/java/util/Collections.java:5590: warning: [varargs] Varargs method could cause heap pollution from non-reifiable varargs parameter elements
        return c.addAll(Arrays.asList(elements));
                                      ^
error: warnings found and -Werror specified
1 error

As it appears from the documentation of SaveVarargs:

> Compilers are encouraged to issue warnings when this annotation type is applied to a method or constructor declaration where:

> The body of the method or constructor declaration performs potentially unsafe operations, such as an assignment to an element of the variable arity parameter's array that generates an unchecked warning.

But as soon as Arrays.asList already suppresses the warning I expect the compilation be ok, but it fails. So my question is simple: is it a bug in compiler or not?

Regards,
Sergey Tsypanov

From jfranck at openjdk.java.net  Mon Dec 21 12:04:55 2020
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Mon, 21 Dec 2020 12:04:55 GMT
Subject: RFR: 8255729:
 com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient
In-Reply-To: <xxaXD9eA6GA-IESOutTmoCLXU2BYY4yT5ha8B6mnTRs=.921709d3-5e2e-437b-be27-214debb1803a@github.com>
References: <lPSFGsaxcZ_GipYihdGoOmSvnHPK7saOxBDsejkVFT8=.9f37d2a7-369d-44f0-a2a7-5afddcdc0960@github.com>
 <tMoprAu5uwBo45blKWeh95jUMwhQn38gxOQe_0mh8c4=.1bfbdfa3-a671-4285-bdab-847e97398a8c@github.com>
 <xxaXD9eA6GA-IESOutTmoCLXU2BYY4yT5ha8B6mnTRs=.921709d3-5e2e-437b-be27-214debb1803a@github.com>
Message-ID: <kPBP8BjiV1slU9WlWpCl39mZyArFiHwyTYtmwO4WhYM=.402972c5-1508-4ea3-b1e9-b68c6ba39883@github.com>

On Mon, 21 Dec 2020 09:55:04 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacFiler.java line 282:
>> 
>>> 280:             if ((off | len | (b.length - (len + off)) | (off + len)) < 0)
>>> 281:                 throw new IndexOutOfBoundsException();
>>> 282:             out.write(b, off, len);
>> 
>> If I understand this `out` is the underlying `OutputStream` and calling `write(byte[], int, int)` performs the same one-byte-at-a-time write as without the override.
>
> In my opinion, the `out` depends on the `FileObject.openOutputStream` which differ depending on the implementation of `FileObject` and  can be set by users in the implementation of `FileObject`.

Ok, got it. So today, in case the stream has an efficient write of an array range it currently isn't called, but a 1-byte-at-a-time write inherited is called instead. This patch delegates to the out method (efficient or not) instead of choosing the inherited method (always inefficient).

I think you can use `Objects::checkFromIndexSize` instead for the index check.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1854

From jonathan.gibbons at oracle.com  Mon Dec 21 15:23:30 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 21 Dec 2020 07:23:30 -0800
Subject: RFR: 8255729:
 com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient
In-Reply-To: <kPBP8BjiV1slU9WlWpCl39mZyArFiHwyTYtmwO4WhYM=.402972c5-1508-4ea3-b1e9-b68c6ba39883@github.com>
References: <lPSFGsaxcZ_GipYihdGoOmSvnHPK7saOxBDsejkVFT8=.9f37d2a7-369d-44f0-a2a7-5afddcdc0960@github.com>
 <tMoprAu5uwBo45blKWeh95jUMwhQn38gxOQe_0mh8c4=.1bfbdfa3-a671-4285-bdab-847e97398a8c@github.com>
 <xxaXD9eA6GA-IESOutTmoCLXU2BYY4yT5ha8B6mnTRs=.921709d3-5e2e-437b-be27-214debb1803a@github.com>
 <kPBP8BjiV1slU9WlWpCl39mZyArFiHwyTYtmwO4WhYM=.402972c5-1508-4ea3-b1e9-b68c6ba39883@github.com>
Message-ID: <29e447c0-39a9-f862-c5cc-d0df03ef97ff@oracle.com>


On 12/21/20 4:04 AM, Joel Borggr?n-Franck wrote:
> I think you can use `Objects::checkFromIndexSize` instead for the index check.

Good catch.

-- Jon


From jjg at openjdk.java.net  Mon Dec 21 17:08:57 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 21 Dec 2020 17:08:57 GMT
Subject: [jdk16] RFR: JDK-8258443: doclint should be service-loaded with
 system class loader
In-Reply-To: <YpOMFuDOqegtFpBBCovd-x76dYHhfjrcSYhwPv43mQQ=.ea10b809-32ca-4c58-9f7c-8031f9d7f3c9@github.com>
References: <Mvlw9FnB-ia4ub0bid0tgiYcCCevRZ-LJBZhwWRa1i8=.93855ab3-6d56-4269-919e-26858a851249@github.com>
 <YpOMFuDOqegtFpBBCovd-x76dYHhfjrcSYhwPv43mQQ=.ea10b809-32ca-4c58-9f7c-8031f9d7f3c9@github.com>
Message-ID: <uq-6YkUWcC8QpN2yRlBzKVy6Tq5Zmt_IlFcMD-zMfOE=.33166525-579b-4ee0-a95b-0f4742778f92@github.com>

On Mon, 21 Dec 2020 08:57:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Trivial fix to use the system class loader when loading doclint for javac
>
> Looks good, should allow JDK-8253996 to be closed too.

@AlanBateman JDK-8253996 is slightly different; my intent is that javac/doclint should give a more friendly message when doclint is _really_ not available, such as in a minimal jlink-ed image.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/54

From jjg at openjdk.java.net  Mon Dec 21 17:08:58 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 21 Dec 2020 17:08:58 GMT
Subject: [jdk16] Integrated: JDK-8258443: doclint should be service-loaded
 with system class loader
In-Reply-To: <Mvlw9FnB-ia4ub0bid0tgiYcCCevRZ-LJBZhwWRa1i8=.93855ab3-6d56-4269-919e-26858a851249@github.com>
References: <Mvlw9FnB-ia4ub0bid0tgiYcCCevRZ-LJBZhwWRa1i8=.93855ab3-6d56-4269-919e-26858a851249@github.com>
Message-ID: <9z1UNb6M-kx5yQvlPcIehuvWPvNsk5BwAuLUDV578Y4=.c8dd3b11-aafc-48cc-ad8b-4defc3041580@github.com>

On Sat, 19 Dec 2020 01:08:36 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Trivial fix to use the system class loader when loading doclint for javac

This pull request has now been integrated.

Changeset: 8da7c580
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/8da7c580
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8258443: doclint should be service-loaded with system class loader

Reviewed-by: alanb

-------------

PR: https://git.openjdk.java.net/jdk16/pull/54

From github.com+13688759+lgxbslgx at openjdk.java.net  Mon Dec 21 17:14:12 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Mon, 21 Dec 2020 17:14:12 GMT
Subject: RFR: 8255729:
 com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient
 [v2]
In-Reply-To: <lPSFGsaxcZ_GipYihdGoOmSvnHPK7saOxBDsejkVFT8=.9f37d2a7-369d-44f0-a2a7-5afddcdc0960@github.com>
References: <lPSFGsaxcZ_GipYihdGoOmSvnHPK7saOxBDsejkVFT8=.9f37d2a7-369d-44f0-a2a7-5afddcdc0960@github.com>
Message-ID: <XKVdqa-eVZmj6vbvx6yH11nfCp8GCx0ae_OX1Wa1_cA=.302d5e22-02d1-4948-95c2-af72cf14a6f0@github.com>

> Hi all,
> 
> `FilerOutputStream` extends `FilterOutputStream` without overwriting the method `write(byte b[], int off, int len)` which would suffer from the performance problem.
> This patch fixes it and adds some `@Override` to polish the code. But I can't find a good way to write a corresponding test case. Maybe it doesn't need a test case. And all existing tests in `test/langtools/tools/javac` passed locally.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Use Objects::checkFromIndexSize

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1854/files
  - new: https://git.openjdk.java.net/jdk/pull/1854/files/02a3fd1e..ed1d7320

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1854&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1854&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1854.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1854/head:pull/1854

PR: https://git.openjdk.java.net/jdk/pull/1854

From jjg at openjdk.java.net  Mon Dec 21 17:15:57 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 21 Dec 2020 17:15:57 GMT
Subject: RFR: 8066694: Strange code in JavacParser.java
In-Reply-To: <sJOs1F9eRA5wwzx488HkuQcEVdaqlRctC4aH5Eninrk=.6705cef5-c630-441f-8f46-8fd2acb0403f@github.com>
References: <sJOs1F9eRA5wwzx488HkuQcEVdaqlRctC4aH5Eninrk=.6705cef5-c630-441f-8f46-8fd2acb0403f@github.com>
Message-ID: <g3Uwoxv7sOb0iVouOTL3w4RikbMR9ht0SQU9UXfPGO0=.65b25d9d-d1c7-4211-9b29-dde5da14682c@github.com>

On Sun, 20 Dec 2020 13:13:43 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> This code was introduced in main repository under https://bugs.openjdk.java.net/browse/JDK-8006775
> I checked original commit in `type-annotations/langtools` repository: https://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/71f35e4b93a5
> Looks like it's not a merge problem.

I suspect this was originally a merge issue, in the work leading up to the integration of the JSR308 work.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 2397:

> 2395:                     elemtype = bracketsOptCont(elemtype, pos, maybeDimAnnos);
> 2396:                 } else {
> 2397:                     if (token.kind == RBRACKET) { // no dimension

I suggest keeping the comment, by moving it to line 2394

-------------

Changes requested by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1852

From github.com+13688759+lgxbslgx at openjdk.java.net  Mon Dec 21 17:52:57 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Mon, 21 Dec 2020 17:52:57 GMT
Subject: Integrated: 8231622: SuppressWarning("serial") ignored on field
 serialVersionUID
In-Reply-To: <_2Z8RhLQo1F6ddk2cZS5J_hoRMPLCe5ssVMeyyscFnc=.d267dddd-12d6-4968-a32d-6bd3510daf45@github.com>
References: <_2Z8RhLQo1F6ddk2cZS5J_hoRMPLCe5ssVMeyyscFnc=.d267dddd-12d6-4968-a32d-6bd3510daf45@github.com>
Message-ID: <mh3x9pu9mZp8um6KDTWnufyxMFWZzyd5spMUwt6PTaw=.464c06bc-bbce-476f-bf9f-4104f63debee@github.com>

On Fri, 4 Dec 2020 16:21:28 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> Currently, a warning is generated when compiling the following code by using the option `-Xlint`.
> 
> import java.io.Serializable;
> class B implements Serializable {
>     @SuppressWarnings("serial")
>     private static final byte serialVersionUID = 5;
> }
> 
> output:
> B.java:4: warning: [serial] serialVersionUID must be of type long in class B
>     private static final byte serialVersionUID = 5;
>                               ^
> 1 warning
> 
> The annotation `@SuppressWarnings("serial")` on  field serialVersionUID is ignored by the compiler.
> This patch fixes it and adds some tests.
> Thank you for taking the time to review.
> 
> Best Regards.

This pull request has now been integrated.

Changeset: 01d51a10
Author:    Guoxiong Li <lgxbslgx at gmail.com>
Committer: Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/01d51a10
Stats:     126 lines in 2 files changed: 124 ins; 0 del; 2 mod

8231622: SuppressWarning("serial") ignored on field serialVersionUID

Reviewed-by: jjg

-------------

PR: https://git.openjdk.java.net/jdk/pull/1626

From bsrbnd at gmail.com  Tue Dec 22 00:56:23 2020
From: bsrbnd at gmail.com (B. Blaser)
Date: Tue, 22 Dec 2020 01:56:23 +0100
Subject: [Ask for sponsoring] Fix another NPE in
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:571)
In-Reply-To: <CAM1U-w_DyumchOqfy5Hn4FwWtW-e7p=o399neaHXcS_ZAL9H4Q@mail.gmail.com>
References: <CAM1U-w_DyumchOqfy5Hn4FwWtW-e7p=o399neaHXcS_ZAL9H4Q@mail.gmail.com>
Message-ID: <CAEgw74DWC5zK5vsKnm-ajWChachDZ2xNc4Yv7en3mWOMUFX79w@mail.gmail.com>

Hi,

On Sun, 20 Dec 2020 at 10:49, JiaYanwei <jiaywe at gmail.com> wrote:
>
> Hi all,
>
> I had found & fixed a javac issue like https://bugs.openjdk.java.net/browse/JDK-8229862 , and created a PR on Github: https://github.com/openjdk/jdk/pull/1479 .
>
> I have no account to create JIRA issue, and I'm not sure whether the code style as well as the solution itself are appropriate. Could anyone sponsor me? Thanks a lot.
>
> Best Regards.

The problem seems to be that 'lambdaTranslationMap' links the
untranslated local variable to its capture. So, what do you think of
the following solution to keep the translated local variable's mapping
with the original symbol (both examples and langtools:tier1 are OK on
jdk14u)?

Thanks,
Bernard

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
@@ -2057,7 +2057,13 @@
                         };
                         break;
                     case LOCAL_VAR:
-                        ret = new VarSymbol(sym.flags() & FINAL,
sym.name, sym.type, translatedSym);
+                        ret = new VarSymbol(sym.flags() & FINAL,
sym.name, sym.type, translatedSym) {
+                            @Override
+                            public Symbol baseSymbol() {
+                                //keep mapping with original symbol
+                                return sym;
+                            }
+                        };
                         ((VarSymbol) ret).pos = ((VarSymbol) sym).pos;
                         break;
                     case PARAM:
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
@@ -1221,7 +1221,7 @@
                 //sym is a local variable - check the lambda translation map to
                 //see if sym has been translated to something else in
the current
                 //scope (by LambdaToMethod)
-                Symbol translatedSym = lambdaTranslationMap.get(sym);
+                Symbol translatedSym =
lambdaTranslationMap.get(sym.baseSymbol());
                 if (translatedSym != null) {
                     tree = make.at(tree.pos).Ident(translatedSym);
                 }

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Dec 22 05:40:56 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 22 Dec 2020 05:40:56 GMT
Subject: RFR: 8255729:
 com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient
 [v2]
In-Reply-To: <tMoprAu5uwBo45blKWeh95jUMwhQn38gxOQe_0mh8c4=.1bfbdfa3-a671-4285-bdab-847e97398a8c@github.com>
References: <lPSFGsaxcZ_GipYihdGoOmSvnHPK7saOxBDsejkVFT8=.9f37d2a7-369d-44f0-a2a7-5afddcdc0960@github.com>
 <tMoprAu5uwBo45blKWeh95jUMwhQn38gxOQe_0mh8c4=.1bfbdfa3-a671-4285-bdab-847e97398a8c@github.com>
Message-ID: <KR2wCGY-3nEGJWDPU1xuv1VNMPISRfIdVzOcl6EwQVo=.5cb3dedb-6889-4535-abb2-eaf133e7b66d@github.com>

On Mon, 21 Dec 2020 09:34:59 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use Objects::checkFromIndexSize
>
> I'd like to see some kind of evidence that performance was actually improved. I realise this might be hard to make a good standalone test for, but it should be doable as an experiment observing how many times write(int) is called for a huge file.

I revised the code by using `Objects::checkFromIndexSize`. I don't revise the code in `FilterOutputStream` because it is the content of package `java.base/java.io`. If you thought the `FilterOutputStream::write(byte b[], int off, int len)` is needed to be modified, I will revise it, too.

Thank you for taking the time to review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1854

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Dec 22 15:30:09 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 22 Dec 2020 15:30:09 GMT
Subject: RFR: 8225003: NPE in Attr.attribIdentAsEnumType
Message-ID: <PHN_VIHKRaTUTixtxee-2V0k__M7bC5ssjqUNupGPps=.b638e98b-1da4-4490-b033-d8874feed79a@github.com>

Hi all,

`Attr.attribIdentAsEnumType` uses `enclClass` which would return null if some error types and/or error symbols exist.

And if we use annotation processor, some errors would be reported to `deferredDiagnosticHandler` and not immediately reported to the users. At this time, the `NullPointerException`(NPE) occurs and all the other work, including that the `deferredDiagnosticHandler` report the errors to users, would not be done. So the user would see the NPE and see that the compiler crashes.

In other words, the NPE also occurs without the annotation processor. But because the `deferredDiagnosticHandler` is not set without the annotation processor, some other errors would be shown immediately to users and the NPE is not shown when using [these catch code](https://github.com/openjdk/jdk/blob/0849117d5c3a9ae12231262fc0d3366a6e8a458d/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Main.java#L349).

This patch fixes the NPE and reports the deferred diagnostics to users at the end of the compilation task. Maybe you can consider that this patch solves two bugs:

1. [JDK-8225003 NPE in Attr.attribIdentAsEnumType](https://bugs.openjdk.java.net/browse/JDK-8225003)
2. Some deferred diagnostics would be not reported to user when the compiler crashes.

The test case needs to fix these two bugs to pass, so I put them together.

Thank you for taking the time to review.

Best Regards.

-------------

Commit messages:
 - 8225003: NPE in Attr.attribIdentAsEnumType

Changes: https://git.openjdk.java.net/jdk/pull/1864/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1864&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8225003
  Stats: 111 lines in 3 files changed: 107 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1864.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1864/head:pull/1864

PR: https://git.openjdk.java.net/jdk/pull/1864

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Dec 22 16:23:14 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 22 Dec 2020 16:23:14 GMT
Subject: RFR: 8258662: JDK 17ea: Crash compiling instanceof check
 involving sealed interface [v2]
In-Reply-To: <NLtC9dIs-LiSiV5DFhmE7PcGsm2xhvG-n63_UnlELbw=.c2702d23-38ee-428f-9136-d0de5bbaf9f0@github.com>
References: <NLtC9dIs-LiSiV5DFhmE7PcGsm2xhvG-n63_UnlELbw=.c2702d23-38ee-428f-9136-d0de5bbaf9f0@github.com>
Message-ID: <1Bb94dovIOuWJQVYey6J9eYRHfcJKcd4SRBBtY2LMQw=.99fcf2d4-9675-4345-a121-7cf3c932d81a@github.com>

> Hi all,
> 
> The method `Types.isCastable` uses method `Types.areDisjoint` to do some check. But `Types.isCastable` doesn't check the type of the parameter before invoking method `Types.areDisjoint`. This patch adds the corresponding check and add a test case.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Use methods instead of instanceof

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1849/files
  - new: https://git.openjdk.java.net/jdk/pull/1849/files/41e94f2c..3b77d032

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1849&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1849&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1849.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1849/head:pull/1849

PR: https://git.openjdk.java.net/jdk/pull/1849

From github.com+741251+turbanoff at openjdk.java.net  Tue Dec 22 18:52:13 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 22 Dec 2020 18:52:13 GMT
Subject: RFR: 8066694: Strange code in JavacParser.java [v2]
In-Reply-To: <sJOs1F9eRA5wwzx488HkuQcEVdaqlRctC4aH5Eninrk=.6705cef5-c630-441f-8f46-8fd2acb0403f@github.com>
References: <sJOs1F9eRA5wwzx488HkuQcEVdaqlRctC4aH5Eninrk=.6705cef5-c630-441f-8f46-8fd2acb0403f@github.com>
Message-ID: <afCGrxqM1uVXb9yrj75SJhYTxjoxgIrgu8bLMQmcy-s=.d72baec7-80e5-4d38-b12f-dfda90083029@github.com>

> This code was introduced in main repository under https://bugs.openjdk.java.net/browse/JDK-8006775
> I checked original commit in `type-annotations/langtools` repository: https://hg.openjdk.java.net/type-annotations/type-annotations/langtools/rev/71f35e4b93a5
> Looks like it's not a merge problem.

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8066694: Strange code in JavacParser.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1852/files
  - new: https://git.openjdk.java.net/jdk/pull/1852/files/a76a30c1..e903d437

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1852&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1852&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1852.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1852/head:pull/1852

PR: https://git.openjdk.java.net/jdk/pull/1852

From github.com+741251+turbanoff at openjdk.java.net  Tue Dec 22 18:52:14 2020
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 22 Dec 2020 18:52:14 GMT
Subject: RFR: 8066694: Strange code in JavacParser.java [v2]
In-Reply-To: <g3Uwoxv7sOb0iVouOTL3w4RikbMR9ht0SQU9UXfPGO0=.65b25d9d-d1c7-4211-9b29-dde5da14682c@github.com>
References: <sJOs1F9eRA5wwzx488HkuQcEVdaqlRctC4aH5Eninrk=.6705cef5-c630-441f-8f46-8fd2acb0403f@github.com>
 <g3Uwoxv7sOb0iVouOTL3w4RikbMR9ht0SQU9UXfPGO0=.65b25d9d-d1c7-4211-9b29-dde5da14682c@github.com>
Message-ID: <oNXyTOhk_7eHK0PqsTUyhvNoVabHVrVOXYNYrJHuGls=.4bb0f55d-89b6-4d54-ad3c-9f68546b4b75@github.com>

On Mon, 21 Dec 2020 17:13:05 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> I suspect this was originally a merge issue, in the work leading up to the integration of the JSR308 work.

Do you know is history of original changes available somewhere?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1852

From jwilhelm at openjdk.java.net  Tue Dec 22 20:51:15 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 22 Dec 2020 20:51:15 GMT
Subject: RFR: Merge jdk16
Message-ID: <XRu1N9J7tPt3MhgjrOU3JdF0uE0eTZ9g6jvhY_EaO7I=.bbdca574-58a7-4251-bf49-08e2606d6798@github.com>

Forwardport JDK 16 -> JDK 17

-------------

Commit messages:
 - Merge
 - 8258832: ProblemList com/sun/jdi/AfterThreadDeathTest.java on Linux-X64
 - 8258827: ProblemList Naming/DefaultRegistryPort.java and Naming/legalRegistryNames/LegalRegistryNames.java on Windows
 - 8258802: ProblemList TestJstatdDefaults.java, TestJstatdRmiPort.java, and TestJstatdServer.java
 - 8258790: C2: Crash on empty macro node list
 - 8258443: doclint should be service-loaded with system class loader
 - 8255763: C2: OSR miscompilation caused by invalid memory instruction placement
 - 8258714: Shenandoah: Process references before evacuation during degen

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.java.net/?repo=jdk&pr=1870&range=00.0
 - jdk16: https://webrevs.openjdk.java.net/?repo=jdk&pr=1870&range=00.1

Changes: https://git.openjdk.java.net/jdk/pull/1870/files
  Stats: 203 lines in 12 files changed: 181 ins; 13 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1870.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1870/head:pull/1870

PR: https://git.openjdk.java.net/jdk/pull/1870

From jonathan.gibbons at oracle.com  Tue Dec 22 21:10:05 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 22 Dec 2020 13:10:05 -0800
Subject: RFR: 8066694: Strange code in JavacParser.java [v2]
In-Reply-To: <oNXyTOhk_7eHK0PqsTUyhvNoVabHVrVOXYNYrJHuGls=.4bb0f55d-89b6-4d54-ad3c-9f68546b4b75@github.com>
References: <sJOs1F9eRA5wwzx488HkuQcEVdaqlRctC4aH5Eninrk=.6705cef5-c630-441f-8f46-8fd2acb0403f@github.com>
 <g3Uwoxv7sOb0iVouOTL3w4RikbMR9ht0SQU9UXfPGO0=.65b25d9d-d1c7-4211-9b29-dde5da14682c@github.com>
 <oNXyTOhk_7eHK0PqsTUyhvNoVabHVrVOXYNYrJHuGls=.4bb0f55d-89b6-4d54-ad3c-9f68546b4b75@github.com>
Message-ID: <5d877ea1-d96f-630d-40de-0c2e65172361@oracle.com>


On 12/22/20 10:52 AM, Andrey Turbanov wrote:
> On Mon, 21 Dec 2020 17:13:05 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:
>
>> I suspect this was originally a merge issue, in the work leading up to the integration of the JSR308 work.
> Do you know is history of original changes available somewhere?
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/1852


It may be available somewhere, but I don't see a need to go there. The 
fix looks simple enough on the merits.

-- Jon


From jwilhelm at openjdk.java.net  Tue Dec 22 21:19:59 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 22 Dec 2020 21:19:59 GMT
Subject: Integrated: Merge jdk16
In-Reply-To: <XRu1N9J7tPt3MhgjrOU3JdF0uE0eTZ9g6jvhY_EaO7I=.bbdca574-58a7-4251-bf49-08e2606d6798@github.com>
References: <XRu1N9J7tPt3MhgjrOU3JdF0uE0eTZ9g6jvhY_EaO7I=.bbdca574-58a7-4251-bf49-08e2606d6798@github.com>
Message-ID: <QSju_jtRwOvAVt9uAlcNO9RwjIh_K9rXyZFuJ6YkgEY=.28295f59-1061-4947-8ca0-ca050e136daa@github.com>

On Tue, 22 Dec 2020 20:45:38 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: f2bad3a0
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f2bad3a0
Stats:     203 lines in 12 files changed: 181 ins; 13 del; 9 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/1870

From jjg at openjdk.java.net  Wed Dec 23 00:06:13 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 23 Dec 2020 00:06:13 GMT
Subject: [jdk16] RFR: JDK-8253996: Javac error on jdk16 build 18: invalid
 flag: -Xdoclint:-missing
Message-ID: <1BH8xqCUnkEyAVYD50BvewKIb_AxutBS8k0TEkK7tXM=.7e865ca1-cd5c-4b29-b8e1-a3e2dedee93f@github.com>

This PR improves the diagnostic when javac is run in an image that does not provide a service provider for DocLint.

Instead of reporting messages about unsupported options, the following warning will be generated:

`
Warning: No service provider for doclint is available
`

In addition, as a minor cleanup, in the `jdk.javadoc` module, javadoc b bypasses the service loader to access `doclint` directly.

-------------

Commit messages:
 - JDK-8253996: Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing

Changes: https://git.openjdk.java.net/jdk16/pull/60/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=60&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253996
  Stats: 96 lines in 6 files changed: 88 ins; 1 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/60.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/60/head:pull/60

PR: https://git.openjdk.java.net/jdk16/pull/60

From jjg at openjdk.java.net  Wed Dec 23 01:35:07 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 23 Dec 2020 01:35:07 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v4]
In-Reply-To: <vZkUHKS22sXksvEkZIlwencSsNSc0HTcCR-5Mp71daQ=.06eeb39b-39c4-4854-861d-432a4b95e946@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <vZkUHKS22sXksvEkZIlwencSsNSc0HTcCR-5Mp71daQ=.06eeb39b-39c4-4854-861d-432a4b95e946@github.com>
Message-ID: <XKTvz2-x2vrvW523LJlGWOkDOqJP27e2n5OiqmmVjZY=.abce90e3-4e29-4a89-aa99-1f74a8bf95ea@github.com>

On Fri, 18 Dec 2020 01:34:15 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> HTML4 is no longer supported in javadoc.
>> 
>> doclint needs to drop HTML4 support as well.
>> The changes consist of:
>> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
>> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
>> * Modifying test code and expected outputs to be checked in HTML5
>
> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   5th: 8257204 and 8256313
>   8257204: Remove usage of -Xhtmlversion option from javac
>   8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option

src/jdk.compiler/share/man/javac.1 line 638:

> 636: .RS
> 637: .RE
> 638: .TP

In general, you should not edit files like this; these files are generated from upstream Markdown files.

-------------

PR: https://git.openjdk.java.net/jdk/pull/893

From jjg at openjdk.java.net  Wed Dec 23 01:35:05 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 23 Dec 2020 01:35:05 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
Message-ID: <g106P5efLYq8H9ekh04enafDvGW0IRB4Z4NyFN6j_8E=.9399c3bb-bb9e-46a5-83f2-a5e7c68dcddf@github.com>

On Fri, 18 Dec 2020 02:34:16 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> HTML4 is no longer supported in javadoc.
>> 
>> doclint needs to drop HTML4 support as well.
>> The changes consist of:
>> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
>> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
>> * Modifying test code and expected outputs to be checked in HTML5
>
> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   5th: 8258460: Remove --doclint-format option from javac

Looks good.
I'll pull down a copy, for review in an IDE and to build and run tests, and if that goes OK, I will approve it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/893

From ysatowse at openjdk.java.net  Wed Dec 23 02:25:01 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Wed, 23 Dec 2020 02:25:01 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <g106P5efLYq8H9ekh04enafDvGW0IRB4Z4NyFN6j_8E=.9399c3bb-bb9e-46a5-83f2-a5e7c68dcddf@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
 <g106P5efLYq8H9ekh04enafDvGW0IRB4Z4NyFN6j_8E=.9399c3bb-bb9e-46a5-83f2-a5e7c68dcddf@github.com>
Message-ID: <6eJV9qXpBqWxbpH2x-RbDWpL9uOTjsCjIu5jhbQ-wSI=.c14cb5c3-266c-423f-924a-6159aa9dd502@github.com>

On Wed, 23 Dec 2020 01:32:29 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   5th: 8258460: Remove --doclint-format option from javac
>
> Looks good.
> I'll pull down a copy, for review in an IDE and to build and run tests, and if that goes OK, I will approve it.

test comment

-------------

PR: https://git.openjdk.java.net/jdk/pull/893

From vicente.romero at oracle.com  Wed Dec 23 03:28:48 2020
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 22 Dec 2020 22:28:48 -0500
Subject: Records, Intersection type and lambda
In-Reply-To: <CAEgw74Azjxk34K0Mo5b9-UxDCBDT6tE1M0K9sZ837aSi28LdxA@mail.gmail.com>
References: <1634118475.2157445.1605459778491.JavaMail.zimbra@u-pem.fr>
 <CAEgw74At3W0manZ4yQsUewZz8iYJ5D136MXLw_nfR6OzjjYUcA@mail.gmail.com>
 <1485898290.1122166.1605599180102.JavaMail.zimbra@u-pem.fr>
 <CAEgw74DK6=Hvehk+GxVL8TcKeMFxUsHevSU0ATzTJQzGB-AoaA@mail.gmail.com>
 <ce41110b-757d-b1f0-7358-a3a716ef52a4@oracle.com>
 <CAEgw74Azjxk34K0Mo5b9-UxDCBDT6tE1M0K9sZ837aSi28LdxA@mail.gmail.com>
Message-ID: <df32ce1d-af2f-0a20-c3af-f56c17c2d203@oracle.com>

Hi Bernard,

On 12/19/20 7:37 AM, B. Blaser wrote:
> Thanks Vicente.
>
> I guess I see the idea with the line you added to my original patch.
> However, I still believe it's not necessary for the purpose of this
> fix targeted to 16.
> So, I'd suggest to file a separate issue for that (to 17?) as it might
> have some side effects.
what side effects do you see?
>
> What do you think?
IMO, I think that the patch wouldn't be complete without that line

> Bernard

Vicente

>
> On Thu, 17 Dec 2020 at 21:14, Vicente Romero <vicente.romero at oracle.com> wrote:
>> Hi,
>>
>> There was a review that got closed bc nobody reviewed it. I will prepare
>> another PR targeting 16,
>>
>> Vicente
>>
>> On 11/18/20 10:21 AM, B. Blaser wrote:
>>> On Tue, 17 Nov 2020 at 08:46, <forax at univ-mlv.fr> wrote:
>>>> yes, thanks !
>>>> still not fixed :(
>>> Probably not a frequent issue with usual classes but I believe this
>>> might be a rather common use case with records, so I verified that my
>>> initial fix is still working fine with your latest example.
>>> However, Vicente seems to be investigating something else in the same
>>> area but I'd suggest to eventually file a separate issue for that in
>>> order to go ahead with my proposal, what do you think?
>>>
>>> Thanks,
>>> Bernard


From vromero at openjdk.java.net  Wed Dec 23 04:39:55 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 23 Dec 2020 04:39:55 GMT
Subject: RFR: 8258662: JDK 17ea: Crash compiling instanceof check
 involving sealed interface [v2]
In-Reply-To: <1Bb94dovIOuWJQVYey6J9eYRHfcJKcd4SRBBtY2LMQw=.99fcf2d4-9675-4345-a121-7cf3c932d81a@github.com>
References: <NLtC9dIs-LiSiV5DFhmE7PcGsm2xhvG-n63_UnlELbw=.c2702d23-38ee-428f-9136-d0de5bbaf9f0@github.com>
 <1Bb94dovIOuWJQVYey6J9eYRHfcJKcd4SRBBtY2LMQw=.99fcf2d4-9675-4345-a121-7cf3c932d81a@github.com>
Message-ID: <yKCyBjdADoFcainenSXFH7oFDQV7MiQNfGncV0Aw8ZM=.b358d42f-7db9-45dd-a5a4-61f02b55c307@github.com>

On Tue, 22 Dec 2020 16:23:14 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi all,
>> 
>> The method `Types.isCastable` uses method `Types.areDisjoint` to do some check. But `Types.isCastable` doesn't check the type of the parameter before invoking method `Types.areDisjoint`. This patch adds the corresponding check and add a test case.
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use methods instead of instanceof

the fix looks good to me but we need this code in JDK 16, please create another PR targeting JDK 16 and close this one. Thanks for the fix!

-------------

PR: https://git.openjdk.java.net/jdk/pull/1849

From github.com+13688759+lgxbslgx at openjdk.java.net  Wed Dec 23 04:41:06 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Wed, 23 Dec 2020 04:41:06 GMT
Subject: RFR: 8230623: Extract command-line help for -Xlint sub-options to
 new --help-lint [v2]
In-Reply-To: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
References: <oNYS2Vd8Hw5fnqj-xE_iA2R5Xi2J6hY2tRTX4NORQOc=.13d42a68-6a48-4879-87df-60c89ae3dc50@github.com>
Message-ID: <lihZhiILl0jhuiIj7USLwsx6n114-BAg1cLYtNfIxJ8=.e1651dbd-b915-4533-9ac6-0594cb8ca527@github.com>

> Hi all,
> 
> This patch splits out the concrete keys of -Xlint into a new option, --help-lint, 
> so that the output of --help-extra is kept clean and concise.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Remove the content in documentation javac.1

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1758/files
  - new: https://git.openjdk.java.net/jdk/pull/1758/files/b844e8c4..b73d62e6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1758&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1758&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1758.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1758/head:pull/1758

PR: https://git.openjdk.java.net/jdk/pull/1758

From jiaywe at gmail.com  Wed Dec 23 04:49:06 2020
From: jiaywe at gmail.com (JiaYanwei)
Date: Wed, 23 Dec 2020 12:49:06 +0800
Subject: [Ask for sponsoring] Fix another NPE in
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:571)
In-Reply-To: <CAEgw74DWC5zK5vsKnm-ajWChachDZ2xNc4Yv7en3mWOMUFX79w@mail.gmail.com>
References: <CAM1U-w_DyumchOqfy5Hn4FwWtW-e7p=o399neaHXcS_ZAL9H4Q@mail.gmail.com>
 <CAEgw74DWC5zK5vsKnm-ajWChachDZ2xNc4Yv7en3mWOMUFX79w@mail.gmail.com>
Message-ID: <CAM1U-w99wL6JLhLSMs9ymY4PYX4cNx+rW-zhjFgjbNv0BiREPA@mail.gmail.com>

Great! I think it's the best solution and can also be directly backported
to 16, 11 & 8.

Should I close (i.e. stop/cancel) the Github PR, or may I commit this code
with you(B. Blaser) as the author - just like what Jan Lahoda did in Github
PR 1221?


B. Blaser <bsrbnd at gmail.com> ?2020?12?22??? ??8:56???

> Hi,
>
> On Sun, 20 Dec 2020 at 10:49, JiaYanwei <jiaywe at gmail.com> wrote:
> >
> > Hi all,
> >
> > I had found & fixed a javac issue like
> https://bugs.openjdk.java.net/browse/JDK-8229862 , and created a PR on
> Github: https://github.com/openjdk/jdk/pull/1479 .
> >
> > I have no account to create JIRA issue, and I'm not sure whether the
> code style as well as the solution itself are appropriate. Could anyone
> sponsor me? Thanks a lot.
> >
> > Best Regards.
>
> The problem seems to be that 'lambdaTranslationMap' links the
> untranslated local variable to its capture. So, what do you think of
> the following solution to keep the translated local variable's mapping
> with the original symbol (both examples and langtools:tier1 are OK on
> jdk14u)?
>
> Thanks,
> Bernard
>
> diff --git
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
>
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
> ---
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
> +++
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
> @@ -2057,7 +2057,13 @@
>                          };
>                          break;
>                      case LOCAL_VAR:
> -                        ret = new VarSymbol(sym.flags() & FINAL,
> sym.name, sym.type, translatedSym);
> +                        ret = new VarSymbol(sym.flags() & FINAL,
> sym.name, sym.type, translatedSym) {
> +                            @Override
> +                            public Symbol baseSymbol() {
> +                                //keep mapping with original symbol
> +                                return sym;
> +                            }
> +                        };
>                          ((VarSymbol) ret).pos = ((VarSymbol) sym).pos;
>                          break;
>                      case PARAM:
> diff --git
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
> @@ -1221,7 +1221,7 @@
>                  //sym is a local variable - check the lambda translation
> map to
>                  //see if sym has been translated to something else in
> the current
>                  //scope (by LambdaToMethod)
> -                Symbol translatedSym = lambdaTranslationMap.get(sym);
> +                Symbol translatedSym =
> lambdaTranslationMap.get(sym.baseSymbol());
>                  if (translatedSym != null) {
>                      tree = make.at(tree.pos).Ident(translatedSym);
>                  }
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20201223/ebd984a2/attachment.htm>

From ysatowse at openjdk.java.net  Wed Dec 23 05:05:05 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Wed, 23 Dec 2020 05:05:05 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v4]
In-Reply-To: <XKTvz2-x2vrvW523LJlGWOkDOqJP27e2n5OiqmmVjZY=.abce90e3-4e29-4a89-aa99-1f74a8bf95ea@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <vZkUHKS22sXksvEkZIlwencSsNSc0HTcCR-5Mp71daQ=.06eeb39b-39c4-4854-861d-432a4b95e946@github.com>
 <XKTvz2-x2vrvW523LJlGWOkDOqJP27e2n5OiqmmVjZY=.abce90e3-4e29-4a89-aa99-1f74a8bf95ea@github.com>
Message-ID: <7_wU3eWhv3jNcD6RLyg4Z9V0uM7PHklBQJqfeJmycZI=.e5251839-6fe9-4e79-9877-539af1098ad5@github.com>

On Wed, 23 Dec 2020 01:27:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   5th: 8257204 and 8256313
>>   8257204: Remove usage of -Xhtmlversion option from javac
>>   8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option
>
> src/jdk.compiler/share/man/javac.1 line 638:
> 
>> 636: .RS
>> 637: .RE
>> 638: .TP
> 
> In general, you should not edit files like this; these files are generated from upstream Markdown files.

Ok.  I will revert this with the next commit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/893

From jjg at openjdk.java.net  Wed Dec 23 05:13:04 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 23 Dec 2020 05:13:04 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
Message-ID: <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>

On Fri, 18 Dec 2020 02:34:16 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> HTML4 is no longer supported in javadoc.
>> 
>> doclint needs to drop HTML4 support as well.
>> The changes consist of:
>> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
>> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
>> * Modifying test code and expected outputs to be checked in HTML5
>
> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   5th: 8258460: Remove --doclint-format option from javac

One must-fix item (bad pattern constant.)

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 736:

> 734: 
> 735:     // https://html.spec.whatwg.org/#the-id-attribute
> 736:     private static final Pattern validId = Pattern.compile("[^\s]+");

The regular expression is invalid and needs to be fixed. It should be `Pattern.compile("[^\\s]+")`
Note the extra `` character. This is because you need to escape the `` character in the string constant, so that the `` is seen in the pattern as part of `\s`.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 710:

> 708: 
> 709: 
> 710:     private boolean checkAnchor(String name) {

I was going to let it slide for this round of cleanup, but if you're editing this file again (see comment on line 736) it might be worth changing the use of `anchor` to `id`.  `anchor` is a term that was more appropriate in the days before the `id` attribute, when we used `<a name="...">`.  This is an optional suggestion.  It might equally be worth focussing on the must-fix items, and postpone this cleanup for later.

-------------

Changes requested by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/893

From github.com+13688759+lgxbslgx at openjdk.java.net  Wed Dec 23 05:14:55 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Wed, 23 Dec 2020 05:14:55 GMT
Subject: RFR: 8258662: JDK 17ea: Crash compiling instanceof check
 involving sealed interface [v2]
In-Reply-To: <yKCyBjdADoFcainenSXFH7oFDQV7MiQNfGncV0Aw8ZM=.b358d42f-7db9-45dd-a5a4-61f02b55c307@github.com>
References: <NLtC9dIs-LiSiV5DFhmE7PcGsm2xhvG-n63_UnlELbw=.c2702d23-38ee-428f-9136-d0de5bbaf9f0@github.com>
 <1Bb94dovIOuWJQVYey6J9eYRHfcJKcd4SRBBtY2LMQw=.99fcf2d4-9675-4345-a121-7cf3c932d81a@github.com>
 <yKCyBjdADoFcainenSXFH7oFDQV7MiQNfGncV0Aw8ZM=.b358d42f-7db9-45dd-a5a4-61f02b55c307@github.com>
Message-ID: <GLZFHJ5j3KLNUu5lPYz8zvwo3qOsK9kPL4tntxtgH6g=.cf197967-b879-4092-9b4b-fbc5b1e15d4f@github.com>

On Wed, 23 Dec 2020 04:36:53 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use methods instead of instanceof
>
> the fix looks good to me but we need this code in JDK 16, please create another PR targeting JDK 16 and close this one. Thanks for the fix!

Move it to JDK 16. Please see https://github.com/openjdk/jdk16/pull/63.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1849

From github.com+13688759+lgxbslgx at openjdk.java.net  Wed Dec 23 05:14:57 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Wed, 23 Dec 2020 05:14:57 GMT
Subject: Withdrawn: 8258662: JDK 17ea: Crash compiling instanceof check
 involving sealed interface
In-Reply-To: <NLtC9dIs-LiSiV5DFhmE7PcGsm2xhvG-n63_UnlELbw=.c2702d23-38ee-428f-9136-d0de5bbaf9f0@github.com>
References: <NLtC9dIs-LiSiV5DFhmE7PcGsm2xhvG-n63_UnlELbw=.c2702d23-38ee-428f-9136-d0de5bbaf9f0@github.com>
Message-ID: <MizAKAo9GWmVpjiu2_imtlVFPkhwjLwHJY170E3REhI=.b618520d-5bed-4590-8463-158abcb22c2e@github.com>

On Sat, 19 Dec 2020 13:49:43 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> The method `Types.isCastable` uses method `Types.areDisjoint` to do some check. But `Types.isCastable` doesn't check the type of the parameter before invoking method `Types.areDisjoint`. This patch adds the corresponding check and add a test case.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1849

From github.com+13688759+lgxbslgx at openjdk.java.net  Wed Dec 23 05:16:08 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Wed, 23 Dec 2020 05:16:08 GMT
Subject: [jdk16] RFR: 8258662: JDK 17ea: Crash compiling instanceof check
 involving sealed interface
Message-ID: <MFzZOJ-kez-q_glvfq4TDsFyLs2dTP8PpoxdfnygmCE=.fa3a8634-850d-4eae-a33b-92b3715a7bcb@github.com>

Hi all,

The method `Types.isCastable` uses method `Types.areDisjoint` to do some check. But `Types.isCastable` doesn't check the type of the parameter before invoking method `Types.areDisjoint`. This patch adds the corresponding check and add a test case.

The original patch is in https://github.com/openjdk/jdk/pull/1849.

Thank you for taking the time to review.

Best Regards.

-------------

Commit messages:
 - 8258662: JDK 17ea: Crash compiling instanceof check involving sealed interface

Changes: https://git.openjdk.java.net/jdk16/pull/63/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=63&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258662
  Stats: 78 lines in 2 files changed: 77 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/63.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/63/head:pull/63

PR: https://git.openjdk.java.net/jdk16/pull/63

From ysatowse at openjdk.java.net  Wed Dec 23 05:41:02 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Wed, 23 Dec 2020 05:41:02 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
 <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
Message-ID: <K-lT5fBVeSNjXs6FNgsFaLRrhQWu-kclfX3TZf7FBXw=.55005f37-8658-4596-bb78-1b719af0f8e8@github.com>

On Wed, 23 Dec 2020 05:01:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   5th: 8258460: Remove --doclint-format option from javac
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 736:
> 
>> 734: 
>> 735:     // https://html.spec.whatwg.org/#the-id-attribute
>> 736:     private static final Pattern validId = Pattern.compile("[^\s]+");
> 
> The regular expression is invalid and needs to be fixed. It should be `Pattern.compile("[^\\s]+")`
> Note the extra `` character. This is because you need to escape the `` character in the string constant, so that the `` is seen in the pattern as part of `\s`.

Correct.  Thanks a lot for finding this error.  
Now that I have doubts why this line could have been compiled without error.  This line should cause a compiler error.

Let me review all anchor tests again because the logic should be checked there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/893

From ysatowse at openjdk.java.net  Wed Dec 23 06:45:01 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Wed, 23 Dec 2020 06:45:01 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
 <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
Message-ID: <SaZ-FbYfWjRxEVFDxnDM8nP_ljpFw-nj4Pe-mzl759s=.cf773bed-11dc-4017-bf0c-8aefd0c9873b@github.com>

On Wed, 23 Dec 2020 05:08:04 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   5th: 8258460: Remove --doclint-format option from javac
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 710:
> 
>> 708: 
>> 709: 
>> 710:     private boolean checkAnchor(String name) {
> 
> I was going to let it slide for this round of cleanup, but if you're editing this file again (see comment on line 736) it might be worth changing the use of `anchor` to `id`.  `anchor` is a term that was more appropriate in the days before the `id` attribute, when we used `<a name="...">`.  This is an optional suggestion.  It might equally be worth focussing on the must-fix items, and postpone this cleanup for later.

I understand.  But is it really no problem to be done in part of the cleanup of doclint?  
Looking at the classes in jdk/javadoc/internal/doclint,  the term `(anchor|Anchor)` looks like only used in Checker.java and resource files.  But a lot of other files, for instance in jdk/javadoc/internal/doclets, use this term to refer to the `id` or `name` attribute.  I would be fine if it is supposed to be done in each cleanup in the future.

-------------

PR: https://git.openjdk.java.net/jdk/pull/893

From ysatowse at openjdk.java.net  Wed Dec 23 07:54:02 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Wed, 23 Dec 2020 07:54:02 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <K-lT5fBVeSNjXs6FNgsFaLRrhQWu-kclfX3TZf7FBXw=.55005f37-8658-4596-bb78-1b719af0f8e8@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
 <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
 <K-lT5fBVeSNjXs6FNgsFaLRrhQWu-kclfX3TZf7FBXw=.55005f37-8658-4596-bb78-1b719af0f8e8@github.com>
Message-ID: <7A3J6XuVSinC1anOYqPp1FkPmq7D25z6Ed8x-dXUJsA=.3c9a56cd-cc38-4ab4-8f88-f991fd7709dd@github.com>

On Wed, 23 Dec 2020 05:38:36 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 736:
>> 
>>> 734: 
>>> 735:     // https://html.spec.whatwg.org/#the-id-attribute
>>> 736:     private static final Pattern validId = Pattern.compile("[^\s]+");
>> 
>> The regular expression is invalid and needs to be fixed. It should be `Pattern.compile("[^\\s]+")`
>> Note the extra `` character. This is because you need to escape the `` character in the string constant, so that the `` is seen in the pattern as part of `\s`.
>
> Correct.  Thanks a lot for finding this error.  
> Now that I have doubts why this line could have been compiled without error.  This line should cause a compiler error.
> 
> Let me review all anchor tests again because the logic should be checked there.

For some reason, `"[^\s]+"` might have been dealt with as a text block, thus `\s` was regarded as a whitespace...
I believe a text block is defined with triple double quotes, but javac seems to accept `"[^\s]+"` as a text block.

That aside, all anchor tests look fine.  This is because there is no specific test to use whitespace characters such as `\n`, `\t`, `\r` and `\f` in an anchor name.  Also I confirmed the discrepancy of the results for `"[^\s]+"` and `"[^\\s]+"`.  It shows that the former is not exactly what we want to do.

$ jshell -J-Duser.language=en -J--show-version
java 15 2020-09-15
Java(TM) SE Runtime Environment (build 15+36-1562)
Java HotSpot(TM) 64-Bit Server VM (build 15+36-1562, mixed mode, sharing)
|  Welcome to JShell -- Version 15
|  For an introduction type: /help intro

jshell> Pattern validId1 = Pattern.compile("[^\s]+")
validId1 ==> [^ ]+

jshell> Pattern validId2 = Pattern.compile("[^\\s]+")
validId2 ==> [^\s]+

jshell> validId1.matcher("aaa").matches()
$3 ==> true

jshell> validId1.matcher("aaa ").matches()
$4 ==> false

jshell> validId1.matcher("aaa\n").matches()
$5 ==> true

jshell> validId2.matcher("aaa").matches()
$6 ==> true

jshell> validId2.matcher("aaa ").matches()
$7 ==> false

jshell> validId2.matcher("aaa\n").matches()
$8 ==> false

-------------

PR: https://git.openjdk.java.net/jdk/pull/893

From ysatowse at openjdk.java.net  Wed Dec 23 08:18:01 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Wed, 23 Dec 2020 08:18:01 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <SaZ-FbYfWjRxEVFDxnDM8nP_ljpFw-nj4Pe-mzl759s=.cf773bed-11dc-4017-bf0c-8aefd0c9873b@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
 <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
 <SaZ-FbYfWjRxEVFDxnDM8nP_ljpFw-nj4Pe-mzl759s=.cf773bed-11dc-4017-bf0c-8aefd0c9873b@github.com>
Message-ID: <hEsFMq6xyUUyDmTATPckbAPUprE9p2Ycqqzk2GXUlJM=.6308c33d-0ba2-4de7-9c63-b26b9783a138@github.com>

On Wed, 23 Dec 2020 06:42:21 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java line 710:
>> 
>>> 708: 
>>> 709: 
>>> 710:     private boolean checkAnchor(String name) {
>> 
>> I was going to let it slide for this round of cleanup, but if you're editing this file again (see comment on line 736) it might be worth changing the use of `anchor` to `id`.  `anchor` is a term that was more appropriate in the days before the `id` attribute, when we used `<a name="...">`.  This is an optional suggestion.  It might equally be worth focussing on the must-fix items, and postpone this cleanup for later.
>
> I understand.  But is it really no problem to be done in part of the cleanup of doclint?  
> Looking at the classes in jdk/javadoc/internal/doclint,  the term `(anchor|Anchor)` looks like only used in Checker.java and resource files.  But a lot of other files, for instance in jdk/javadoc/internal/doclets, use this term to refer to the `id` or `name` attribute.  I would be fine if it is supposed to be done in each cleanup in the future.

If we would apply similar changing to doclint.properties, what you are thinking is like below right?

-dc.anchor.already.defined = anchor already defined: "{0}"
-dc.anchor.value.missing = no value given for anchor
+dc.id.already.defined = attribute "id" already defined: "{0}"
+dc.id.value.missing = no value given for attribute "id"

-dc.invalid.anchor = invalid name for anchor: "{0}"
-dc.invalid.id = invalid name for attribute "id": "{0}"

-------------

PR: https://git.openjdk.java.net/jdk/pull/893

From dawid.weiss at gmail.com  Wed Dec 23 10:39:05 2020
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Wed, 23 Dec 2020 11:39:05 +0100
Subject: javac reports broken HTML on multiline mailto links
Message-ID: <CAM21Rt9eOgXWA8dq6HUwJPW7nFpnPp7YcdQKHYRMaMmMGyEmpA@mail.gmail.com>

Hello and Merry Christmas,

I discovered this odd javac behavior with jdk8 up to jdk15 (didn't
check the latest head). This source file (note the anchor tag over
multiple lines):

/**
 * Lucene internals or asking for help on <a
 * href="mailto:java-user at lucene.apache.org">java-user at lucene.apache.org</a>
  */
public class Breaks {}

When compiled with

javac -Xdoclint:all/protected Breaks.java

generates this:

Breaks.java:2: error: malformed HTML
 * Lucene internals or asking for help on <a
                                          ^
Breaks.java:3: error: bad use of '>'
 * href="mailto:java-user at lucene.apache.org">java-user at lucene.apache.org</a>
                                            ^
Breaks.java:3: error: unexpected end tag: </a>
 * href="mailto:java-user at lucene.apache.org">java-user at lucene.apache.org</a>
                                                                        ^
What's interesting is that the following two alternatives compile just fine:

/**
 * Lucene internals or asking for help on <a
 * href="http://lucene.apache.org">java-user at lucene.apache.org</a>
  */
public class Passes {}

/**
 * Lucene internals or asking for help on <a
href="mailto:java-user at lucene.apache.org">java-user at lucene.apache.org</a>
to figure out why.
  */
public class Passes2 {}

Is it just me or all these should compile just fine?...

Dawid

[1] Just in case mail clients attempt to reformat the pasted examples,
here's a gist with
the sources:
https://gist.github.com/dweiss/c1c9f218c6a8e5d2f253193806a9f472

From bsrbnd at gmail.com  Wed Dec 23 15:32:26 2020
From: bsrbnd at gmail.com (B. Blaser)
Date: Wed, 23 Dec 2020 16:32:26 +0100
Subject: [Ask for sponsoring] Fix another NPE in
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:571)
In-Reply-To: <CAM1U-w99wL6JLhLSMs9ymY4PYX4cNx+rW-zhjFgjbNv0BiREPA@mail.gmail.com>
References: <CAM1U-w_DyumchOqfy5Hn4FwWtW-e7p=o399neaHXcS_ZAL9H4Q@mail.gmail.com>
 <CAEgw74DWC5zK5vsKnm-ajWChachDZ2xNc4Yv7en3mWOMUFX79w@mail.gmail.com>
 <CAM1U-w99wL6JLhLSMs9ymY4PYX4cNx+rW-zhjFgjbNv0BiREPA@mail.gmail.com>
Message-ID: <CAEgw74BUQSvn+gFCZ91ciT2qcTOrmTpT=iyi=mSgN8GRJLv8sQ@mail.gmail.com>

Hi Jia,

On Wed, 23 Dec 2020 at 05:49, JiaYanwei <jiaywe at gmail.com> wrote:
>
> Great! I think it's the best solution and can also be directly backported to 16, 11 & 8.
>
> Should I close (i.e. stop/cancel) the Github PR, or may I commit this code with you(B. Blaser) as the author - just like what Jan Lahoda did in Github PR 1221?

Thanks for your feedback, I filed
https://bugs.openjdk.java.net/browse/JDK-8258897 and assigned it to
Jan (I hope he won't mind). So, I'll let him or maybe Jon advise on
what to do with the pull request.

Regards,
Bernard

From jjg at openjdk.java.net  Wed Dec 23 15:56:01 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 23 Dec 2020 15:56:01 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
 <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
Message-ID: <Jhwh9hnH9R7CiGsV4S7zgAu2nXrfXURb3KX7D-f3Jkg=.66a19e92-54db-4530-9360-47072587f180@github.com>

On Wed, 23 Dec 2020 05:10:31 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   5th: 8258460: Remove --doclint-format option from javac
>
> One must-fix item (bad pattern constant.)

\s was introduced as a valid escape character in JDK 15 as part of the 
support for Text Blocks.

https://docs.oracle.com/javase/specs/jls/se15/html/jls-3.html#jls-EscapeSequence
https://docs.oracle.com/javase/specs/jls/se14/preview/specs/text-blocks-jls.html#jls-3.10.7

FWIW, the escape sequence showed up with red squiggly lines in my IDE.

-- Jon

On 12/22/20 9:38 PM, Yoshiki SATO wrote:
>
> *@satoyoshiki* commented on this pull request.
>
> ------------------------------------------------------------------------
>
> In 
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547668049__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZiYojsWrqg$>:
>
> > @@ -765,8 +732,8 @@ private Element getEnclosingPackageOrClass(Element e) {
>           return e;
>       }
>   
> -    //http://www.w3.org/TR/html401/types.html#type-name  <https://urldefense.com/v3/__http://www.w3.org/TR/html401/types.html*type-name__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZibVYnjqnQ$>
> -    private static final Pattern validName = Pattern.compile("[A-Za-z][A-Za-z0-9-_:.]*");
> +    //https://html.spec.whatwg.org/#the-id-attribute  <https://urldefense.com/v3/__https://html.spec.whatwg.org/*the-id-attribute__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZib5vw0eRg$>
> +    private static final Pattern validId = Pattern.compile("[^\s]+");
>
> Correct. Thanks a lot for finding this error.
> Now that I have doubts why this line could have been compiled without 
> error. This line should cause a compiler error.
>
> Let me review all anchor tests again because the logic should be 
> checked there.
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547668049__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZiYojsWrqg$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRXCJBCNZR4ZUBZCEBTSWF66TANCNFSM4TBXTH2Q__;!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZia6kQL08w$>.
>

-------------

PR: https://git.openjdk.java.net/jdk/pull/893

From jiaywe at gmail.com  Wed Dec 23 16:44:20 2020
From: jiaywe at gmail.com (JiaYanwei)
Date: Thu, 24 Dec 2020 00:44:20 +0800
Subject: [Ask for sponsoring] Fix another NPE in
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:571)
In-Reply-To: <CAEgw74BUQSvn+gFCZ91ciT2qcTOrmTpT=iyi=mSgN8GRJLv8sQ@mail.gmail.com>
References: <CAM1U-w_DyumchOqfy5Hn4FwWtW-e7p=o399neaHXcS_ZAL9H4Q@mail.gmail.com>
 <CAEgw74DWC5zK5vsKnm-ajWChachDZ2xNc4Yv7en3mWOMUFX79w@mail.gmail.com>
 <CAM1U-w99wL6JLhLSMs9ymY4PYX4cNx+rW-zhjFgjbNv0BiREPA@mail.gmail.com>
 <CAEgw74BUQSvn+gFCZ91ciT2qcTOrmTpT=iyi=mSgN8GRJLv8sQ@mail.gmail.com>
Message-ID: <CAM1U-w_3wdwjh4qpC9GK1RT6hG31-Em+x0H56q89JbdB4nnsHg@mail.gmail.com>

Hi Bernard,

Thank you!

Best Regards,
Yanwei

B. Blaser <bsrbnd at gmail.com> ?2020?12?23??? ??11:32???

> Hi Jia,
>
> On Wed, 23 Dec 2020 at 05:49, JiaYanwei <jiaywe at gmail.com> wrote:
> >
> > Great! I think it's the best solution and can also be directly
> backported to 16, 11 & 8.
> >
> > Should I close (i.e. stop/cancel) the Github PR, or may I commit this
> code with you(B. Blaser) as the author - just like what Jan Lahoda did in
> Github PR 1221?
>
> Thanks for your feedback, I filed
> https://bugs.openjdk.java.net/browse/JDK-8258897 and assigned it to
> Jan (I hope he won't mind). So, I'll let him or maybe Jon advise on
> what to do with the pull request.
>
> Regards,
> Bernard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20201224/db52f741/attachment.htm>

From github.com+13688759+lgxbslgx at openjdk.java.net  Wed Dec 23 17:11:06 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Wed, 23 Dec 2020 17:11:06 GMT
Subject: RFR: 8239596: PARAMETER annotation on receiver type does not cause
 error
Message-ID: <HIPFxHVe1NJS2dldCZjPosdBxw-cZgpUE-PXc4WZroE=.2f69a16b-017b-44a0-89cd-a0686223c270@github.com>

Hi all,

`TypeAnnotationsValidator::visitMethodDef`  uses `checkForDeclarationAnnotations` incorrectly so that the check could not work as expected and some related errors are not reported. This patch fixes it and adds a corresponding test case.

Thank you for taking the time to review.

Best Regards.

-------------

Commit messages:
 - 8239596: PARAMETER annotation on receiver type does not cause error

Changes: https://git.openjdk.java.net/jdk/pull/1881/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1881&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8239596
  Stats: 89 lines in 2 files changed: 87 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1881.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1881/head:pull/1881

PR: https://git.openjdk.java.net/jdk/pull/1881

From jjg at openjdk.java.net  Wed Dec 23 17:12:03 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 23 Dec 2020 17:12:03 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <Jhwh9hnH9R7CiGsV4S7zgAu2nXrfXURb3KX7D-f3Jkg=.66a19e92-54db-4530-9360-47072587f180@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
 <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
 <Jhwh9hnH9R7CiGsV4S7zgAu2nXrfXURb3KX7D-f3Jkg=.66a19e92-54db-4530-9360-47072587f180@github.com>
Message-ID: <xZxi9rbJ9VUlAsG3ZJrHI8dfziWoH1Gt0ti6IKe4wwI=.c8f0f568-b94e-4ba3-9451-e2ef361a6f11@github.com>

On Wed, 23 Dec 2020 15:53:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> One must-fix item (bad pattern constant.)
>
> \s was introduced as a valid escape character in JDK 15 as part of the 
> support for Text Blocks.
> 
> https://docs.oracle.com/javase/specs/jls/se15/html/jls-3.html#jls-EscapeSequence
> https://docs.oracle.com/javase/specs/jls/se14/preview/specs/text-blocks-jls.html#jls-3.10.7
> 
> FWIW, the escape sequence showed up with red squiggly lines in my IDE.
> 
> -- Jon
> 
> On 12/22/20 9:38 PM, Yoshiki SATO wrote:
>>
>> *@satoyoshiki* commented on this pull request.
>>
>> ------------------------------------------------------------------------
>>
>> In 
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547668049__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZiYojsWrqg$>:
>>
>> > @@ -765,8 +732,8 @@ private Element getEnclosingPackageOrClass(Element e) {
>>           return e;
>>       }
>>   
>> -    //http://www.w3.org/TR/html401/types.html#type-name  <https://urldefense.com/v3/__http://www.w3.org/TR/html401/types.html*type-name__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZibVYnjqnQ$>
>> -    private static final Pattern validName = Pattern.compile("[A-Za-z][A-Za-z0-9-_:.]*");
>> +    //https://html.spec.whatwg.org/#the-id-attribute  <https://urldefense.com/v3/__https://html.spec.whatwg.org/*the-id-attribute__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZib5vw0eRg$>
>> +    private static final Pattern validId = Pattern.compile("[^\s]+");
>>
>> Correct. Thanks a lot for finding this error.
>> Now that I have doubts why this line could have been compiled without 
>> error. This line should cause a compiler error.
>>
>> Let me review all anchor tests again because the logic should be 
>> checked there.
>>
>> ?
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547668049__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZiYojsWrqg$>, 
>> or unsubscribe 
>> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRXCJBCNZR4ZUBZCEBTSWF66TANCNFSM4TBXTH2Q__;!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZia6kQL08w$>.
>>

On 12/22/20 10:42 PM, Yoshiki SATO wrote:
>
> *@satoyoshiki* commented on this pull request.
>
> ------------------------------------------------------------------------
>
> In 
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547716025__;Iw!!GqivPVa7Brio!Oae1uD8yALBU6ReCJTwKccZjdEsGyXddDLOOeF2SJLi8x7SoU5jr-Jr0KVl2EVajBRHM-g$>:
>
> > -    }
> -
> -    private void validateHtml5Attrs(AttributeTree tree, Name name, AttrKind k) {
> -        switch (k) {
> -            case ALL:
> -            case HTML5:
> -                break;
> -
> -            case INVALID:
> -            case OBSOLETE:
> -            case USE_CSS:
> -            case HTML4:
> -                env.messages.error(HTML, tree, "dc.attr.not.supported.html5", name);
> -                break;
> -        }
> -    }
>   
>       private boolean checkAnchor(String name) {
>
> I understand. But is it really no problem to be done in part of the 
> cleanup of doclint?
> Looking at the classes in jdk/javadoc/internal/doclint, the term 
> |(anchor|Anchor)| looks like only used in Checker.java and resource 
> files. But a lot of other files, for instance in 
> jdk/javadoc/internal/doclets, use this term to refer to the |id| or 
> |name| attribute. I would be fine if it is supposed to be done in each 
> cleanup in the future.
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547716025__;Iw!!GqivPVa7Brio!Oae1uD8yALBU6ReCJTwKccZjdEsGyXddDLOOeF2SJLi8x7SoU5jr-Jr0KVl2EVajBRHM-g$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRQS4FULCERHKMAZ5OLSWGGNVANCNFSM4TBXTH2Q__;!!GqivPVa7Brio!Oae1uD8yALBU6ReCJTwKccZjdEsGyXddDLOOeF2SJLi8x7SoU5jr-Jr0KVl2EVYEkdTG2A$>.
>

If you were to cleanup the "anchor" terminology, it should only be done 
in doclint, meaning Checker.java and resource files. Cleaning up 
terminology in the rest of javadoc is another project for another day. 
But, it's OK to skip this terminology cleanup in doclint at this time, 
since it is only peripherally related to the primary goal to remove 
HTML4 support.

-- Jon

>

-------------

PR: https://git.openjdk.java.net/jdk/pull/893

From jjg at openjdk.java.net  Wed Dec 23 17:15:01 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 23 Dec 2020 17:15:01 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <xZxi9rbJ9VUlAsG3ZJrHI8dfziWoH1Gt0ti6IKe4wwI=.c8f0f568-b94e-4ba3-9451-e2ef361a6f11@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
 <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
 <Jhwh9hnH9R7CiGsV4S7zgAu2nXrfXURb3KX7D-f3Jkg=.66a19e92-54db-4530-9360-47072587f180@github.com>
 <xZxi9rbJ9VUlAsG3ZJrHI8dfziWoH1Gt0ti6IKe4wwI=.c8f0f568-b94e-4ba3-9451-e2ef361a6f11@github.com>
Message-ID: <RnaZOYLCduGjwzYR_Kq6vul_nmOFpjFDXfuYZ4Dt0Zo=.a22a9652-2e6d-49ac-a4cb-cc0b7d945b11@github.com>

On Wed, 23 Dec 2020 17:08:55 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> \s was introduced as a valid escape character in JDK 15 as part of the 
>> support for Text Blocks.
>> 
>> https://docs.oracle.com/javase/specs/jls/se15/html/jls-3.html#jls-EscapeSequence
>> https://docs.oracle.com/javase/specs/jls/se14/preview/specs/text-blocks-jls.html#jls-3.10.7
>> 
>> FWIW, the escape sequence showed up with red squiggly lines in my IDE.
>> 
>> -- Jon
>> 
>> On 12/22/20 9:38 PM, Yoshiki SATO wrote:
>>>
>>> *@satoyoshiki* commented on this pull request.
>>>
>>> ------------------------------------------------------------------------
>>>
>>> In 
>>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java 
>>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547668049__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZiYojsWrqg$>:
>>>
>>> > @@ -765,8 +732,8 @@ private Element getEnclosingPackageOrClass(Element e) {
>>>           return e;
>>>       }
>>>   
>>> -    //http://www.w3.org/TR/html401/types.html#type-name  <https://urldefense.com/v3/__http://www.w3.org/TR/html401/types.html*type-name__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZibVYnjqnQ$>
>>> -    private static final Pattern validName = Pattern.compile("[A-Za-z][A-Za-z0-9-_:.]*");
>>> +    //https://html.spec.whatwg.org/#the-id-attribute  <https://urldefense.com/v3/__https://html.spec.whatwg.org/*the-id-attribute__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZib5vw0eRg$>
>>> +    private static final Pattern validId = Pattern.compile("[^\s]+");
>>>
>>> Correct. Thanks a lot for finding this error.
>>> Now that I have doubts why this line could have been compiled without 
>>> error. This line should cause a compiler error.
>>>
>>> Let me review all anchor tests again because the logic should be 
>>> checked there.
>>>
>>> ?
>>> You are receiving this because you were mentioned.
>>> Reply to this email directly, view it on GitHub 
>>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547668049__;Iw!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZiYojsWrqg$>, 
>>> or unsubscribe 
>>> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRXCJBCNZR4ZUBZCEBTSWF66TANCNFSM4TBXTH2Q__;!!GqivPVa7Brio!OUEFldgNdIV8aqoReM0lNXfIYO3IoXGR1RUbcYmVdEHRRdA3oy1Zaa3h2DevZia6kQL08w$>.
>>>
>
> On 12/22/20 10:42 PM, Yoshiki SATO wrote:
>>
>> *@satoyoshiki* commented on this pull request.
>>
>> ------------------------------------------------------------------------
>>
>> In 
>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547716025__;Iw!!GqivPVa7Brio!Oae1uD8yALBU6ReCJTwKccZjdEsGyXddDLOOeF2SJLi8x7SoU5jr-Jr0KVl2EVajBRHM-g$>:
>>
>> > -    }
>> -
>> -    private void validateHtml5Attrs(AttributeTree tree, Name name, AttrKind k) {
>> -        switch (k) {
>> -            case ALL:
>> -            case HTML5:
>> -                break;
>> -
>> -            case INVALID:
>> -            case OBSOLETE:
>> -            case USE_CSS:
>> -            case HTML4:
>> -                env.messages.error(HTML, tree, "dc.attr.not.supported.html5", name);
>> -                break;
>> -        }
>> -    }
>>   
>>       private boolean checkAnchor(String name) {
>>
>> I understand. But is it really no problem to be done in part of the 
>> cleanup of doclint?
>> Looking at the classes in jdk/javadoc/internal/doclint, the term 
>> |(anchor|Anchor)| looks like only used in Checker.java and resource 
>> files. But a lot of other files, for instance in 
>> jdk/javadoc/internal/doclets, use this term to refer to the |id| or 
>> |name| attribute. I would be fine if it is supposed to be done in each 
>> cleanup in the future.
>>
>> ?
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547716025__;Iw!!GqivPVa7Brio!Oae1uD8yALBU6ReCJTwKccZjdEsGyXddDLOOeF2SJLi8x7SoU5jr-Jr0KVl2EVajBRHM-g$>, 
>> or unsubscribe 
>> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRQS4FULCERHKMAZ5OLSWGGNVANCNFSM4TBXTH2Q__;!!GqivPVa7Brio!Oae1uD8yALBU6ReCJTwKccZjdEsGyXddDLOOeF2SJLi8x7SoU5jr-Jr0KVl2EVYEkdTG2A$>.
>>
> 
> If you were to cleanup the "anchor" terminology, it should only be done 
> in doclint, meaning Checker.java and resource files. Cleaning up 
> terminology in the rest of javadoc is another project for another day. 
> But, it's OK to skip this terminology cleanup in doclint at this time, 
> since it is only peripherally related to the primary goal to remove 
> HTML4 support.
> 
> -- Jon
> 
>>

Although `\s` was introduced as part of the work for text blocks, it was 
added to the set of escape characters accepted in string and character 
literals. So, no, that constant is not being treated as a text block, 
because text blocks only begin and end with triple-quotes: `"""`

See the JLS links I gave in my previous response.

-- Jon

On 12/22/20 11:50 PM, Yoshiki SATO wrote:
>
> *@satoyoshiki* commented on this pull request.
>
> ------------------------------------------------------------------------
>
> In 
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547768833__;Iw!!GqivPVa7Brio!JzRqq_cZpzUEFer1m5NX92ABR7tcna9povirJpPwfSxuO4EFI0tRAmRLw80UwpJdsJ1BgQ$>:
>
> > @@ -765,8 +732,8 @@ private Element getEnclosingPackageOrClass(Element e) {
>           return e;
>       }
>   
> -    //http://www.w3.org/TR/html401/types.html#type-name  <https://urldefense.com/v3/__http://www.w3.org/TR/html401/types.html*type-name__;Iw!!GqivPVa7Brio!JzRqq_cZpzUEFer1m5NX92ABR7tcna9povirJpPwfSxuO4EFI0tRAmRLw80UwpJRSKFcFA$>
> -    private static final Pattern validName = Pattern.compile("[A-Za-z][A-Za-z0-9-_:.]*");
> +    //https://html.spec.whatwg.org/#the-id-attribute  <https://urldefense.com/v3/__https://html.spec.whatwg.org/*the-id-attribute__;Iw!!GqivPVa7Brio!JzRqq_cZpzUEFer1m5NX92ABR7tcna9povirJpPwfSxuO4EFI0tRAmRLw80UwpLwqIk5gQ$>
> +    private static final Pattern validId = Pattern.compile("[^\s]+");
>
> For some reason, |"[^\s]+"| might have been dealt with as a text 
> block, thus |\s| was regarded as a whitespace...
> I believe a text block is defined with triple double quotes, but javac 
> seems to accept |"[^\s]+"| as a text block.
>
> That aside, all anchor tests look fine. This is because there is no 
> specific test to use whitespace characters such as |\n|, |\t|, |\r| 
> and |\f| in an anchor name. Also I confirmed the discrepancy of the 
> results for |"[^\s]+"| and |"[^\\s]+"|. It shows that the former is 
> not exactly what we want to do.
>
> /var/tmp/jib-yoshiki/install/jdk/15/36/bundles/osx-x64/jdk-15_osx-x64_bin.tar.gz/jdk-15.jdk/Contents/Home/bin/jshell 
> -J-Duser.language=en -J--show-version
> java 15 2020-09-15
> Java(TM) SE Runtime Environment (build 15+36-1562)
> Java HotSpot(TM) 64-Bit Server VM (build 15+36-1562, mixed mode, sharing)
> | Welcome to JShell -- Version 15
> | For an introduction type: /help intro
>
> jshell> Pattern validId1 = Pattern.compile("[^\s]+")
> validId1 ==> [^ ]+
>
> jshell> Pattern validId2 = Pattern.compile("[^\s]+")
> validId2 ==> [^\s]+
>
> jshell> validId1.matcher("aaa").matches()
> $3 ==> true
>
> jshell> validId1.matcher("aaa ").matches()
> $4 ==> false
>
> jshell> validId1.matcher("aaa\n").matches()
> $5 ==> true
>
> jshell> validId2.matcher("aaa").matches()
> $6 ==> true
>
> jshell> validId2.matcher("aaa ").matches()
> $7 ==> false
>
> jshell> validId2.matcher("aaa\n").matches()
> $8 ==> false
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/893*discussion_r547768833__;Iw!!GqivPVa7Brio!JzRqq_cZpzUEFer1m5NX92ABR7tcna9povirJpPwfSxuO4EFI0tRAmRLw80UwpJdsJ1BgQ$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRQZVY3MLTBJ7SZR7ETSWGONXANCNFSM4TBXTH2Q__;!!GqivPVa7Brio!JzRqq_cZpzUEFer1m5NX92ABR7tcna9povirJpPwfSxuO4EFI0tRAmRLw80UwpK72GWUdA$>.
>

-------------

PR: https://git.openjdk.java.net/jdk/pull/893

From jonathan.gibbons at oracle.com  Wed Dec 23 19:39:17 2020
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 23 Dec 2020 11:39:17 -0800
Subject: [Ask for sponsoring] Fix another NPE in
 jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:571)
In-Reply-To: <CAEgw74BUQSvn+gFCZ91ciT2qcTOrmTpT=iyi=mSgN8GRJLv8sQ@mail.gmail.com>
References: <CAM1U-w_DyumchOqfy5Hn4FwWtW-e7p=o399neaHXcS_ZAL9H4Q@mail.gmail.com>
 <CAEgw74DWC5zK5vsKnm-ajWChachDZ2xNc4Yv7en3mWOMUFX79w@mail.gmail.com>
 <CAM1U-w99wL6JLhLSMs9ymY4PYX4cNx+rW-zhjFgjbNv0BiREPA@mail.gmail.com>
 <CAEgw74BUQSvn+gFCZ91ciT2qcTOrmTpT=iyi=mSgN8GRJLv8sQ@mail.gmail.com>
Message-ID: <4ef2c9d0-cf0c-bec9-f0e0-76a439005163@oracle.com>

Bernard, Jia,

You need an expert in this part of the code to do the review, and the likely
experts are on vacation through the end of the year and may not be able
to respond before the first week of next year.

As a matter of policy, if folk (you+reviewers) think this should go in 16,
you need to file the PR against the jdk16 repo. From there, it will 
eventually
and automatically be forward-ported to the main jdk rep.

Note there will only be a limited window in the new year to fix bugs in 16.
See the schedule for JDK 16 here:
https://openjdk.java.net/projects/jdk/16/

-- Jon

On 12/23/20 7:32 AM, B. Blaser wrote:
> Hi Jia,
>
> On Wed, 23 Dec 2020 at 05:49, JiaYanwei <jiaywe at gmail.com> wrote:
>> Great! I think it's the best solution and can also be directly backported to 16, 11 & 8.
>>
>> Should I close (i.e. stop/cancel) the Github PR, or may I commit this code with you(B. Blaser) as the author - just like what Jan Lahoda did in Github PR 1221?
> Thanks for your feedback, I filed
> https://bugs.openjdk.java.net/browse/JDK-8258897 and assigned it to
> Jan (I hope he won't mind). So, I'll let him or maybe Jon advise on
> what to do with the pull request.
>
> Regards,
> Bernard

From vromero at openjdk.java.net  Wed Dec 23 20:31:02 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 23 Dec 2020 20:31:02 GMT
Subject: [jdk16] RFR: 8253954: javac crash when compiling code with enhanced
 switch expressions with option -Xjcov
Message-ID: <QN3gqFi6fNU-jEXXg2PYvHLrxgnHO2gEn95K_W3sydI=.da8551af-f968-460b-bc7c-8a0e550fbb13@github.com>

Please review this one liner patch that is fixing a crash in javac when compiling with option `-Xjcov`. The crash was due to an assertion failure at `com.sun.tools.javac.jvm.CRTable` as no position was found for compiler generated `yield` trees in some cases. The fix is to visit the `value` expression in the `yield` tree so that when the CRT table is being generated, the position for the `yield` tree is not `null`

TIA

-------------

Commit messages:
 - Merge branch 'master' into JDK-8253954
 - 8253954: javac crash when compiling code with enhanced switch expressions with option -Xjcov

Changes: https://git.openjdk.java.net/jdk16/pull/66/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=66&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253954
  Stats: 45 lines in 2 files changed: 45 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/66.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/66/head:pull/66

PR: https://git.openjdk.java.net/jdk16/pull/66

From jjg at openjdk.java.net  Wed Dec 23 21:11:59 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 23 Dec 2020 21:11:59 GMT
Subject: [jdk16] RFR: 8253954: javac crash when compiling code with
 enhanced switch expressions with option -Xjcov
In-Reply-To: <QN3gqFi6fNU-jEXXg2PYvHLrxgnHO2gEn95K_W3sydI=.da8551af-f968-460b-bc7c-8a0e550fbb13@github.com>
References: <QN3gqFi6fNU-jEXXg2PYvHLrxgnHO2gEn95K_W3sydI=.da8551af-f968-460b-bc7c-8a0e550fbb13@github.com>
Message-ID: <TcMVBhniBTwP9WVc2hI9tz5hWliqMz5hdshiKetnOs4=.1df627b5-eac8-43da-8b4c-b115b92f91d0@github.com>

On Wed, 23 Dec 2020 20:25:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this one liner patch that is fixing a crash in javac when compiling with option `-Xjcov`. The crash was due to an assertion failure at `com.sun.tools.javac.jvm.CRTable` as no position was found for compiler generated `yield` trees in some cases. The fix is to visit the `value` expression in the `yield` tree so that when the CRT table is being generated, the position for the `yield` tree is not `null`
> 
> TIA

Looks OK to me

-------------

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/66

From ysatowse at openjdk.java.net  Thu Dec 24 01:17:00 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Thu, 24 Dec 2020 01:17:00 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v5]
In-Reply-To: <Jhwh9hnH9R7CiGsV4S7zgAu2nXrfXURb3KX7D-f3Jkg=.66a19e92-54db-4530-9360-47072587f180@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <qLWbJ9PDN8m4Lx7CG3JB_B8YFeAL3MiXfnmjgVYgZ8w=.c9276710-9637-4b25-a275-13ca336e988c@github.com>
 <oYLJ4H1-8m_-vudrpTG9HFAauozvrmWj8VGixyZ9L8g=.90efff73-4552-4fcc-8689-f71b742e8ccc@github.com>
 <Jhwh9hnH9R7CiGsV4S7zgAu2nXrfXURb3KX7D-f3Jkg=.66a19e92-54db-4530-9360-47072587f180@github.com>
Message-ID: <VDi3Ijs-MdtHTAXBk6LNoIDeCxdgIEuWWteMuyyeveI=.c1ac5846-7028-4247-92a6-be63a6ce935b@github.com>

On Wed, 23 Dec 2020 15:53:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> \s was introduced as a valid escape character in JDK 15 as part of the support for Text Blocks. https://docs.oracle.com/javase/specs/jls/se15/html/jls-3.html#jls-EscapeSequence https://docs.oracle.com/javase/specs/jls/se14/preview/specs/text-blocks-jls.html#jls-3.10.7 FWIW, the escape sequence showed up with red squiggly lines in my IDE.
> [?](#)

Ok.  I didn't know that.  When I change my project SDK to 14, the escape sequence showed up with red squiggly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/893

From vromero at openjdk.java.net  Thu Dec 24 01:26:55 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 24 Dec 2020 01:26:55 GMT
Subject: [jdk16] Integrated: 8253954: javac crash when compiling code with
 enhanced switch expressions with option -Xjcov
In-Reply-To: <QN3gqFi6fNU-jEXXg2PYvHLrxgnHO2gEn95K_W3sydI=.da8551af-f968-460b-bc7c-8a0e550fbb13@github.com>
References: <QN3gqFi6fNU-jEXXg2PYvHLrxgnHO2gEn95K_W3sydI=.da8551af-f968-460b-bc7c-8a0e550fbb13@github.com>
Message-ID: <y5OVc_s4I3GPpij3NmiDE0N8Yp7_UUj8Gn_1nP4-ARo=.991c5caa-11a8-4316-9086-cd4e79ad7dda@github.com>

On Wed, 23 Dec 2020 20:25:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this one liner patch that is fixing a crash in javac when compiling with option `-Xjcov`. The crash was due to an assertion failure at `com.sun.tools.javac.jvm.CRTable` as no position was found for compiler generated `yield` trees in some cases. The fix is to visit the `value` expression in the `yield` tree so that when the CRT table is being generated, the position for the `yield` tree is not `null`
> 
> TIA

This pull request has now been integrated.

Changeset: 23b83c51
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/23b83c51
Stats:     45 lines in 2 files changed: 45 ins; 0 del; 0 mod

8253954: javac crash when compiling code with enhanced switch expressions with option -Xjcov

Reviewed-by: jjg

-------------

PR: https://git.openjdk.java.net/jdk16/pull/66

From jjg at openjdk.java.net  Thu Dec 24 02:09:05 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 24 Dec 2020 02:09:05 GMT
Subject: [jdk16] RFR: JDK-8258916: javac/doclint reports broken HTML on
 multiline mailto links
Message-ID: <8D7rBvR2PWIrPXSnfv1wxmUoilT3MOVUgvqFcHHYnVQ=.21b6765e-1368-46f8-a2e9-7c41d6d121ea@github.com>

Please review a trivial fix to correctly handle '@' inside the value of an HTML attribute. 
The fix is simply to cancel the `newline` flag that is set when a newline has been read.

-------------

Commit messages:
 - JDK-8258916: javac reports broken HTML on multiline mailto links

Changes: https://git.openjdk.java.net/jdk16/pull/68/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=68&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258916
  Stats: 8 lines in 2 files changed: 7 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/68.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/68/head:pull/68

PR: https://git.openjdk.java.net/jdk16/pull/68

From ysatowse at openjdk.java.net  Thu Dec 24 02:54:17 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Thu, 24 Dec 2020 02:54:17 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v6]
In-Reply-To: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
Message-ID: <iAxu3KnauDOTBgSQCyVQoI8PZXWJC96g-CTZQCD8dU8=.be3b7775-1a43-42ed-87cc-6471ff5baa13@github.com>

> HTML4 is no longer supported in javadoc.
> 
> doclint needs to drop HTML4 support as well.
> The changes consist of:
> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
> * Modifying test code and expected outputs to be checked in HTML5

Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:

  7th: Some fixes and additional changes for 8247957

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/893/files
  - new: https://git.openjdk.java.net/jdk/pull/893/files/261f207a..8a0e1193

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=893&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=893&range=04-05

  Stats: 17 lines in 4 files changed: 11 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/893.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/893/head:pull/893

PR: https://git.openjdk.java.net/jdk/pull/893

From jlaskey at openjdk.java.net  Thu Dec 24 03:08:01 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 24 Dec 2020 03:08:01 GMT
Subject: [jdk16] RFR: JDK-8258916: javac/doclint reports broken HTML on
 multiline mailto links
In-Reply-To: <8D7rBvR2PWIrPXSnfv1wxmUoilT3MOVUgvqFcHHYnVQ=.21b6765e-1368-46f8-a2e9-7c41d6d121ea@github.com>
References: <8D7rBvR2PWIrPXSnfv1wxmUoilT3MOVUgvqFcHHYnVQ=.21b6765e-1368-46f8-a2e9-7c41d6d121ea@github.com>
Message-ID: <o361GH3BXj8lXnhEoq5OZh8eyYcZaRu9zK27CSOiOYA=.129835fc-73d1-4da5-a549-261718707c0c@github.com>

On Thu, 24 Dec 2020 02:04:06 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial fix to correctly handle '@' inside the value of an HTML attribute. 
> The fix is simply to cancel the `newline` flag that is set when a newline has been read.

Marked as reviewed by jlaskey (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk16/pull/68

From iris at openjdk.java.net  Thu Dec 24 03:16:59 2020
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 24 Dec 2020 03:16:59 GMT
Subject: [jdk16] RFR: JDK-8258916: javac/doclint reports broken HTML on
 multiline mailto links
In-Reply-To: <8D7rBvR2PWIrPXSnfv1wxmUoilT3MOVUgvqFcHHYnVQ=.21b6765e-1368-46f8-a2e9-7c41d6d121ea@github.com>
References: <8D7rBvR2PWIrPXSnfv1wxmUoilT3MOVUgvqFcHHYnVQ=.21b6765e-1368-46f8-a2e9-7c41d6d121ea@github.com>
Message-ID: <m07Dt6o8Kxxg8LjWWo0fp4q63sJ3CbxX-CQvVtQALrs=.cc3a1144-6339-45c3-a022-2322533dfc75@github.com>

On Thu, 24 Dec 2020 02:04:06 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial fix to correctly handle '@' inside the value of an HTML attribute. 
> The fix is simply to cancel the `newline` flag that is set when a newline has been read.

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk16/pull/68

From jjg at openjdk.java.net  Thu Dec 24 04:53:02 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 24 Dec 2020 04:53:02 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v6]
In-Reply-To: <iAxu3KnauDOTBgSQCyVQoI8PZXWJC96g-CTZQCD8dU8=.be3b7775-1a43-42ed-87cc-6471ff5baa13@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <iAxu3KnauDOTBgSQCyVQoI8PZXWJC96g-CTZQCD8dU8=.be3b7775-1a43-42ed-87cc-6471ff5baa13@github.com>
Message-ID: <5hMtvUeQgEc5mk5_Fcb3vahTxPIviTG5pbDD_J0f1ec=.5fbd685c-606e-44e4-843d-449418c1a950@github.com>

On Thu, 24 Dec 2020 02:54:17 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> HTML4 is no longer supported in javadoc.
>> 
>> doclint needs to drop HTML4 support as well.
>> The changes consist of:
>> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
>> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
>> * Modifying test code and expected outputs to be checked in HTML5
>
> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   7th: Some fixes and additional changes for 8247957

Marked as reviewed by jjg (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/893

From jjg at openjdk.java.net  Thu Dec 24 04:55:59 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 24 Dec 2020 04:55:59 GMT
Subject: [jdk16] Integrated: JDK-8258916: javac/doclint reports broken HTML on
 multiline mailto links
In-Reply-To: <8D7rBvR2PWIrPXSnfv1wxmUoilT3MOVUgvqFcHHYnVQ=.21b6765e-1368-46f8-a2e9-7c41d6d121ea@github.com>
References: <8D7rBvR2PWIrPXSnfv1wxmUoilT3MOVUgvqFcHHYnVQ=.21b6765e-1368-46f8-a2e9-7c41d6d121ea@github.com>
Message-ID: <uY-9392fMGz1hqhmc-m3jtKLaIGbyG-Mvwony4QyKBg=.83c2dbd9-38bc-4289-b7d0-a0ca9d2a7271@github.com>

On Thu, 24 Dec 2020 02:04:06 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial fix to correctly handle '@' inside the value of an HTML attribute. 
> The fix is simply to cancel the `newline` flag that is set when a newline has been read.

This pull request has now been integrated.

Changeset: c398a828
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/c398a828
Stats:     8 lines in 2 files changed: 7 ins; 0 del; 1 mod

8258916: javac/doclint reports broken HTML on multiline mailto links

Reviewed-by: jlaskey, iris

-------------

PR: https://git.openjdk.java.net/jdk16/pull/68

From jwilhelm at openjdk.java.net  Thu Dec 24 07:28:59 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 24 Dec 2020 07:28:59 GMT
Subject: RFR: Merge jdk16
Message-ID: <wQSFlx_IyhencApL5ww2nZ2agMkrsK6uGcvb_HG-L6Q=.c051fae7-49c9-4152-9ed0-b08e595140fa@github.com>

Forwardport JDK 16 -> JDK 17

-------------

Commit messages:
 - Merge
 - 8258916: javac/doclint reports broken HTML on multiline mailto links
 - 8253954: javac crash when compiling code with enhanced switch expressions with option -Xjcov
 - 8257468: runtime/whitebox/TestWBDeflateIdleMonitors.java fails with Monitor should be deflated.: expected true to equal false
 - 8257521: runtime/logging/MonitorInflationTest.java crashed in MonitorList::unlink_deflated

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/1887/files
  Stats: 74 lines in 6 files changed: 68 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1887.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1887/head:pull/1887

PR: https://git.openjdk.java.net/jdk/pull/1887

From jwilhelm at openjdk.java.net  Thu Dec 24 08:32:43 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 24 Dec 2020 08:32:43 GMT
Subject: RFR: Merge jdk16 [v2]
In-Reply-To: <wQSFlx_IyhencApL5ww2nZ2agMkrsK6uGcvb_HG-L6Q=.c051fae7-49c9-4152-9ed0-b08e595140fa@github.com>
References: <wQSFlx_IyhencApL5ww2nZ2agMkrsK6uGcvb_HG-L6Q=.c051fae7-49c9-4152-9ed0-b08e595140fa@github.com>
Message-ID: <IMm6CSwqmNfAdSoHS8Nl-ZRAc8FKox4njPwLtkLvJj4=.f49d028e-21bf-4c74-a560-9d85c9a3b97e@github.com>

> Forwardport JDK 16 -> JDK 17

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 123 commits:

 - Merge
 - 8258913: ProblemList javax/swing/JComboBox/6559152/bug6559152.java on Linux-X64
   
   Reviewed-by: prr
 - 8258856: VM build without C1/C2 fails after JDK-8243205
   
   Reviewed-by: jiefu, kvn
 - 8258851: Mismatch in SunPKCS11 provider registration properties and actual implementation
   
   Reviewed-by: weijun
 - 8258839: Remove JVM option ExitVMOnVerifyError
   
   Reviewed-by: iignatyev, dcubed, coleenp
 - 8258186: Replace use of JNI_COMMIT mode with mode 0
   
   Reviewed-by: xuelei, alanb
 - 8258911: ProblemList serviceability/attach/RemovingUnixDomainSocketTest.java on Linux-X64
   
   Reviewed-by: amenkov
 - 8258557: Deproblemlist fixed problemlisted test
   
   Reviewed-by: trebari, serb
 - 8258837: Remove JVM option DisableStartThread
   
   Reviewed-by: kbarrett, dcubed
 - 8253368: TLS connection always receives close_notify exception
   
   Reviewed-by: xuelei
 - ... and 113 more: https://git.openjdk.java.net/jdk/compare/c398a828...f32ccfaa

-------------

Changes: https://git.openjdk.java.net/jdk/pull/1887/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1887&range=01
  Stats: 23854 lines in 636 files changed: 18445 ins; 3271 del; 2138 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1887.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1887/head:pull/1887

PR: https://git.openjdk.java.net/jdk/pull/1887

From jwilhelm at openjdk.java.net  Thu Dec 24 08:32:44 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 24 Dec 2020 08:32:44 GMT
Subject: Integrated: Merge jdk16
In-Reply-To: <wQSFlx_IyhencApL5ww2nZ2agMkrsK6uGcvb_HG-L6Q=.c051fae7-49c9-4152-9ed0-b08e595140fa@github.com>
References: <wQSFlx_IyhencApL5ww2nZ2agMkrsK6uGcvb_HG-L6Q=.c051fae7-49c9-4152-9ed0-b08e595140fa@github.com>
Message-ID: <eNUUbu2_78dpB_izL6f5sxGpERcVpUa54Q1T0OTxfjE=.4594ede1-60b2-40f3-a48a-517fbdb3989e@github.com>

On Thu, 24 Dec 2020 07:23:41 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: 57217b58
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/57217b58
Stats:     74 lines in 6 files changed: 68 ins; 0 del; 6 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/1887

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Dec 24 16:07:08 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 24 Dec 2020 16:07:08 GMT
Subject: RFR: 8226216: parameter modifiers are not visible to javac plugins
 across compilation boundaries
Message-ID: <LMhW8s79WUigTic7qfv9KTCI09Hmkvyn5KVvVgN2_T0=.066483bf-d0a4-40ea-a13e-fb9c7680197f@github.com>

Hi all,

javac fails to read modifiers from the MethodParameters attribute in class files, which prevents plugins from accessing those modifiers across compilation boundaries. Because `com.sun.tools.javac.jvm.ClassReader` doesn't read and store the access flags(modifiers) from MethodParameters attribute.

This patch fixes it and adds a corresponding test case. All the existing tests of javac passed locally.

Thank you for taking the time to review.

Best Regards.

-------------

Commit messages:
 - 8226216: parameter modifiers are not visible to javac plugins across compilation boundaries

Changes: https://git.openjdk.java.net/jdk/pull/1890/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1890&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8226216
  Stats: 172 lines in 2 files changed: 171 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1890.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1890/head:pull/1890

PR: https://git.openjdk.java.net/jdk/pull/1890

From jjg at openjdk.java.net  Thu Dec 24 16:25:59 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 24 Dec 2020 16:25:59 GMT
Subject: RFR: 8226216: parameter modifiers are not visible to javac
 plugins across compilation boundaries
In-Reply-To: <LMhW8s79WUigTic7qfv9KTCI09Hmkvyn5KVvVgN2_T0=.066483bf-d0a4-40ea-a13e-fb9c7680197f@github.com>
References: <LMhW8s79WUigTic7qfv9KTCI09Hmkvyn5KVvVgN2_T0=.066483bf-d0a4-40ea-a13e-fb9c7680197f@github.com>
Message-ID: <XxC4RQc9moAbiN4k1HLW8kKjRMqOH2bHV8dz-cvKhPo=.b874c308-a2f7-4e29-8545-1d35bc299f92@github.com>

On Thu, 24 Dec 2020 16:02:19 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> javac fails to read modifiers from the MethodParameters attribute in class files, which prevents plugins from accessing those modifiers across compilation boundaries. Because `com.sun.tools.javac.jvm.ClassReader` doesn't read and store the access flags(modifiers) from MethodParameters attribute.
> 
> This patch fixes it and adds a corresponding test case. All the existing tests of javac passed locally.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

I've noted a couple of minor issues in the test.
I'll leave it to other javac folk to decide the merits of the change to `ClassReader`.
Note that the `MethodParameters` attribute may not always be present.

test/langtools/tools/javac/classreader/8226216/T8226216.java line 9:

> 7:  * published by the Free Software Foundation.  Oracle designates this
> 8:  * particular file as subject to the "Classpath" exception as provided
> 9:  * by Oracle in the LICENSE file that accompanied this code.

Tests should not contain the text `Oracle designates ... this code.` or the immediately preceding whitespace.

test/langtools/tools/javac/classreader/8226216/T8226216.java line 123:

> 121: 
> 122:     @Test
> 123:     public void testParameterModifiersNotVisiable() throws Exception {

spelling: should be "Visible"

-------------

Changes requested by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1890

From jjg at openjdk.java.net  Thu Dec 24 17:31:08 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 24 Dec 2020 17:31:08 GMT
Subject: [jdk16] RFR: JDK-8258941: Test specify the Classpath exception in the
 header
Message-ID: <-U1HUnApFI_DzWAPrcIHhKyB4GVTGKSWYRkYM6UaC78=.5b0cb719-0241-4bcc-a61f-493ba9e6962b@github.com>

Fix up legal headers.
One header is replaced by `/nodynamiccopyright/` because changing the length of the header affects the line numbers in a golden file.

-------------

Commit messages:
 - JDK-8258941: Test specify the Classpath exception in the header

Changes: https://git.openjdk.java.net/jdk16/pull/69/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=69&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258941
  Stats: 41 lines in 7 files changed: 0 ins; 33 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/69.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/69/head:pull/69

PR: https://git.openjdk.java.net/jdk16/pull/69

From jjg at openjdk.java.net  Thu Dec 24 17:36:00 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Thu, 24 Dec 2020 17:36:00 GMT
Subject: [jdk16] Integrated: JDK-8258941: Test specify the Classpath exception
 in the header
In-Reply-To: <-U1HUnApFI_DzWAPrcIHhKyB4GVTGKSWYRkYM6UaC78=.5b0cb719-0241-4bcc-a61f-493ba9e6962b@github.com>
References: <-U1HUnApFI_DzWAPrcIHhKyB4GVTGKSWYRkYM6UaC78=.5b0cb719-0241-4bcc-a61f-493ba9e6962b@github.com>
Message-ID: <hwcGmRlC8E7C7scp-7sqybiCRyACzgdCv7uBoBcX9BQ=.06b2660e-6993-4a38-9d27-2fa107052f98@github.com>

On Thu, 24 Dec 2020 17:26:09 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Fix up legal headers.
> One header is replaced by `/nodynamiccopyright/` because changing the length of the header affects the line numbers in a golden file.

This pull request has now been integrated.

Changeset: e2aa724a
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/e2aa724a
Stats:     41 lines in 7 files changed: 0 ins; 33 del; 8 mod

8258941: Test specify the Classpath exception in the header

Reviewed-by: vromero

-------------

PR: https://git.openjdk.java.net/jdk16/pull/69

From vromero at openjdk.java.net  Thu Dec 24 17:36:00 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 24 Dec 2020 17:36:00 GMT
Subject: [jdk16] RFR: JDK-8258941: Test specify the Classpath exception in
 the header
In-Reply-To: <-U1HUnApFI_DzWAPrcIHhKyB4GVTGKSWYRkYM6UaC78=.5b0cb719-0241-4bcc-a61f-493ba9e6962b@github.com>
References: <-U1HUnApFI_DzWAPrcIHhKyB4GVTGKSWYRkYM6UaC78=.5b0cb719-0241-4bcc-a61f-493ba9e6962b@github.com>
Message-ID: <nzGYckHgIzKsKtPL0AK7c_P5GVP2uyUGTlPrjKWWdVc=.24371b43-e906-4b40-a411-bfb5cc4a30a4@github.com>

On Thu, 24 Dec 2020 17:26:09 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Fix up legal headers.
> One header is replaced by `/nodynamiccopyright/` because changing the length of the header affects the line numbers in a golden file.

looks good

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/69

From vromero at openjdk.java.net  Thu Dec 24 20:28:56 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 24 Dec 2020 20:28:56 GMT
Subject: [jdk16] RFR: 8258662: JDK 17ea: Crash compiling instanceof check
 involving sealed interface
In-Reply-To: <MFzZOJ-kez-q_glvfq4TDsFyLs2dTP8PpoxdfnygmCE=.fa3a8634-850d-4eae-a33b-92b3715a7bcb@github.com>
References: <MFzZOJ-kez-q_glvfq4TDsFyLs2dTP8PpoxdfnygmCE=.fa3a8634-850d-4eae-a33b-92b3715a7bcb@github.com>
Message-ID: <eGvT4tWyTlAp_bUEhWX4bP-c98_yFLQlGR3vhZkvElQ=.cca3aadb-411b-4934-b82e-82aa947e9c78@github.com>

On Wed, 23 Dec 2020 05:10:59 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> The method `Types.isCastable` uses method `Types.areDisjoint` to do some check. But `Types.isCastable` doesn't check the type of the parameter before invoking method `Types.areDisjoint`. This patch adds the corresponding check and add a test case.
> 
> The original patch is in https://github.com/openjdk/jdk/pull/1849.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

looks good

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.java.net/jdk16/pull/63

From ysatowse at openjdk.java.net  Fri Dec 25 02:17:16 2020
From: ysatowse at openjdk.java.net (Yoshiki Sato)
Date: Fri, 25 Dec 2020 02:17:16 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v7]
In-Reply-To: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
Message-ID: <LzK41S5KU-_RAey_VEUY36M38mCNpTaUyTyAQGFyy_k=.bd57bd4b-edf0-465e-987a-bc8b96b5bf5f@github.com>

> HTML4 is no longer supported in javadoc.
> 
> doclint needs to drop HTML4 support as well.
> The changes consist of:
> * Removing -Xhtmlversion option from doclint and --doclint-format from javac.
> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
> * Updating makefile not to use removed option.
> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
> * Fixing incorrect value checks for the id attribute.
> * Modifying test code and expected outputs to be checked in HTML5

Yoshiki Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge master
 - 7th: Some fixes and additional changes for 8247957
 - 5th: 8258460: Remove --doclint-format option from javac
 - 5th: 8257204 and 8256313
   8257204: Remove usage of -Xhtmlversion option from javac
   8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option
 - 8257204 and 8256313
   8257204: Remove usage of -Xhtmlversion option from javac
   8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option
 - 3rd: 8247957 and 8256312
 - Merge branch 'master' into JDK-8247957_2
 - 8247957: remove doclint support for HTML 4
   8256312: Valid anchor 'id' value not allowed
 - 8247957: remove doclint support for HTML 4

-------------

Changes: https://git.openjdk.java.net/jdk/pull/893/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=893&range=06
  Stats: 1499 lines in 60 files changed: 411 ins; 808 del; 280 mod
  Patch: https://git.openjdk.java.net/jdk/pull/893.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/893/head:pull/893

PR: https://git.openjdk.java.net/jdk/pull/893

From jjg at openjdk.java.net  Fri Dec 25 02:24:03 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 25 Dec 2020 02:24:03 GMT
Subject: RFR: 8247957: remove doclint support for HTML 4 [v7]
In-Reply-To: <LzK41S5KU-_RAey_VEUY36M38mCNpTaUyTyAQGFyy_k=.bd57bd4b-edf0-465e-987a-bc8b96b5bf5f@github.com>
References: <vlbJ-zrZsNQGcUxAM9Z76lcpLj2QeNnlyZnjBQJTF3U=.82e5e47e-5db1-4a4f-8ca0-48009fbda71d@github.com>
 <LzK41S5KU-_RAey_VEUY36M38mCNpTaUyTyAQGFyy_k=.bd57bd4b-edf0-465e-987a-bc8b96b5bf5f@github.com>
Message-ID: <qaq5n4TG873EONYE468-sVM_oq8AibEpWT1haNhmIOM=.cf3d7c3b-2510-4c67-8fbf-3d90031b54cc@github.com>

On Fri, 25 Dec 2020 02:17:16 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> HTML4 is no longer supported in javadoc.
>> 
>> doclint needs to drop HTML4 support as well.
>> The changes consist of:
>> * Removing -Xhtmlversion option from doclint and --doclint-format from javac.
>> * Removing jdk.javadoc.internal.doclint.HtmlVersion and its references.
>> * Updating makefile not to use removed option.
>> * Sorting out supported tags and attributes in HTML5 (including fix incorrect permission of valign in TH, TR, TD, THEAD and TBODY)
>> * Fixing incorrect value checks for the id attribute.
>> * Modifying test code and expected outputs to be checked in HTML5
>
> Yoshiki Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge master
>  - 7th: Some fixes and additional changes for 8247957
>  - 5th: 8258460: Remove --doclint-format option from javac
>  - 5th: 8257204 and 8256313
>    8257204: Remove usage of -Xhtmlversion option from javac
>    8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option
>  - 8257204 and 8256313
>    8257204: Remove usage of -Xhtmlversion option from javac
>    8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option
>  - 3rd: 8247957 and 8256312
>  - Merge branch 'master' into JDK-8247957_2
>  - 8247957: remove doclint support for HTML 4
>    8256312: Valid anchor 'id' value not allowed
>  - 8247957: remove doclint support for HTML 4

Marked as reviewed by jjg (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/893

From github.com+13688759+lgxbslgx at openjdk.java.net  Fri Dec 25 07:18:18 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Fri, 25 Dec 2020 07:18:18 GMT
Subject: [jdk16] RFR: 8258662: JDK 17ea: Crash compiling instanceof check
 involving sealed interface [v2]
In-Reply-To: <MFzZOJ-kez-q_glvfq4TDsFyLs2dTP8PpoxdfnygmCE=.fa3a8634-850d-4eae-a33b-92b3715a7bcb@github.com>
References: <MFzZOJ-kez-q_glvfq4TDsFyLs2dTP8PpoxdfnygmCE=.fa3a8634-850d-4eae-a33b-92b3715a7bcb@github.com>
Message-ID: <e6THbaC73UzylavhaWymG27Qgsw0bfygxsm7_VJBlpc=.77f9face-5504-4be9-ad64-5776327618be@github.com>

> Hi all,
> 
> The method `Types.isCastable` uses method `Types.areDisjoint` to do some check. But `Types.isCastable` doesn't check the type of the parameter before invoking method `Types.areDisjoint`. This patch adds the corresponding check and add a test case.
> 
> The original patch is in https://github.com/openjdk/jdk/pull/1849.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Modify legal header.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk16/pull/63/files
  - new: https://git.openjdk.java.net/jdk16/pull/63/files/4b07c7bc..1dec0e3c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk16&pr=63&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk16&pr=63&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/63.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/63/head:pull/63

PR: https://git.openjdk.java.net/jdk16/pull/63

From github.com+13688759+lgxbslgx at openjdk.java.net  Fri Dec 25 07:25:14 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Fri, 25 Dec 2020 07:25:14 GMT
Subject: RFR: 8226216: parameter modifiers are not visible to javac
 plugins across compilation boundaries [v2]
In-Reply-To: <LMhW8s79WUigTic7qfv9KTCI09Hmkvyn5KVvVgN2_T0=.066483bf-d0a4-40ea-a13e-fb9c7680197f@github.com>
References: <LMhW8s79WUigTic7qfv9KTCI09Hmkvyn5KVvVgN2_T0=.066483bf-d0a4-40ea-a13e-fb9c7680197f@github.com>
Message-ID: <eBJbUFdHMxo4y_DgikyoUfLlOLqyqC5zkcwDSxzNe9E=.3e72c7ad-81e4-4929-90cc-15866ffb9b94@github.com>

> Hi all,
> 
> javac fails to read modifiers from the MethodParameters attribute in class files, which prevents plugins from accessing those modifiers across compilation boundaries. Because `com.sun.tools.javac.jvm.ClassReader` doesn't read and store the access flags(modifiers) from MethodParameters attribute.
> 
> This patch fixes it and adds a corresponding test case. All the existing tests of javac passed locally.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Modify legal header. Fix typo.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1890/files
  - new: https://git.openjdk.java.net/jdk/pull/1890/files/f064d8e8..a074937f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1890&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1890&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1890.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1890/head:pull/1890

PR: https://git.openjdk.java.net/jdk/pull/1890

From github.com+13688759+lgxbslgx at openjdk.java.net  Fri Dec 25 07:30:13 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Fri, 25 Dec 2020 07:30:13 GMT
Subject: RFR: 8225003: NPE in Attr.attribIdentAsEnumType [v2]
In-Reply-To: <PHN_VIHKRaTUTixtxee-2V0k__M7bC5ssjqUNupGPps=.b638e98b-1da4-4490-b033-d8874feed79a@github.com>
References: <PHN_VIHKRaTUTixtxee-2V0k__M7bC5ssjqUNupGPps=.b638e98b-1da4-4490-b033-d8874feed79a@github.com>
Message-ID: <Aupuv3lY0D5kC21tEZ1tFHIZHRQJP7mAIwpAvrfbbXE=.d4e6a1c6-3a80-4b73-b414-17c6e986ac65@github.com>

> Hi all,
> 
> `Attr.attribIdentAsEnumType` uses `enclClass` which would return null if some error types and/or error symbols exist.
> 
> And if we use annotation processor, some errors would be reported to `deferredDiagnosticHandler` and not immediately reported to the users. At this time, the `NullPointerException`(NPE) occurs and all the other work, including that the `deferredDiagnosticHandler` report the errors to users, would not be done. So the user would see the NPE and see that the compiler crashes.
> 
> In other words, the NPE also occurs without the annotation processor. But because the `deferredDiagnosticHandler` is not set without the annotation processor, some other errors would be shown immediately to users and the NPE is not shown when using [these catch code](https://github.com/openjdk/jdk/blob/0849117d5c3a9ae12231262fc0d3366a6e8a458d/src/jdk.compiler/share/classes/com/sun/tools/javac/main/Main.java#L349).
> 
> This patch fixes the NPE and reports the deferred diagnostics to users at the end of the compilation task. Maybe you can consider that this patch solves two bugs:
> 
> 1. [JDK-8225003 NPE in Attr.attribIdentAsEnumType](https://bugs.openjdk.java.net/browse/JDK-8225003)
> 2. Some deferred diagnostics would be not reported to user when the compiler crashes.
> 
> The test case needs to fix these two bugs to pass, so I put them together.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Modify legal header.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1864/files
  - new: https://git.openjdk.java.net/jdk/pull/1864/files/9c3a3d0a..4b085238

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1864&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1864&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1864.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1864/head:pull/1864

PR: https://git.openjdk.java.net/jdk/pull/1864

From github.com+13688759+lgxbslgx at openjdk.java.net  Fri Dec 25 08:24:57 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Fri, 25 Dec 2020 08:24:57 GMT
Subject: RFR: 8226216: parameter modifiers are not visible to javac
 plugins across compilation boundaries [v2]
In-Reply-To: <XxC4RQc9moAbiN4k1HLW8kKjRMqOH2bHV8dz-cvKhPo=.b874c308-a2f7-4e29-8545-1d35bc299f92@github.com>
References: <LMhW8s79WUigTic7qfv9KTCI09Hmkvyn5KVvVgN2_T0=.066483bf-d0a4-40ea-a13e-fb9c7680197f@github.com>
 <XxC4RQc9moAbiN4k1HLW8kKjRMqOH2bHV8dz-cvKhPo=.b874c308-a2f7-4e29-8545-1d35bc299f92@github.com>
Message-ID: <AN9yYslknR8saL9b30SyO7WtjCi7ZM_PDGHpqyO6-30=.b0f8badb-7deb-4ddc-9894-34fe4a426665@github.com>

On Thu, 24 Dec 2020 16:18:55 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Modify legal header. Fix typo.
>
> test/langtools/tools/javac/classreader/8226216/T8226216.java line 9:
> 
>> 7:  * published by the Free Software Foundation.  Oracle designates this
>> 8:  * particular file as subject to the "Classpath" exception as provided
>> 9:  * by Oracle in the LICENSE file that accompanied this code.
> 
> Tests should not contain the text `Oracle designates ... this code.` or the immediately preceding whitespace.

Fixed.

> test/langtools/tools/javac/classreader/8226216/T8226216.java line 123:
> 
>> 121: 
>> 122:     @Test
>> 123:     public void testParameterModifiersNotVisiable() throws Exception {
> 
> spelling: should be "Visible"

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1890

From github.com+13688759+lgxbslgx at openjdk.java.net  Fri Dec 25 16:27:07 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Fri, 25 Dec 2020 16:27:07 GMT
Subject: RFR: 8216400: improve handling of IOExceptions in JavaCompiler.close()
Message-ID: <4Fjw1q-olNMDFLskC2G91WNch4FsD6SN5FzcJKh-NNE=.8caa1ba6-6349-477c-acac-14aac3b7ce7d@github.com>

Hi all,

This little patch enhances the code according to the comment by using a simplest way. I found [JDK-8069116](https://bugs.openjdk.java.net/browse/JDK-8069116) is a similar issue. A better way would be appreciated.

Thank you for taking the time to reivew.

Best Regards.

-------------

Commit messages:
 - 8216400: improve handling of IOExceptions in JavaCompiler.close()

Changes: https://git.openjdk.java.net/jdk/pull/1895/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1895&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8216400
  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1895.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1895/head:pull/1895

PR: https://git.openjdk.java.net/jdk/pull/1895

From github.com+13688759+lgxbslgx at openjdk.java.net  Fri Dec 25 16:32:01 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Fri, 25 Dec 2020 16:32:01 GMT
Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility
Message-ID: <wd62mmsecdHYCNEAhc-2qsTSRJy0v7QA70Dl4-hXKQA=.a3cc5eba-97ed-4b75-b004-e394edfeb98b@github.com>

Hi all,

This little patch enhances the setting of `Log` in `JavacTool.getTask`.

Thank you for taking the time to review.

Best Regards.

-------------

Commit messages:
 - 8198317: Enhance JavacTool.getTask for flexibility

Changes: https://git.openjdk.java.net/jdk/pull/1896/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1896&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8198317
  Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1896.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1896/head:pull/1896

PR: https://git.openjdk.java.net/jdk/pull/1896

From github.com+13688759+lgxbslgx at openjdk.java.net  Fri Dec 25 16:40:58 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Fri, 25 Dec 2020 16:40:58 GMT
Subject: [jdk16] RFR: 8258662: JDK 17ea: Crash compiling instanceof check
 involving sealed interface [v2]
In-Reply-To: <eGvT4tWyTlAp_bUEhWX4bP-c98_yFLQlGR3vhZkvElQ=.cca3aadb-411b-4934-b82e-82aa947e9c78@github.com>
References: <MFzZOJ-kez-q_glvfq4TDsFyLs2dTP8PpoxdfnygmCE=.fa3a8634-850d-4eae-a33b-92b3715a7bcb@github.com>
 <eGvT4tWyTlAp_bUEhWX4bP-c98_yFLQlGR3vhZkvElQ=.cca3aadb-411b-4934-b82e-82aa947e9c78@github.com>
Message-ID: <71PqQdw4RZAVVt5WlnEuSGW-pZAYIY7ZO0Jqz8aXInc=.40899596-955c-4f68-9cee-bf21cd028b86@github.com>

On Thu, 24 Dec 2020 20:25:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Modify legal header.
>
> looks good

@vicente-romero-oracle I revised the legal header. Thank you for taking the time to review.

-------------

PR: https://git.openjdk.java.net/jdk16/pull/63

From jjg at openjdk.java.net  Fri Dec 25 20:53:58 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 25 Dec 2020 20:53:58 GMT
Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility
In-Reply-To: <wd62mmsecdHYCNEAhc-2qsTSRJy0v7QA70Dl4-hXKQA=.a3cc5eba-97ed-4b75-b004-e394edfeb98b@github.com>
References: <wd62mmsecdHYCNEAhc-2qsTSRJy0v7QA70Dl4-hXKQA=.a3cc5eba-97ed-4b75-b004-e394edfeb98b@github.com>
Message-ID: <JMq94r5dMs_4ybB798-GKjiMm20R4TOy4Z3apeCiGpU=.6d8ceb52-6a27-4255-ad6e-b04699d1fb64@github.com>

On Fri, 25 Dec 2020 16:26:39 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> This little patch enhances the setting of `Log` in `JavacTool.getTask`.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

As a general rule, all changes should have an accompanying regression test, unless there is a good reason why not.   The set of good reasons has a corresponding list of JBS labels, shown here: http://openjdk.java.net/guide/#noreg

The closest match here would be `noreg-trivial` but I don't think it is close enough to claim that. In other words, I think this change needs a corresponding new test.  It is also not uncommon for small changes like this to more effort to write the test than fixing the underlying issue.

--

* *Unit test*: insurance against having to writing a regression test later on
* *Regression test*: the penalty for not writing a unit test in the first place

-------------

Changes requested by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1896

From jjg at openjdk.java.net  Fri Dec 25 23:45:55 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 25 Dec 2020 23:45:55 GMT
Subject: RFR: 8216400: improve handling of IOExceptions in
 JavaCompiler.close()
In-Reply-To: <4Fjw1q-olNMDFLskC2G91WNch4FsD6SN5FzcJKh-NNE=.8caa1ba6-6349-477c-acac-14aac3b7ce7d@github.com>
References: <4Fjw1q-olNMDFLskC2G91WNch4FsD6SN5FzcJKh-NNE=.8caa1ba6-6349-477c-acac-14aac3b7ce7d@github.com>
Message-ID: <W6-aF6SYrcsMEMZGQejKez3m7rs411XGP-OH2K1tgtw=.846e0333-7692-46b9-9e08-ce0778abb951@github.com>

On Fri, 25 Dec 2020 16:22:22 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> This little patch enhances the code according to the comment by using a simplest way. I found [JDK-8069116](https://bugs.openjdk.java.net/browse/JDK-8069116) is a similar issue. A better way would be appreciated.
> 
> Thank you for taking the time to reivew.
> 
> Best Regards.

Changes requested by jjg (Reviewer).

src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java line 1825:

> 1823:                     JCDiagnostic msg = diagFactory.fragment(Fragments.FatalErrCantClose);
> 1824:                     throw new FatalError(msg, e);
> 1825:                 }

The comment is meant to suggest the following:

`
FatalError fe = null;
for (Closable c : closeables) {
    try {
        c.close();
    } catch (IOException e) {
        if (fe == null) {
            JCDiagnostic msg = diagFactory.fragment(Fragments.FatalErrCantClose);
            fe = new FatalError(msg, e):
        } else {
            fe.addSuppressed(e);
        }
    }
}
if (fe != null) {
    throw fe;
}
`

(Apologies if there are any errors in that: I just typed it in directly.)


This is probably a case where you could probably get away with no test and use the label `norge-hard`.  If you were to write a test, it would have to involve creating multiple file system artifacts that cannot be closed, perhaps by creating wrappers that always throw exceptions when `close()` is called.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1895

From github.com+13688759+lgxbslgx at openjdk.java.net  Sat Dec 26 08:26:54 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sat, 26 Dec 2020 08:26:54 GMT
Subject: RFR: 8216400: improve handling of IOExceptions in
 JavaCompiler.close()
In-Reply-To: <W6-aF6SYrcsMEMZGQejKez3m7rs411XGP-OH2K1tgtw=.846e0333-7692-46b9-9e08-ce0778abb951@github.com>
References: <4Fjw1q-olNMDFLskC2G91WNch4FsD6SN5FzcJKh-NNE=.8caa1ba6-6349-477c-acac-14aac3b7ce7d@github.com>
 <W6-aF6SYrcsMEMZGQejKez3m7rs411XGP-OH2K1tgtw=.846e0333-7692-46b9-9e08-ce0778abb951@github.com>
Message-ID: <feDD6RPR4aFANYcJQhRIyefP8bQ6Hc28-x7yNh-K0IE=.85f417ae-ab6b-4e1c-b283-7f20f86cfe62@github.com>

On Fri, 25 Dec 2020 23:41:36 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Hi all,
>> 
>> This little patch enhances the code according to the comment by using a simplest way. I found [JDK-8069116](https://bugs.openjdk.java.net/browse/JDK-8069116) is a similar issue. A better way would be appreciated.
>> 
>> Thank you for taking the time to reivew.
>> 
>> Best Regards.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/main/JavaCompiler.java line 1825:
> 
>> 1823:                     JCDiagnostic msg = diagFactory.fragment(Fragments.FatalErrCantClose);
>> 1824:                     throw new FatalError(msg, e);
>> 1825:                 }
> 
> The comment is meant to suggest the following:
> 
> `
> FatalError fe = null;
> for (Closable c : closeables) {
>     try {
>         c.close();
>     } catch (IOException e) {
>         if (fe == null) {
>             JCDiagnostic msg = diagFactory.fragment(Fragments.FatalErrCantClose);
>             fe = new FatalError(msg, e):
>         } else {
>             fe.addSuppressed(e);
>         }
>     }
> }
> if (fe != null) {
>     throw fe;
> }
> `
> 
> (Apologies if there are any errors in that: I just typed it in directly.)
> 
> 
> This is probably a case where you could probably get away with no test and use the label `norge-hard`.  If you were to write a test, it would have to involve creating multiple file system artifacts that cannot be closed, perhaps by creating wrappers that always throw exceptions when `close()` is called.

Oops, I misunderstood the meaning of  `any/all exceptions from all the Closeables`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1895

From github.com+13688759+lgxbslgx at openjdk.java.net  Sat Dec 26 15:46:15 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sat, 26 Dec 2020 15:46:15 GMT
Subject: RFR: 8216400: improve handling of IOExceptions in
 JavaCompiler.close() [v2]
In-Reply-To: <4Fjw1q-olNMDFLskC2G91WNch4FsD6SN5FzcJKh-NNE=.8caa1ba6-6349-477c-acac-14aac3b7ce7d@github.com>
References: <4Fjw1q-olNMDFLskC2G91WNch4FsD6SN5FzcJKh-NNE=.8caa1ba6-6349-477c-acac-14aac3b7ce7d@github.com>
Message-ID: <XH2J7t2M-8kksnNs3ed3B2ZH0xBMowqh2UEnpJhci28=.ba91863e-def5-4bd1-8c89-fa8eb799608e@github.com>

> Hi all,
> 
> This little patch enhances the code according to the comment by using a simplest way. I found [JDK-8069116](https://bugs.openjdk.java.net/browse/JDK-8069116) is a similar issue. A better way would be appreciated.
> 
> Thank you for taking the time to reivew.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision:

 - Add a test case.
 - Set all exceptions from all the Closeables.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1895/files
  - new: https://git.openjdk.java.net/jdk/pull/1895/files/5e844d0c..e19b1a22

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1895&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1895&range=00-01

  Stats: 155 lines in 2 files changed: 152 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1895.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1895/head:pull/1895

PR: https://git.openjdk.java.net/jdk/pull/1895

From jjg at openjdk.java.net  Sat Dec 26 16:01:56 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sat, 26 Dec 2020 16:01:56 GMT
Subject: RFR: 8216400: improve handling of IOExceptions in
 JavaCompiler.close() [v2]
In-Reply-To: <XH2J7t2M-8kksnNs3ed3B2ZH0xBMowqh2UEnpJhci28=.ba91863e-def5-4bd1-8c89-fa8eb799608e@github.com>
References: <4Fjw1q-olNMDFLskC2G91WNch4FsD6SN5FzcJKh-NNE=.8caa1ba6-6349-477c-acac-14aac3b7ce7d@github.com>
 <XH2J7t2M-8kksnNs3ed3B2ZH0xBMowqh2UEnpJhci28=.ba91863e-def5-4bd1-8c89-fa8eb799608e@github.com>
Message-ID: <V9gRDM-_r1zheEUNtI5XoWMekHvuLQyNfZ78sDUTz4w=.621051c1-efb1-464d-af62-9dedc8593d84@github.com>

On Sat, 26 Dec 2020 15:46:15 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi all,
>> 
>> This little patch enhances the code according to the comment by using a simplest way. I found [JDK-8069116](https://bugs.openjdk.java.net/browse/JDK-8069116) is a similar issue. A better way would be appreciated.
>> 
>> Thank you for taking the time to reivew.
>> 
>> Best Regards.
>
> Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add a test case.
>  - Set all exceptions from all the Closeables.

OK. Clever test; well done.
Without the test, I would not personally have approved the work, since I suggested the code. (I would have wanted another set of Reviewer eyes on the suggestion.)
But given the addition of the test to verify the behavior, I think it's OK to go ahead.

test/langtools/tools/javac/fatalErrors/ImproveFatalErrorHandling.java line 87:

> 85:         try {
> 86:             compiler.close();
> 87:         } catch(FatalError fatalError) {

(minor) add space after "catch"

-------------

Marked as reviewed by jjg (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1895

From github.com+13688759+lgxbslgx at openjdk.java.net  Sat Dec 26 16:21:12 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sat, 26 Dec 2020 16:21:12 GMT
Subject: RFR: 8216400: improve handling of IOExceptions in
 JavaCompiler.close() [v3]
In-Reply-To: <4Fjw1q-olNMDFLskC2G91WNch4FsD6SN5FzcJKh-NNE=.8caa1ba6-6349-477c-acac-14aac3b7ce7d@github.com>
References: <4Fjw1q-olNMDFLskC2G91WNch4FsD6SN5FzcJKh-NNE=.8caa1ba6-6349-477c-acac-14aac3b7ce7d@github.com>
Message-ID: <0tw4iK--P1SWIhicA4KNPQJhYunMs8jVzdyKLWeRk9U=.9f863c9b-eca1-4dbd-b301-cc71e83ccf4d@github.com>

> Hi all,
> 
> This little patch enhances the code according to the comment by using a simplest way. I found [JDK-8069116](https://bugs.openjdk.java.net/browse/JDK-8069116) is a similar issue. A better way would be appreciated.
> 
> Thank you for taking the time to reivew.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Polish.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1895/files
  - new: https://git.openjdk.java.net/jdk/pull/1895/files/e19b1a22..ae642c2b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1895&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1895&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1895.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1895/head:pull/1895

PR: https://git.openjdk.java.net/jdk/pull/1895

From github.com+13688759+lgxbslgx at openjdk.java.net  Sat Dec 26 16:21:13 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sat, 26 Dec 2020 16:21:13 GMT
Subject: RFR: 8216400: improve handling of IOExceptions in
 JavaCompiler.close() [v2]
In-Reply-To: <V9gRDM-_r1zheEUNtI5XoWMekHvuLQyNfZ78sDUTz4w=.621051c1-efb1-464d-af62-9dedc8593d84@github.com>
References: <4Fjw1q-olNMDFLskC2G91WNch4FsD6SN5FzcJKh-NNE=.8caa1ba6-6349-477c-acac-14aac3b7ce7d@github.com>
 <XH2J7t2M-8kksnNs3ed3B2ZH0xBMowqh2UEnpJhci28=.ba91863e-def5-4bd1-8c89-fa8eb799608e@github.com>
 <V9gRDM-_r1zheEUNtI5XoWMekHvuLQyNfZ78sDUTz4w=.621051c1-efb1-464d-af62-9dedc8593d84@github.com>
Message-ID: <mgsdbgszL5IP7gmte9fooD7FLmc3MqRFD-8XIwCjtmw=.8d9ba094-8248-4bb8-8420-eefd0ecff39c@github.com>

On Sat, 26 Dec 2020 15:54:33 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add a test case.
>>  - Set all exceptions from all the Closeables.
>
> test/langtools/tools/javac/fatalErrors/ImproveFatalErrorHandling.java line 87:
> 
>> 85:         try {
>> 86:             compiler.close();
>> 87:         } catch(FatalError fatalError) {
> 
> (minor) add space after "catch"

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1895

From jjg at openjdk.java.net  Sat Dec 26 16:30:55 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sat, 26 Dec 2020 16:30:55 GMT
Subject: RFR: 8216400: improve handling of IOExceptions in
 JavaCompiler.close() [v2]
In-Reply-To: <mgsdbgszL5IP7gmte9fooD7FLmc3MqRFD-8XIwCjtmw=.8d9ba094-8248-4bb8-8420-eefd0ecff39c@github.com>
References: <4Fjw1q-olNMDFLskC2G91WNch4FsD6SN5FzcJKh-NNE=.8caa1ba6-6349-477c-acac-14aac3b7ce7d@github.com>
 <XH2J7t2M-8kksnNs3ed3B2ZH0xBMowqh2UEnpJhci28=.ba91863e-def5-4bd1-8c89-fa8eb799608e@github.com>
 <V9gRDM-_r1zheEUNtI5XoWMekHvuLQyNfZ78sDUTz4w=.621051c1-efb1-464d-af62-9dedc8593d84@github.com>
 <mgsdbgszL5IP7gmte9fooD7FLmc3MqRFD-8XIwCjtmw=.8d9ba094-8248-4bb8-8420-eefd0ecff39c@github.com>
Message-ID: <pxZU-a1sOXn9nW2fFvBCcwP6FHMr5N_TYFCJl8TgwG4=.3cfc0395-0248-4220-b638-d898035a3edf@github.com>

On Sat, 26 Dec 2020 16:18:34 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> test/langtools/tools/javac/fatalErrors/ImproveFatalErrorHandling.java line 87:
>> 
>>> 85:         try {
>>> 86:             compiler.close();
>>> 87:         } catch(FatalError fatalError) {
>> 
>> (minor) add space after "catch"
>
> Fixed.

??

-------------

PR: https://git.openjdk.java.net/jdk/pull/1895

From github.com+13688759+lgxbslgx at openjdk.java.net  Sat Dec 26 17:34:18 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sat, 26 Dec 2020 17:34:18 GMT
Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility [v2]
In-Reply-To: <JMq94r5dMs_4ybB798-GKjiMm20R4TOy4Z3apeCiGpU=.6d8ceb52-6a27-4255-ad6e-b04699d1fb64@github.com>
References: <wd62mmsecdHYCNEAhc-2qsTSRJy0v7QA70Dl4-hXKQA=.a3cc5eba-97ed-4b75-b004-e394edfeb98b@github.com>
 <JMq94r5dMs_4ybB798-GKjiMm20R4TOy4Z3apeCiGpU=.6d8ceb52-6a27-4255-ad6e-b04699d1fb64@github.com>
Message-ID: <h4CJfDfLyxgJN4YDY2XjNbORblPDz7tkimMKBnHQEUc=.87e08d7e-eb88-4831-8ccf-066882247789@github.com>

On Fri, 25 Dec 2020 20:51:43 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a test case.
>
> As a general rule, all changes should have an accompanying regression test, unless there is a good reason why not.   The set of good reasons has a corresponding list of JBS labels, shown here: http://openjdk.java.net/guide/#noreg
> 
> The closest match here would be `noreg-trivial` but I don't think it is close enough to claim that. In other words, I think this change needs a corresponding new test.  It is also not uncommon for small changes like this to more effort to write the test than fixing the underlying issue.
> 
> --
> 
> * *Unit test*: insurance against having to writing a regression test later on
> * *Regression test*: the penalty for not writing a unit test in the first place

I submit a test case. But I don't satisfy with it, because it can't meet all the situations.
I try to use the reflect api locally to write a better test. Please see the code below. The code can't be compiled.

    @Test
    public void testLogSettingInJavacTool() throws Exception {
        Class<?> pwClass = Class.forName("java.io.PrintWriter");
        Field psOutField = pwClass.getDeclaredField("psOut");
        psOutField.setAccessible(true);
        Field outField = pwClass.getDeclaredField("out");
        outField.setAccessible(true);

        // Situation: out is null and the value is not set in the context.
        JavacTaskImpl task1 = (JavacTaskImpl) ToolProvider
                .getSystemJavaCompiler()
                .getTask(null, null, null, null, null, null);
        PrintWriter writer1 = task1.getContext().get(Log.errKey);
        PrintStream psOut1 = (PrintStream) psOutField.get(writer1);
        if (!System.err.equals(psOut1)) {
            throw new Error("The PrintWriter is set uncorrectly.");
        }

        // Situation: out is not null and out is a PrintWriter.
        PrintWriter expectedPW = new PrintWriter(System.out);
        JavacTaskImpl task2 = (JavacTaskImpl) ToolProvider
                .getSystemJavaCompiler()
                .getTask(expectedPW, null, null, null, null, null);
        PrintWriter writer2 = task2.getContext().get(Log.errKey);
        PrintStream psOut2 = (PrintStream) psOutField.get(writer2);
        if (!System.out.equals(psOut2) || expectedPW.equals(writer2)) {
            throw new Error("The PrintWriter is set uncorrectly.");
        }

        // Situation: out is not null and out is not a PrintWriter.
        OutputStreamWriter expectedOSW = new OutputStreamWriter(System.out);
        JavacTaskImpl task3 = (JavacTaskImpl) ToolProvider
                .getSystemJavaCompiler()
                .getTask(expectedOSW, null, null, null, null, null);
        PrintWriter writer3 = task3.getContext().get(Log.errKey);
        Writer out3 = (Writer) outField.get(writer3);
        if (!(out3 instanceof OutputStreamWriter) || !expectedOSW.equals(out3)) {
            throw new Error("The PrintWriter is set uncorrectly.");
        }
    }

The error information is shown below.

STDERR:
test: testLogSettingInJavacTool
Exception running test testLogSettingInJavacTool: java.lang.reflect.InaccessibleObjectException: Unable to make field private java.io.PrintStream java.io.PrintWriter.psOut accessible: module java.base does not "opens java.io" to unnamed module @2fd66ad3
java.lang.reflect.InaccessibleObjectException: Unable to make field private java.io.PrintStream java.io.PrintWriter.psOut accessible: module java.base does not "opens java.io" to unnamed module @2fd66ad3
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
	at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:177)
	at java.base/java.lang.reflect.Field.setAccessible(Field.java:171)
	at T8198317.testLogSettingInJavacTool(T8198317.java:63)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
	at toolbox.TestRunner.runTests(TestRunner.java:89)
	at toolbox.TestRunner.runTests(TestRunner.java:73)
	at T8198317.main(T8198317.java:56)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
	at java.base/java.lang.Thread.run(Thread.java:831)

A better test case would be appreciated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1896

From github.com+13688759+lgxbslgx at openjdk.java.net  Sat Dec 26 17:34:18 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sat, 26 Dec 2020 17:34:18 GMT
Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility [v2]
In-Reply-To: <wd62mmsecdHYCNEAhc-2qsTSRJy0v7QA70Dl4-hXKQA=.a3cc5eba-97ed-4b75-b004-e394edfeb98b@github.com>
References: <wd62mmsecdHYCNEAhc-2qsTSRJy0v7QA70Dl4-hXKQA=.a3cc5eba-97ed-4b75-b004-e394edfeb98b@github.com>
Message-ID: <ux1OQB-EVnzZzdTNVKMK9V0UNrykQJDgAJIXm0POuK0=.d9716c25-2851-4f33-85d1-dd47dc241597@github.com>

> Hi all,
> 
> This little patch enhances the setting of `Log` in `JavacTool.getTask`.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Add a test case.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1896/files
  - new: https://git.openjdk.java.net/jdk/pull/1896/files/5ac98f79..f73c4052

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1896&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1896&range=00-01

  Stats: 74 lines in 1 file changed: 74 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1896.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1896/head:pull/1896

PR: https://git.openjdk.java.net/jdk/pull/1896

From github.com+13688759+lgxbslgx at openjdk.java.net  Sat Dec 26 17:35:57 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sat, 26 Dec 2020 17:35:57 GMT
Subject: Integrated: 8216400: improve handling of IOExceptions in
 JavaCompiler.close()
In-Reply-To: <4Fjw1q-olNMDFLskC2G91WNch4FsD6SN5FzcJKh-NNE=.8caa1ba6-6349-477c-acac-14aac3b7ce7d@github.com>
References: <4Fjw1q-olNMDFLskC2G91WNch4FsD6SN5FzcJKh-NNE=.8caa1ba6-6349-477c-acac-14aac3b7ce7d@github.com>
Message-ID: <Rha43f23XbPH6RRAyNX0MyMsdjn-SysZ27f6WQudRZ0=.a64c71b5-bea4-4ef2-a48b-9d20038b5feb@github.com>

On Fri, 25 Dec 2020 16:22:22 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> This little patch enhances the code according to the comment by using a simplest way. I found [JDK-8069116](https://bugs.openjdk.java.net/browse/JDK-8069116) is a similar issue. A better way would be appreciated.
> 
> Thank you for taking the time to reivew.
> 
> Best Regards.

This pull request has now been integrated.

Changeset: 97c99b5d
Author:    Guoxiong Li <lgxbslgx at gmail.com>
Committer: Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/97c99b5d
Stats:     154 lines in 2 files changed: 148 ins; 0 del; 6 mod

8216400: improve handling of IOExceptions in JavaCompiler.close()
8069116: improve fatal error handling in JavaCompiler

Reviewed-by: jjg

-------------

PR: https://git.openjdk.java.net/jdk/pull/1895

From jjg at openjdk.java.net  Sat Dec 26 17:43:55 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sat, 26 Dec 2020 17:43:55 GMT
Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility [v2]
In-Reply-To: <h4CJfDfLyxgJN4YDY2XjNbORblPDz7tkimMKBnHQEUc=.87e08d7e-eb88-4831-8ccf-066882247789@github.com>
References: <wd62mmsecdHYCNEAhc-2qsTSRJy0v7QA70Dl4-hXKQA=.a3cc5eba-97ed-4b75-b004-e394edfeb98b@github.com>
 <JMq94r5dMs_4ybB798-GKjiMm20R4TOy4Z3apeCiGpU=.6d8ceb52-6a27-4255-ad6e-b04699d1fb64@github.com>
 <h4CJfDfLyxgJN4YDY2XjNbORblPDz7tkimMKBnHQEUc=.87e08d7e-eb88-4831-8ccf-066882247789@github.com>
Message-ID: <j3nCc1yFGbA8khiZF02Jlx3O_N5lggvzWFgjXuYvqBE=.cd7e0704-a5bf-4e08-9749-f6dc3b5266dd@github.com>

On Sat, 26 Dec 2020 17:30:58 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> As a general rule, all changes should have an accompanying regression test, unless there is a good reason why not.   The set of good reasons has a corresponding list of JBS labels, shown here: http://openjdk.java.net/guide/#noreg
>> 
>> The closest match here would be `noreg-trivial` but I don't think it is close enough to claim that. In other words, I think this change needs a corresponding new test.  It is also not uncommon for small changes like this to more effort to write the test than fixing the underlying issue.
>> 
>> --
>> 
>> * *Unit test*: insurance against having to writing a regression test later on
>> * *Regression test*: the penalty for not writing a unit test in the first place
>
> I submit a test case. But I don't satisfy with it, because it can't meet all the situations.
> I try to use the reflect api locally to write a better test. Please see the code below. The code can't be compiled.
> 
>     @Test
>     public void testLogSettingInJavacTool() throws Exception {
>         Class<?> pwClass = Class.forName("java.io.PrintWriter");
>         Field psOutField = pwClass.getDeclaredField("psOut");
>         psOutField.setAccessible(true);
>         Field outField = pwClass.getDeclaredField("out");
>         outField.setAccessible(true);
> 
>         // Situation: out is null and the value is not set in the context.
>         JavacTaskImpl task1 = (JavacTaskImpl) ToolProvider
>                 .getSystemJavaCompiler()
>                 .getTask(null, null, null, null, null, null);
>         PrintWriter writer1 = task1.getContext().get(Log.errKey);
>         PrintStream psOut1 = (PrintStream) psOutField.get(writer1);
>         if (!System.err.equals(psOut1)) {
>             throw new Error("The PrintWriter is set uncorrectly.");
>         }
> 
>         // Situation: out is not null and out is a PrintWriter.
>         PrintWriter expectedPW = new PrintWriter(System.out);
>         JavacTaskImpl task2 = (JavacTaskImpl) ToolProvider
>                 .getSystemJavaCompiler()
>                 .getTask(expectedPW, null, null, null, null, null);
>         PrintWriter writer2 = task2.getContext().get(Log.errKey);
>         PrintStream psOut2 = (PrintStream) psOutField.get(writer2);
>         if (!System.out.equals(psOut2) || expectedPW.equals(writer2)) {
>             throw new Error("The PrintWriter is set uncorrectly.");
>         }
> 
>         // Situation: out is not null and out is not a PrintWriter.
>         OutputStreamWriter expectedOSW = new OutputStreamWriter(System.out);
>         JavacTaskImpl task3 = (JavacTaskImpl) ToolProvider
>                 .getSystemJavaCompiler()
>                 .getTask(expectedOSW, null, null, null, null, null);
>         PrintWriter writer3 = task3.getContext().get(Log.errKey);
>         Writer out3 = (Writer) outField.get(writer3);
>         if (!(out3 instanceof OutputStreamWriter) || !expectedOSW.equals(out3)) {
>             throw new Error("The PrintWriter is set uncorrectly.");
>         }
>     }
> 
> The error information is shown below.
> 
> STDERR:
> test: testLogSettingInJavacTool
> Exception running test testLogSettingInJavacTool: java.lang.reflect.InaccessibleObjectException: Unable to make field private java.io.PrintStream java.io.PrintWriter.psOut accessible: module java.base does not "opens java.io" to unnamed module @2fd66ad3
> java.lang.reflect.InaccessibleObjectException: Unable to make field private java.io.PrintStream java.io.PrintWriter.psOut accessible: module java.base does not "opens java.io" to unnamed module @2fd66ad3
> 	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
> 	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> 	at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:177)
> 	at java.base/java.lang.reflect.Field.setAccessible(Field.java:171)
> 	at T8198317.testLogSettingInJavacTool(T8198317.java:63)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> 	at toolbox.TestRunner.runTests(TestRunner.java:89)
> 	at toolbox.TestRunner.runTests(TestRunner.java:73)
> 	at T8198317.main(T8198317.java:56)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
> 	at java.base/java.lang.Thread.run(Thread.java:831)
> 
> A better test case would be appreciated.

While it is acceptable practice for file manager tests to access the file manager internals, and more generally for javac tests to access the javac internals, it is less good to access the internals of other parts of the system (like PrintWriter in java.base), since future changes to those components could break this test as an unwelcome side effect.

How easy would it be to observe/verify the desired behavior by monitoring the output to the resulting PrintWriter object, e.g. by triggering some known diagnostic?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1896

From github.com+13688759+lgxbslgx at openjdk.java.net  Sat Dec 26 18:58:15 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sat, 26 Dec 2020 18:58:15 GMT
Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility [v3]
In-Reply-To: <wd62mmsecdHYCNEAhc-2qsTSRJy0v7QA70Dl4-hXKQA=.a3cc5eba-97ed-4b75-b004-e394edfeb98b@github.com>
References: <wd62mmsecdHYCNEAhc-2qsTSRJy0v7QA70Dl4-hXKQA=.a3cc5eba-97ed-4b75-b004-e394edfeb98b@github.com>
Message-ID: <JX-iyXc_sJJURjgud46jHz7kLSJt7Jvf-7XkeRtNjLU=.29e853a7-4932-413b-9f98-ac619dcd5069@github.com>

> Hi all,
> 
> This little patch enhances the setting of `Log` in `JavacTool.getTask`.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Revise test.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1896/files
  - new: https://git.openjdk.java.net/jdk/pull/1896/files/f73c4052..e13c072b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1896&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1896&range=01-02

  Stats: 63 lines in 1 file changed: 52 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1896.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1896/head:pull/1896

PR: https://git.openjdk.java.net/jdk/pull/1896

From github.com+13688759+lgxbslgx at openjdk.java.net  Sun Dec 27 15:02:04 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sun, 27 Dec 2020 15:02:04 GMT
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
Message-ID: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>

Hi all,

This patch replaces javac's `Filter` with `Predicate` and set `Filter` as `Deprecated`.
Two existing tests failed and I fixed it.
Currently, all the tests in `test/langtools` passed locally by using the following command.

make test CONF=linux-x86_64-server-release JOBS=4 TEST=test/langtools/

Thank you for taking the time to review.

Best Regards.

-------------

Commit messages:
 - Add comments.
 - 8057543: Replace javac's Filter with Predicate (and lambdas)

Changes: https://git.openjdk.java.net/jdk/pull/1898/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1898&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8057543
  Stats: 147 lines in 19 files changed: 22 ins; 6 del; 119 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1898.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1898/head:pull/1898

PR: https://git.openjdk.java.net/jdk/pull/1898

From github.com+13688759+lgxbslgx at openjdk.java.net  Sun Dec 27 15:38:54 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Sun, 27 Dec 2020 15:38:54 GMT
Subject: RFR: 8057543: Replace javac's Filter with Predicate (and lambdas)
In-Reply-To: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
References: <bpkysQEcqriD_LisrpETmgXnbEBfM4Yw6p6MNMLPhnA=.7c55eccf-00ca-48d5-8bdf-7e2d7e68d631@github.com>
Message-ID: <iMmlBs0rju7_yEOzjoD_8zbuFadN-rqTuAbvZF0hwf4=.f137c2e1-dca7-4668-bfe1-5c3a5bf83c2a@github.com>

On Sun, 27 Dec 2020 14:54:16 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> This patch replaces javac's `Filter` with `Predicate` and sets `Filter` as `Deprecated`.
> Two existing tests failed and I fixed it.
> Currently, all the tests in `test/langtools` passed locally by using the following command.
> 
> make test CONF=linux-x86_64-server-release JOBS=4 TEST=test/langtools/
> 
> Thank you for taking the time to review.
> 
> Best Regards.

More information and some similar issues:

These four issues were fixed in [this patch](https://github.com/openjdk/jdk/commit/c4e8276376676bda9aa4cb00b6d071fb70c21b85)
[JDK-8057542](https://bugs.openjdk.java.net/browse/JDK-8057542)
[JDK-8057545](https://bugs.openjdk.java.net/browse/JDK-8057545)
[JDK-8057546](https://bugs.openjdk.java.net/browse/JDK-8057546)
[JDK-8057547](https://bugs.openjdk.java.net/browse/JDK-8057547)

This issue was fixed in [this patch](https://github.com/openjdk/jdk/commit/582a4ebd92e60f95ae77d25eb00c6a146e727fab)
[JDK-8057544](https://bugs.openjdk.java.net/browse/JDK-8057544)

But their status are still `NEW`. It should be revised to `RESOLVED` or `CLOSED`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1898

From bsrbnd at gmail.com  Sun Dec 27 21:31:04 2020
From: bsrbnd at gmail.com (B. Blaser)
Date: Sun, 27 Dec 2020 22:31:04 +0100
Subject: Records, Intersection type and lambda
In-Reply-To: <df32ce1d-af2f-0a20-c3af-f56c17c2d203@oracle.com>
References: <1634118475.2157445.1605459778491.JavaMail.zimbra@u-pem.fr>
 <CAEgw74At3W0manZ4yQsUewZz8iYJ5D136MXLw_nfR6OzjjYUcA@mail.gmail.com>
 <1485898290.1122166.1605599180102.JavaMail.zimbra@u-pem.fr>
 <CAEgw74DK6=Hvehk+GxVL8TcKeMFxUsHevSU0ATzTJQzGB-AoaA@mail.gmail.com>
 <ce41110b-757d-b1f0-7358-a3a716ef52a4@oracle.com>
 <CAEgw74Azjxk34K0Mo5b9-UxDCBDT6tE1M0K9sZ837aSi28LdxA@mail.gmail.com>
 <df32ce1d-af2f-0a20-c3af-f56c17c2d203@oracle.com>
Message-ID: <CAEgw74D3xVQmgOdfe4ByBgZNW9TKOGLJ84CY0QgXXuE3=xGbNg@mail.gmail.com>

Hi Vicente,

On Wed, 23 Dec 2020 at 04:29, Vicente Romero <vicente.romero at oracle.com> wrote:
>
> Hi Bernard,
>
> what side effects do you see?

By tweaking Remi's example:

public class RecLCE {
  interface Foo { }
  interface F<T extends Foo> {
    void call(T t);
  }

  record Bar1() implements Foo { }
  record Bar2() implements Foo { }
  record Pair<P extends Foo>(P p1, P p2) {

    static <P extends Foo> Pair<P> of(P p1, P p2) {
      return new Pair<P>(p1, p2);
    }

    void forEach(F<P> f) {
      f.call(p1);
      f.call(p2);
    }
  }

  static class Hello {
    void m(Foo foo) {
      System.out.println(foo.getClass());
    }
  }

  public static void main(String[] args) {
    var pair = Pair.of(new Bar1(), new Bar2());
    pair.forEach(new Hello()::m);
  }
}

The line you've added is causing the lambda to use the instantiated
type 'Record' which isn't a subtype of 'Foo', see javap's output:
    Method arguments:
      #57 (LRecLCE$Foo;)V
      #58 REF_invokeStatic
RecLCE.lambda$main$0:(LRecLCE$Hello;Ljava/lang/Record;)V
      #61 (Ljava/lang/Record;)V

So, it should use the un-instantiated SAM parameter type 'Foo' instead
which my initial fix was suggesting:
    Method arguments:
      #57 (LRecLCE$Foo;)V
      #58 REF_invokeStatic RecLCE.lambda$main$0:(LRecLCE$Hello;LRecLCE$Foo;)V
      #61 (Ljava/lang/Record;)V

Unfortunately, this very example reveals another issue as the
instantiated type 'Record' is still not convertible to 'Foo' although
all was working fine with Remis's initial example:
    Method arguments:
      #55 (Ljava/lang/Object;)V
      #57 REF_invokeStatic
RecordIntersectionTypeAndLambda.lambda$main$0:(LRecordIntersectionTypeAndLambda$Hello;Ljava/lang/Object;)V
      #60 (Ljava/lang/Record;)V

Referring to 'LambdaMetafactory::metafactory', we see that
'instantiatedMethodType' may be the same or a specialization of
'samMethodType' suggesting to use the SAM type too when the
instantiated type is compound like in the experimental fix below
(langtools:tier1 is OK on jdk14u):
    Method arguments:
      #57 (LRecLCE$Foo;)V
      #58 REF_invokeStatic RecLCE.lambda$main$0:(LRecLCE$Hello;LRecLCE$Foo;)V
      #57 (LRecLCE$Foo;)V

What do you think?
Bernard

diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
@@ -438,6 +438,7 @@
         List<JCExpression> indy_args =
translate(syntheticInits.toList(), localContext.prev);

         //convert to an invokedynamic call
+        localContext.useSAM = tree.useSAM;
         result = makeMetafactoryIndyCall(context, sym.asHandle(), indy_args);
     }

@@ -888,6 +889,7 @@
         private final ListBuffer<JCVariableDecl> params = new ListBuffer<>();

         private JCExpression receiverExpression = null;
+        private boolean useSAM = false;

         MemberReferenceToLambda(JCMemberReference tree,
ReferenceTranslationContext localContext, Symbol owner) {
             this.tree = tree;
@@ -911,6 +913,7 @@
                 slam.target = tree.target;
                 slam.type = tree.type;
                 slam.pos = tree.pos;
+                slam.useSAM = useSAM;
                 return slam;
             } finally {
                 make.at(prevPos);
@@ -954,6 +957,7 @@

             // Failsafe -- assure match-up
             boolean checkForIntersection = tree.varargsElement !=
null || implSize == descPTypes.size();
+            useSAM = checkForIntersection &&
localContext.interfaceParameterIsIntersectionOrUnionType();

             // Use parameter types of the implementation method
unless the unerased
             // SAM parameter type is an intersection type, in that case use the
@@ -963,18 +967,7 @@
             // are used as pointers to the current parameter type information
             // and are thus not usable afterwards.
             for (int i = 0; implPTypes.nonEmpty() && i < last; ++i) {
-                // By default use the implementation method parmeter type
-                Type parmType = implPTypes.head;
-                // If the unerased parameter type is a type variable whose
-                // bound is an intersection (eg. <T extends A & B>) then
-                // use the SAM parameter type
-                if (checkForIntersection && descPTypes.head.getKind()
== TypeKind.TYPEVAR) {
-                    TypeVar tv = (TypeVar) descPTypes.head;
-                    if (tv.getUpperBound().getKind() ==
TypeKind.INTERSECTION) {
-                        parmType = samPTypes.head;
-                    }
-                }
-                addParameter("x$" + i, parmType, true);
+                addParameter("x$" + i, useSAM ? samPTypes.head :
implPTypes.head, true);

                 // Advance to the next parameter
                 implPTypes = implPTypes.tail;
@@ -1094,7 +1087,7 @@
         List<LoadableConstant> staticArgs = List.of(
                 typeToMethodType(samSym.type),
                 refSym.asHandle(),
-                typeToMethodType(tree.getDescriptorType(types)));
+                typeToMethodType(context.useSAM ? samSym.type :
tree.getDescriptorType(types)));

         //computed indy arg types
         ListBuffer<Type> indy_args_types = new ListBuffer<>();
@@ -1826,6 +1819,8 @@
             /** list of methods to be bridged by the meta-factory */
             final List<Symbol> bridges;

+            boolean useSAM = false;
+
             TranslationContext(T tree) {
                 this.tree = tree;
                 this.owner = owner(true);
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java
@@ -1892,6 +1892,7 @@
         public JCTree body;
         public boolean canCompleteNormally = true;
         public ParameterKind paramKind;
+        public boolean useSAM = false;

         public JCLambda(List<JCVariableDecl> params,
                         JCTree body) {

From github.com+3896345+hltj at openjdk.java.net  Mon Dec 28 15:22:08 2020
From: github.com+3896345+hltj at openjdk.java.net (Jia Yanwei)
Date: Mon, 28 Dec 2020 15:22:08 GMT
Subject: RFR: 8258897: wrong translation of capturing local classes inside
 nested lambdas
Message-ID: <kqt3eLtYBwA_b8d-7Rqa166hJ-j1h1RIhVmSPBmkDCw=.70768c3c-9070-4993-9627-88dd9959189b@github.com>

**Issue:**
`javac` crashes with a NPE when compiling such code:
- a local class captured a reference type local variable of a enclosed lambda (which contains multiple local variables with different types)
- instance the local class in a nested lambda

Affects all versions from Java 8 to 16-ea, here is a example output with OpenJDK 15.0.1:

An exception has occurred in the compiler (15.0.1). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java.lang.NullPointerException: Cannot read field "sym" because "this.lvar[1]" is null
    at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:571)
    at jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.load(Items.java:399)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:889)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:1942)
    at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1800)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:864)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1723)
    at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1532)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:618)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:669)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1084)
    at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1047)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:954)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:917)
    at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:893)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597)
    at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2395)
    at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:756)
    at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1644)
    at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1612)
    at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973)
    at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317)
    at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
    at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:59)
    at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:45)
printing javac parameters to: /tmp/javac.20201126_141249.args

The minimal reproducing code is:

 java
class Main {
    static Runnable runnable = () -> {
        boolean b0 = false;
        String s0 = "hello";

        class Local {
            int i = s0.length();
        }

        Runnable dummy = () -> new Local();
    };
}

If the captured variable is a primitive type, the code will compile but cause a runtime crash at startup. e.g.:

 java
public class CaptureInt {
    static Runnable runnable = () -> {
        boolean b0 = false;
        int i0 = 5;

        class Local {
            int i = i0 + 2;
        }

        Runnable dummy = () -> new Local();
    };

    public static void main(String args[]) {
    }
}

**Reason & Solution:**

During compilation, the captured variable was correctly synthetized as a synthetic argument in the synthetic methods for the nested lambda after `desugar()`. 
But the synthetic argument was not used when loading free variables, and it always use the original symbol for the original variable as if not in a nested lambda.
My experimental solution is substituting the symbols in free variables that were captured as synthetic arguments in nested lambda.
Welcome any advice and better solution.

-------------

Commit messages:
 - Merge branch 'master' into javac-npe-fix
 - update variables order in test case & remove redundancy test cases
 - fix code style for test cases
 - merge test cases & introduce more cases with anonymous cases enabled
 - merge test cases & introduce more cases with anonymous cases enabled
 - remove redundancy test cases & rename the rest test cases
 - fix another NPE in jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:571)

Changes: https://git.openjdk.java.net/jdk/pull/1479/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1479&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258897
  Stats: 154 lines in 3 files changed: 152 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1479.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1479/head:pull/1479

PR: https://git.openjdk.java.net/jdk/pull/1479

From github.com+3896345+hltj at openjdk.java.net  Mon Dec 28 15:22:09 2020
From: github.com+3896345+hltj at openjdk.java.net (Jia Yanwei)
Date: Mon, 28 Dec 2020 15:22:09 GMT
Subject: RFR: 8258897: wrong translation of capturing local classes inside
 nested lambdas
In-Reply-To: <kqt3eLtYBwA_b8d-7Rqa166hJ-j1h1RIhVmSPBmkDCw=.70768c3c-9070-4993-9627-88dd9959189b@github.com>
References: <kqt3eLtYBwA_b8d-7Rqa166hJ-j1h1RIhVmSPBmkDCw=.70768c3c-9070-4993-9627-88dd9959189b@github.com>
Message-ID: <VSh4s4Ice9cXWTbF6yll5OW6W-qkfE74F9w5lRtOsZM=.4d746566-e90d-4da6-a731-cc716c9c05c5@github.com>

On Fri, 27 Nov 2020 12:32:21 GMT, Jia Yanwei <github.com+3896345+hltj at openjdk.org> wrote:

> **Issue:**
> `javac` crashes with a NPE when compiling such code:
> - a local class captured a reference type local variable of a enclosed lambda (which contains multiple local variables with different types)
> - instance the local class in a nested lambda
> 
> Affects all versions from Java 8 to 16-ea, here is a example output with OpenJDK 15.0.1:
> 
> An exception has occurred in the compiler (15.0.1). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.NullPointerException: Cannot read field "sym" because "this.lvar[1]" is null
>     at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:571)
>     at jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.load(Items.java:399)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:889)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:1942)
>     at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1800)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:864)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1723)
>     at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1532)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:618)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:669)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1084)
>     at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1047)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:954)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:917)
>     at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:893)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2395)
>     at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:756)
>     at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1644)
>     at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1612)
>     at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973)
>     at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317)
>     at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
>     at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:59)
>     at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:45)
> printing javac parameters to: /tmp/javac.20201126_141249.args
> 
> The minimal reproducing code is:
> 
>  java
> class Main {
>     static Runnable runnable = () -> {
>         boolean b0 = false;
>         String s0 = "hello";
> 
>         class Local {
>             int i = s0.length();
>         }
> 
>         Runnable dummy = () -> new Local();
>     };
> }
> 
> If the captured variable is a primitive type, the code will compile but cause a runtime crash at startup. e.g.:
> 
>  java
> public class CaptureInt {
>     static Runnable runnable = () -> {
>         boolean b0 = false;
>         int i0 = 5;
> 
>         class Local {
>             int i = i0 + 2;
>         }
> 
>         Runnable dummy = () -> new Local();
>     };
> 
>     public static void main(String args[]) {
>     }
> }
> 
> **Reason & Solution:**
> 
> During compilation, the captured variable was correctly synthetized as a synthetic argument in the synthetic methods for the nested lambda after `desugar()`. 
> But the synthetic argument was not used when loading free variables, and it always use the original symbol for the original variable as if not in a nested lambda.
> My experimental solution is substituting the symbols in free variables that were captured as synthetic arguments in nested lambda.
> Welcome any advice and better solution.

I had signed OCA, but named as `jyw`, the email and full name are identical.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1479

From github.com+13688759+lgxbslgx at openjdk.java.net  Mon Dec 28 15:35:01 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Mon, 28 Dec 2020 15:35:01 GMT
Subject: [jdk16] Integrated: 8258662: JDK 17ea: Crash compiling instanceof
 check involving sealed interface
In-Reply-To: <MFzZOJ-kez-q_glvfq4TDsFyLs2dTP8PpoxdfnygmCE=.fa3a8634-850d-4eae-a33b-92b3715a7bcb@github.com>
References: <MFzZOJ-kez-q_glvfq4TDsFyLs2dTP8PpoxdfnygmCE=.fa3a8634-850d-4eae-a33b-92b3715a7bcb@github.com>
Message-ID: <nF_jO3zwoaXvwDJknev--FcKE2ALSnKjaWHXBWY3OaM=.6b30fa19-5fb8-4c99-be10-108214fee8ef@github.com>

On Wed, 23 Dec 2020 05:10:59 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> The method `Types.isCastable` uses method `Types.areDisjoint` to do some check. But `Types.isCastable` doesn't check the type of the parameter before invoking method `Types.areDisjoint`. This patch adds the corresponding check and add a test case.
> 
> The original patch is in https://github.com/openjdk/jdk/pull/1849.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

This pull request has now been integrated.

Changeset: 881bceb9
Author:    Guoxiong Li <lgxbslgx at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.java.net/jdk16/commit/881bceb9
Stats:     76 lines in 2 files changed: 75 ins; 0 del; 1 mod

8258662: JDK 17ea: Crash compiling instanceof check involving sealed interface

Reviewed-by: vromero

-------------

PR: https://git.openjdk.java.net/jdk16/pull/63

From github.com+3896345+hltj at openjdk.java.net  Tue Dec 29 02:46:57 2020
From: github.com+3896345+hltj at openjdk.java.net (Jia Yanwei)
Date: Tue, 29 Dec 2020 02:46:57 GMT
Subject: RFR: 8258897: wrong translation of capturing local classes inside
 nested lambdas
In-Reply-To: <VSh4s4Ice9cXWTbF6yll5OW6W-qkfE74F9w5lRtOsZM=.4d746566-e90d-4da6-a731-cc716c9c05c5@github.com>
References: <kqt3eLtYBwA_b8d-7Rqa166hJ-j1h1RIhVmSPBmkDCw=.70768c3c-9070-4993-9627-88dd9959189b@github.com>
 <VSh4s4Ice9cXWTbF6yll5OW6W-qkfE74F9w5lRtOsZM=.4d746566-e90d-4da6-a731-cc716c9c05c5@github.com>
Message-ID: <xxxNXeuywItbf5K25HU5kE6wHD945ii5Kqmt7ot85wc=.5928d488-1fa7-4438-bf2b-5f2f15537e80@github.com>

On Fri, 27 Nov 2020 12:37:24 GMT, Jia Yanwei <github.com+3896345+hltj at openjdk.org> wrote:

>> **Issue:**
>> `javac` crashes with a NPE when compiling such code:
>> - a local class captured a reference type local variable of a enclosed lambda (which contains multiple local variables with different types)
>> - instance the local class in a nested lambda
>> 
>> Affects all versions from Java 8 to 16-ea, here is a example output with OpenJDK 15.0.1:
>> 
>> An exception has occurred in the compiler (15.0.1). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
>> java.lang.NullPointerException: Cannot read field "sym" because "this.lvar[1]" is null
>>     at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:571)
>>     at jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.load(Items.java:399)
>>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:889)
>>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:1942)
>>     at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1800)
>>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:864)
>>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1723)
>>     at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1532)
>>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597)
>>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632)
>>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:618)
>>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:669)
>>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1084)
>>     at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1047)
>>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597)
>>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632)
>>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:954)
>>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:917)
>>     at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:893)
>>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597)
>>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2395)
>>     at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:756)
>>     at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1644)
>>     at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1612)
>>     at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973)
>>     at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317)
>>     at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
>>     at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:59)
>>     at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:45)
>> printing javac parameters to: /tmp/javac.20201126_141249.args
>> 
>> The minimal reproducing code is:
>> 
>>  java
>> class Main {
>>     static Runnable runnable = () -> {
>>         boolean b0 = false;
>>         String s0 = "hello";
>> 
>>         class Local {
>>             int i = s0.length();
>>         }
>> 
>>         Runnable dummy = () -> new Local();
>>     };
>> }
>> 
>> If the captured variable is a primitive type, the code will compile but cause a runtime crash at startup. e.g.:
>> 
>>  java
>> public class CaptureInt {
>>     static Runnable runnable = () -> {
>>         boolean b0 = false;
>>         int i0 = 5;
>> 
>>         class Local {
>>             int i = i0 + 2;
>>         }
>> 
>>         Runnable dummy = () -> new Local();
>>     };
>> 
>>     public static void main(String args[]) {
>>     }
>> }
>> 
>> **Reason & Solution:**
>> 
>> During compilation, the captured variable was correctly synthetized as a synthetic argument in the synthetic methods for the nested lambda after `desugar()`. 
>> But the synthetic argument was not used when loading free variables, and it always use the original symbol for the original variable as if not in a nested lambda.
>> My experimental solution is substituting the symbols in free variables that were captured as synthetic arguments in nested lambda.
>> Welcome any advice and better solution.
>
> I had signed OCA, but named as `jyw`, the email and full name are identical.

Bernard's reply:

The problem seems to be that 'lambdaTranslationMap' links the
untranslated local variable to its capture. So, what do you think of
the following solution to keep the translated local variable's mapping
with the original symbol (both examples and langtools:tier1 are OK on
jdk14u)?

 diff
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
@@ -2057,7 +2057,13 @@
                         };
                         break;
                     case LOCAL_VAR:
-                        ret = new VarSymbol(sym.flags() & FINAL,
sym.name, sym.type, translatedSym);
+                        ret = new VarSymbol(sym.flags() & FINAL,
sym.name, sym.type, translatedSym) {
+                            @Override
+                            public Symbol baseSymbol() {
+                                //keep mapping with original symbol
+                                return sym;
+                            }
+                        };
                         ((VarSymbol) ret).pos = ((VarSymbol) sym).pos;
                         break;
                     case PARAM:
diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java
@@ -1221,7 +1221,7 @@
                 //sym is a local variable - check the lambda translation map to
                 //see if sym has been translated to something else in
the current
                 //scope (by LambdaToMethod)
-                Symbol translatedSym = lambdaTranslationMap.get(sym);
+                Symbol translatedSym =
lambdaTranslationMap.get(sym.baseSymbol());
                 if (translatedSym != null) {
                     tree = make.at(tree.pos).Ident(translatedSym);
                 }

-------------

PR: https://git.openjdk.java.net/jdk/pull/1479

From jjg at openjdk.java.net  Tue Dec 29 03:45:57 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 29 Dec 2020 03:45:57 GMT
Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility [v3]
In-Reply-To: <JX-iyXc_sJJURjgud46jHz7kLSJt7Jvf-7XkeRtNjLU=.29e853a7-4932-413b-9f98-ac619dcd5069@github.com>
References: <wd62mmsecdHYCNEAhc-2qsTSRJy0v7QA70Dl4-hXKQA=.a3cc5eba-97ed-4b75-b004-e394edfeb98b@github.com>
 <JX-iyXc_sJJURjgud46jHz7kLSJt7Jvf-7XkeRtNjLU=.29e853a7-4932-413b-9f98-ac619dcd5069@github.com>
Message-ID: <1C7URguurLTNecDlWJUVnuzOMKjxWYTbtMALA7_zujM=.34d4f580-4695-4790-afbd-16d5a2b8120b@github.com>

On Sat, 26 Dec 2020 18:58:15 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi all,
>> 
>> This little patch enhances the setting of `Log` in `JavacTool.getTask`.
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revise test.

Any time that tests split a string into lines it is really important to ensure that it works on Windows as well as Linux/Mac platforms, because of the different line endings.

The code looks OK. Alternatively, if you are not concerned to check for the exact line ending sequence, you can use `split("\\R")` to split on any line ending sequence.  Either way, it's worth checking the test runs on platforms with both kinds of typical line ending.

test/langtools/tools/javac/api/8198317/T8198317.java line 90:

> 88:                 .call();
> 89:         tb.checkEqual(expected, Arrays.asList(bais.toString().split(lineSeparator)));
> 90:         System.setErr(prev);

Although not strictly necessary in this case, it is good practice to use `try ... finally` to reset values back to some previous value. In other words, the `System.setErr(prev);` should be in the `finally` clause.

test/langtools/tools/javac/api/8198317/T8198317.java line 82:

> 80: 
> 81:         // Situation: out is null and the value is not set in the context.
> 82:         ByteArrayOutputStream bais = new ByteArrayOutputStream();

The variable name `bais` is "surprising". Is it a cut-n-paste from elsewhere?    I was expecting to see `baos` as an acronym for "byte array output stream",  `bais` suggests "byte array input stream".

-------------

PR: https://git.openjdk.java.net/jdk/pull/1896

From jjg at openjdk.java.net  Tue Dec 29 03:45:58 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 29 Dec 2020 03:45:58 GMT
Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility [v3]
In-Reply-To: <1C7URguurLTNecDlWJUVnuzOMKjxWYTbtMALA7_zujM=.34d4f580-4695-4790-afbd-16d5a2b8120b@github.com>
References: <wd62mmsecdHYCNEAhc-2qsTSRJy0v7QA70Dl4-hXKQA=.a3cc5eba-97ed-4b75-b004-e394edfeb98b@github.com>
 <JX-iyXc_sJJURjgud46jHz7kLSJt7Jvf-7XkeRtNjLU=.29e853a7-4932-413b-9f98-ac619dcd5069@github.com>
 <1C7URguurLTNecDlWJUVnuzOMKjxWYTbtMALA7_zujM=.34d4f580-4695-4790-afbd-16d5a2b8120b@github.com>
Message-ID: <hSAOOWfjpir1YS6CcWYjFRE49HCzBTeNDjUcEhYc5hU=.778e45ae-647d-4dde-937e-616d1fc2ca80@github.com>

On Tue, 29 Dec 2020 03:40:52 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revise test.
>
> Any time that tests split a string into lines it is really important to ensure that it works on Windows as well as Linux/Mac platforms, because of the different line endings.
> 
> The code looks OK. Alternatively, if you are not concerned to check for the exact line ending sequence, you can use `split("\\R")` to split on any line ending sequence.  Either way, it's worth checking the test runs on platforms with both kinds of typical line ending.

Given that the `langtools/tier1` pre-submit tests worked for Linux and Windows, you're OK on the "newline" front.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1896

From github.com+3896345+hltj at openjdk.java.net  Tue Dec 29 04:25:05 2020
From: github.com+3896345+hltj at openjdk.java.net (Jia Yanwei)
Date: Tue, 29 Dec 2020 04:25:05 GMT
Subject: RFR: 8258897: wrong translation of capturing local classes inside
 nested lambdas [v2]
In-Reply-To: <kqt3eLtYBwA_b8d-7Rqa166hJ-j1h1RIhVmSPBmkDCw=.70768c3c-9070-4993-9627-88dd9959189b@github.com>
References: <kqt3eLtYBwA_b8d-7Rqa166hJ-j1h1RIhVmSPBmkDCw=.70768c3c-9070-4993-9627-88dd9959189b@github.com>
Message-ID: <5NB4DrPwwCONpkbWmEHKUHL8CWEqHSk1QoPP_IDF0bg=.e64256d0-5f6b-471c-850b-912863ea3058@github.com>

> **Issue:**
> `javac` crashes with a NPE when compiling such code:
> - a local class captured a reference type local variable of a enclosed lambda (which contains multiple local variables with different types)
> - instance the local class in a nested lambda
> 
> Affects all versions from Java 8 to 16-ea, here is a example output with OpenJDK 15.0.1:
> 
> An exception has occurred in the compiler (15.0.1). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.NullPointerException: Cannot read field "sym" because "this.lvar[1]" is null
>     at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:571)
>     at jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.load(Items.java:399)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:889)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:1942)
>     at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1800)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:864)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1723)
>     at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1532)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:618)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:669)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1084)
>     at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1047)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:954)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:917)
>     at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:893)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2395)
>     at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:756)
>     at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1644)
>     at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1612)
>     at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973)
>     at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317)
>     at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
>     at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:59)
>     at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:45)
> printing javac parameters to: /tmp/javac.20201126_141249.args
> 
> The minimal reproducing code is:
> 
>  java
> class Main {
>     static Runnable runnable = () -> {
>         boolean b0 = false;
>         String s0 = "hello";
> 
>         class Local {
>             int i = s0.length();
>         }
> 
>         Runnable dummy = () -> new Local();
>     };
> }
> 
> If the captured variable is a primitive type, the code will compile but cause a runtime crash at startup. e.g.:
> 
>  java
> public class CaptureInt {
>     static Runnable runnable = () -> {
>         boolean b0 = false;
>         int i0 = 5;
> 
>         class Local {
>             int i = i0 + 2;
>         }
> 
>         Runnable dummy = () -> new Local();
>     };
> 
>     public static void main(String args[]) {
>     }
> }
> 
> **Reason & Experimental solution:**
> 
> During compilation, the captured variable was correctly synthetized as a synthetic argument in the synthetic methods for the nested lambda after `desugar()`. 
> But the synthetic argument was not used when loading free variables, and it always use the original symbol for the original variable as if not in a nested lambda.
> My experimental solution is substituting the symbols in free variables that were captured as synthetic arguments in nested lambda.
> I'm not sure whether the code style as well as the solution itself are appropriate. Welcome any advice and better solution.

Jia Yanwei has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into javac-npe-fix
 - Merge branch 'master' into javac-npe-fix
 - update variables order in test case & remove redundancy test cases
 - fix code style for test cases
 - merge test cases & introduce more cases with anonymous cases enabled
 - merge test cases & introduce more cases with anonymous cases enabled
 - remove redundancy test cases & rename the rest test cases
 - fix another NPE in jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:571)

-------------

Changes: https://git.openjdk.java.net/jdk/pull/1479/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1479&range=01
  Stats: 154 lines in 3 files changed: 152 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1479.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1479/head:pull/1479

PR: https://git.openjdk.java.net/jdk/pull/1479

From github.com+3896345+hltj at openjdk.java.net  Tue Dec 29 04:53:10 2020
From: github.com+3896345+hltj at openjdk.java.net (Jia Yanwei)
Date: Tue, 29 Dec 2020 04:53:10 GMT
Subject: RFR: 8258897: wrong translation of capturing local classes inside
 nested lambdas [v3]
In-Reply-To: <kqt3eLtYBwA_b8d-7Rqa166hJ-j1h1RIhVmSPBmkDCw=.70768c3c-9070-4993-9627-88dd9959189b@github.com>
References: <kqt3eLtYBwA_b8d-7Rqa166hJ-j1h1RIhVmSPBmkDCw=.70768c3c-9070-4993-9627-88dd9959189b@github.com>
Message-ID: <nQH8IGk75o0ZJ7bcDuMY2q3FJIXsZmMMIR1LMApEpEQ=.83a2fa8e-7112-4bc6-af95-49968a99325f@github.com>

> **Issue:**
> `javac` crashes with a NPE when compiling such code:
> - a local class captured a reference type local variable of a enclosed lambda (which contains multiple local variables with different types)
> - instance the local class in a nested lambda
> 
> Affects all versions from Java 8 to 16-ea, here is a example output with OpenJDK 15.0.1:
> 
> An exception has occurred in the compiler (15.0.1). Please file a bug against the Java compiler via the Java bug reporting page (http://bugreport.java.com) after checking the Bug Database (http://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
> java.lang.NullPointerException: Cannot read field "sym" because "this.lvar[1]" is null
>     at jdk.compiler/com.sun.tools.javac.jvm.Code.emitop0(Code.java:571)
>     at jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.load(Items.java:399)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:889)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitNewClass(Gen.java:1942)
>     at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1800)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:864)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1723)
>     at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1532)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:618)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:669)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1084)
>     at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1047)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:632)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:954)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:917)
>     at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:893)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:597)
>     at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2395)
>     at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:756)
>     at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1644)
>     at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1612)
>     at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:973)
>     at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317)
>     at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
>     at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:59)
>     at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:45)
> printing javac parameters to: /tmp/javac.20201126_141249.args
> 
> The minimal reproducing code is:
> 
>  java
> class Main {
>     static Runnable runnable = () -> {
>         boolean b0 = false;
>         String s0 = "hello";
> 
>         class Local {
>             int i = s0.length();
>         }
> 
>         Runnable dummy = () -> new Local();
>     };
> }
> 
> If the captured variable is a primitive type, the code will compile but cause a runtime crash at startup. e.g.:
> 
>  java
> public class CaptureInt {
>     static Runnable runnable = () -> {
>         boolean b0 = false;
>         int i0 = 5;
> 
>         class Local {
>             int i = i0 + 2;
>         }
> 
>         Runnable dummy = () -> new Local();
>     };
> 
>     public static void main(String args[]) {
>     }
> }
> 
> **Reason & Experimental solution:**
> 
> During compilation, the captured variable was correctly synthetized as a synthetic argument in the synthetic methods for the nested lambda after `desugar()`. 
> But the synthetic argument was not used when loading free variables, and it always use the original symbol for the original variable as if not in a nested lambda.
> My experimental solution is substituting the symbols in free variables that were captured as synthetic arguments in nested lambda.
> I'm not sure whether the code style as well as the solution itself are appropriate. Welcome any advice and better solution.

Jia Yanwei has updated the pull request incrementally with three additional commits since the last revision:

 - fix 8258897: wrong translation of capturing local classes inside nested lambdas
 - rename test case directory name
 - revert the experimental fix in 9dec0d2

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1479/files
  - new: https://git.openjdk.java.net/jdk/pull/1479/files/74330aa2..86cb0ad8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1479&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1479&range=01-02

  Stats: 32 lines in 4 files changed: 6 ins; 22 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1479.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1479/head:pull/1479

PR: https://git.openjdk.java.net/jdk/pull/1479

From jwilhelm at openjdk.java.net  Tue Dec 29 05:27:58 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 29 Dec 2020 05:27:58 GMT
Subject: Integrated: Merge jdk16
Message-ID: <UejEJa3DX0NE2abzyUd3ax0t5MEhbACeI4HsrY-R3ao=.1f02b5ca-474e-412d-bbe3-b1b86422ba9d@github.com>

Forwardport JDK 16 -> JDK 17

-------------

Commit messages:
 - Merge
 - 8257147: [TESTBUG] Set a larger default loop count for the VectorAPI jtreg tests
 - 8216400: improve handling of IOExceptions in JavaCompiler.close()
 - 8258914: javax/net/ssl/DTLS/RespondToRetransmit.java timed out
 - Merge
 - 8258913: ProblemList javax/swing/JComboBox/6559152/bug6559152.java on Linux-X64
 - 8258856: VM build without C1/C2 fails after JDK-8243205
 - 8258851: Mismatch in SunPKCS11 provider registration properties and actual implementation
 - 8258839: Remove JVM option ExitVMOnVerifyError
 - 8258186: Replace use of JNI_COMMIT mode with mode 0
 - ... and 117 more: https://git.openjdk.java.net/jdk/compare/881bceb9...85accc95

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.java.net/jdk/pull/1902/files
  Stats: 24075 lines in 702 files changed: 18594 ins; 3271 del; 2210 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1902.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1902/head:pull/1902

PR: https://git.openjdk.java.net/jdk/pull/1902

From jwilhelm at openjdk.java.net  Tue Dec 29 05:28:00 2020
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Tue, 29 Dec 2020 05:28:00 GMT
Subject: Integrated: Merge jdk16
In-Reply-To: <UejEJa3DX0NE2abzyUd3ax0t5MEhbACeI4HsrY-R3ao=.1f02b5ca-474e-412d-bbe3-b1b86422ba9d@github.com>
References: <UejEJa3DX0NE2abzyUd3ax0t5MEhbACeI4HsrY-R3ao=.1f02b5ca-474e-412d-bbe3-b1b86422ba9d@github.com>
Message-ID: <xAv2P29NIKMsBoiLLkWS974g55kCcqZoGUM2qO-vhfw=.3b9cb745-a147-4b67-b73b-d0c53860907b@github.com>

On Tue, 29 Dec 2020 05:22:02 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 16 -> JDK 17

This pull request has now been integrated.

Changeset: 07c93fab
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/07c93fab
Stats:     143 lines in 15 files changed: 84 ins; 43 del; 16 mod

Merge

-------------

PR: https://git.openjdk.java.net/jdk/pull/1902

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Dec 29 07:36:32 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 29 Dec 2020 07:36:32 GMT
Subject: RFR: 8258525: Some existing tests should use /nodynamiccopyright/
 instead of the standard header [v2]
In-Reply-To: <epkxwkylg6_rkP9V3hrA3VaZOCJmmY51bgICJN_y5wg=.f2805d11-4bd9-4f4a-a477-d94452aad2e9@github.com>
References: <epkxwkylg6_rkP9V3hrA3VaZOCJmmY51bgICJN_y5wg=.f2805d11-4bd9-4f4a-a477-d94452aad2e9@github.com>
Message-ID: <606ChVIrA2FMkWK8AaEwzlTthd-GQBYoTdvifAUh1mQ=.8014aacf-8f9a-45d9-bd44-a9b264b30719@github.com>

> Hi all,
> 
> This is the background of this patch. According to the comments[1] written by Jonathan Gibbons during the review of JDK-8231622[2], I want to solve previous tests that used the bad style. I wrote a python script[3] to find the bad style tests. But it is not precise and complete.
> 
> [1] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015542.html
> [2] https://github.com/openjdk/jdk/pull/1626
> [3] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015619.html
> 
> Currently, I write another python script that can accurately check all the bad style tests. The procedure of this script is shown below.
> 1.  Add a blank line at the head of the java source files(exclude the files contain `/nodynamiccopyright/`) in directory `test/langtools/tools/javac`. This step simulates the changes of the length in the legal header.
> 2. Run the test by using the command `make test CONF=linux-x86_64-server-release JOBS=4 TEST=test/langtools/tools/javac`. This step checks whether the tests can be comfortable to the changes of the length in legal header. If a test failed, it means the test style is bad and need to be revised.
> 3. Delete the blank line at the head of the java source files(exclude the files contain `/nodynamiccopyright/`) in directory `test/langtools/tools/javac`. This step recovers the modified files.
> 
> If all the tests are in good style,  all the tests in step 2 will passed. I use this script to test the branch `master` locally. 129 tests failed. I fixed them. Currently, I use this script to test the branch `test-copyright-clean` of this patch locally. All the tests passed.
> 
> I think this patch solves all the bad style tests if my script has no bugs and no new bad style tests were integrated to branch `master` recently.
> 
> The code of the new python script is shown below. You maybe need to revise the options `CONF=linux-x86_64-server-release` and `JOBS=4` when testing locally.
> 
> #!/usr/bin/python
> import os
> 
> 
> def runTests(find_dir):
>     os.system('make test CONF=linux-x86_64-server-release JOBS=4 TEST=' + find_dir)
>     return
> 
> 
> def addBlankLinePerFile(full_path):
>     search_file = open(full_path, 'r+')
>     content = search_file.read()
>     if content.find("/nodynamiccopyright/") < 0 and full_path.endswith(".java"):
>         search_file.seek(0)
>         search_file.write("\n")
>         search_file.write(content)
>     search_file.close()
> 
> 
> def deleteBlankLinePerFile(full_path):
>     search_file = open(full_path, 'r')
>     old_content = search_file.readlines()
>     search_file.close()
>     search_file = open(full_path, 'w')
>     if ''.join(old_content).find("/nodynamiccopyright/") < 0 and full_path.endswith(".java"):
>         new_content = ''.join(old_content[1:])
>         search_file.write(new_content)
>     else:
>         search_file.write(''.join(old_content))
>     search_file.close()
> 
> 
> def addBlankLine(find_dir):
>     for dir_path, dir_names, file_names in os.walk(find_dir):
>         for file_name in file_names:
>             full_path = os.path.join(dir_path, file_name)
>             addBlankLinePerFile(full_path)
> 
> 
> def deleteBlankLine(find_dir):
>     for dir_path, dir_names, file_names in os.walk(find_dir):
>         for file_name in file_names:
>             full_path = os.path.join(dir_path, file_name)
>             deleteBlankLinePerFile(full_path)
> 
> 
> if __name__ == "__main__":
>     findDir = "test/langtools/tools/javac"
>     addBlankLine(findDir)
>     runTests(findDir)
>     deleteBlankLine(findDir)
> 
> 
> Thank you for taking the time to review.
> And could I ask your help to create a new issue in the bug tracker? Thanks again.

Guoxiong Li 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 four additional commits since the last revision:

 - Merge branch 'master' into test-copyright-cleanup
 - Merge branch 'master' into test-copyright-cleanup
 - Merge branch 'master' into test-copyright-cleanup
 - Some tests should use /nodynamiccopyright/ instead of the copyright header.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1732/files
  - new: https://git.openjdk.java.net/jdk/pull/1732/files/67882939..eeb04044

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1732&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1732&range=00-01

  Stats: 36027 lines in 1037 files changed: 27372 ins; 5145 del; 3510 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1732.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1732/head:pull/1732

PR: https://git.openjdk.java.net/jdk/pull/1732

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Dec 29 07:49:58 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 29 Dec 2020 07:49:58 GMT
Subject: RFR: 8258525: Some existing tests should use /nodynamiccopyright/
 instead of the standard header
In-Reply-To: <T2k3qsT52MFCumh3VnJuj51YB3-A4mrVBSGfmjQYtOA=.a8a5c937-2c47-48ae-89c2-4e89bd429bb7@github.com>
References: <epkxwkylg6_rkP9V3hrA3VaZOCJmmY51bgICJN_y5wg=.f2805d11-4bd9-4f4a-a477-d94452aad2e9@github.com>
 <7hafV_O2jHgs64xzjogkbZbfzpBvXvYkjisQEveKXCo=.6f8df181-19b8-4716-885b-1eb249c4080a@github.com>
 <-_LQhyFiYWgqUwwvr4yQuwdzUrhfef8ryPgOvuwZYwg=.64a37358-4973-4c1d-a218-80293d83366a@github.com>
 <T2k3qsT52MFCumh3VnJuj51YB3-A4mrVBSGfmjQYtOA=.a8a5c937-2c47-48ae-89c2-4e89bd429bb7@github.com>
Message-ID: <M2HVYHeeib-wCMbm7Uq2a0sYac5_U-R789qmsKbdb4o=.a622b1ac-456d-44e7-b86c-7e2f5fe22f2a@github.com>

On Sat, 19 Dec 2020 15:08:03 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> I'm ready to approve this change, once the issue has been set correctly
>
> The issue was set correctly. It is good to go on now.

I merged the `master` branch and did the check. All the new codes are fine.

@jonathan-gibbons I saw a patch you submit to JDK 16: [JDK-8258941](https://github.com/openjdk/jdk16/pull/69). It has a little change at `SomeVbc.java` which do the same thing as this patch. I think that this patch should be reviewed and be integrated as soon as possible so that other folks don't need to do the duplicated work.

Thank you for taking the time to review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1732

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Dec 29 08:05:16 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 29 Dec 2020 08:05:16 GMT
Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility [v4]
In-Reply-To: <wd62mmsecdHYCNEAhc-2qsTSRJy0v7QA70Dl4-hXKQA=.a3cc5eba-97ed-4b75-b004-e394edfeb98b@github.com>
References: <wd62mmsecdHYCNEAhc-2qsTSRJy0v7QA70Dl4-hXKQA=.a3cc5eba-97ed-4b75-b004-e394edfeb98b@github.com>
Message-ID: <tzBd5DDu-xKCq90buQq5Gj4KINpPw2gc5u35JUoY-ac=.564e08e9-5bd1-4042-9097-b549d8cd1456@github.com>

> Hi all,
> 
> This little patch enhances the setting of `Log` in `JavacTool.getTask`.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Revise test code. Fix typo.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1896/files
  - new: https://git.openjdk.java.net/jdk/pull/1896/files/e13c072b..909140e1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1896&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1896&range=02-03

  Stats: 11 lines in 1 file changed: 3 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1896.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1896/head:pull/1896

PR: https://git.openjdk.java.net/jdk/pull/1896

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Dec 29 08:05:17 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 29 Dec 2020 08:05:17 GMT
Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility [v3]
In-Reply-To: <1C7URguurLTNecDlWJUVnuzOMKjxWYTbtMALA7_zujM=.34d4f580-4695-4790-afbd-16d5a2b8120b@github.com>
References: <wd62mmsecdHYCNEAhc-2qsTSRJy0v7QA70Dl4-hXKQA=.a3cc5eba-97ed-4b75-b004-e394edfeb98b@github.com>
 <JX-iyXc_sJJURjgud46jHz7kLSJt7Jvf-7XkeRtNjLU=.29e853a7-4932-413b-9f98-ac619dcd5069@github.com>
 <1C7URguurLTNecDlWJUVnuzOMKjxWYTbtMALA7_zujM=.34d4f580-4695-4790-afbd-16d5a2b8120b@github.com>
Message-ID: <Mk-bBnKh4vrtGVeEgGanxaGKmM193XXYGCb990Rq9eU=.251eb738-e88e-45a2-bd00-feb37ac8b0f1@github.com>

On Tue, 29 Dec 2020 03:31:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revise test.
>
> test/langtools/tools/javac/api/8198317/T8198317.java line 90:
> 
>> 88:                 .call();
>> 89:         tb.checkEqual(expected, Arrays.asList(bais.toString().split(lineSeparator)));
>> 90:         System.setErr(prev);
> 
> Although not strictly necessary in this case, it is good practice to use `try ... finally` to reset values back to some previous value. In other words, the `System.setErr(prev);` should be in the `finally` clause.

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1896

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Dec 29 08:10:57 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 29 Dec 2020 08:10:57 GMT
Subject: RFR: 8198317: Enhance JavacTool.getTask for flexibility [v3]
In-Reply-To: <1C7URguurLTNecDlWJUVnuzOMKjxWYTbtMALA7_zujM=.34d4f580-4695-4790-afbd-16d5a2b8120b@github.com>
References: <wd62mmsecdHYCNEAhc-2qsTSRJy0v7QA70Dl4-hXKQA=.a3cc5eba-97ed-4b75-b004-e394edfeb98b@github.com>
 <JX-iyXc_sJJURjgud46jHz7kLSJt7Jvf-7XkeRtNjLU=.29e853a7-4932-413b-9f98-ac619dcd5069@github.com>
 <1C7URguurLTNecDlWJUVnuzOMKjxWYTbtMALA7_zujM=.34d4f580-4695-4790-afbd-16d5a2b8120b@github.com>
Message-ID: <GkFdi4ZdldPQBFWyL0YXHTr2f8ChPECJ8EYyvgG5TN4=.a5c51662-6669-4dd0-a954-4619ebebd425@github.com>

On Tue, 29 Dec 2020 03:34:21 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revise test.
>
> test/langtools/tools/javac/api/8198317/T8198317.java line 82:
> 
>> 80: 
>> 81:         // Situation: out is null and the value is not set in the context.
>> 82:         ByteArrayOutputStream bais = new ByteArrayOutputStream();
> 
> The variable name `bais` is "surprising". Is it a cut-n-paste from elsewhere?    I was expecting to see `baos` as an acronym for "byte array output stream",  `bais` suggests "byte array input stream".

Fixed. I used `ByteArrayInputStream bais = new ByteArrayInputStream();` at the beginning. Then I identified the `ByteArrayInputStream` is not right and changed to use `ByteArrayOutputStream`. But I forgot to revise the variable name `bais`. Sorry for wasting the time at this careless detail.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1896

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Dec 29 11:24:07 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 29 Dec 2020 11:24:07 GMT
Subject: RFR: 8173165: javac should reject references to enum constants from
 nested classes inside instance initializers
Message-ID: <-ybyMmI6j-ko4axPeDmAIhSTMMnosvR9WXzykEiG5Dw=.55bef910-bf0c-4134-8970-5d5acc143242@github.com>

Hi all,

The [JLS 8.9.2](https://docs.oracle.com/javase/specs/jls/se15/html/jls-8.html#jls-8.9.2) states it as bellow.

> It is a compile-time error to refer to a static field of an enum type from a constructor, instance initializer, or instance variable initializer of the enum type, unless the field is a constant variable (?4.12.4).

Currently, compiler doesn't generate the compile-time error when compiling the following code.

import java.util.HashSet;
public enum Test {
    FOO;
    public HashSet<Test> vals = new HashSet<Test>(){
        Test test = FOO;
        {
            add(FOO);
        }
    };
}

This patch fixes it and adds two corresponding tests. Thank you for taking the time to review.

Best Regards.

-------------

Commit messages:
 - 8173165: javac should reject references to enum constants from nested classes inside instance initializers

Changes: https://git.openjdk.java.net/jdk/pull/1905/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1905&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8173165
  Stats: 135 lines in 2 files changed: 131 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1905.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1905/head:pull/1905

PR: https://git.openjdk.java.net/jdk/pull/1905

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Dec 29 14:03:55 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 29 Dec 2020 14:03:55 GMT
Subject: RFR: 8173165: javac should reject references to enum constants
 from nested classes inside instance initializers
In-Reply-To: <-ybyMmI6j-ko4axPeDmAIhSTMMnosvR9WXzykEiG5Dw=.55bef910-bf0c-4134-8970-5d5acc143242@github.com>
References: <-ybyMmI6j-ko4axPeDmAIhSTMMnosvR9WXzykEiG5Dw=.55bef910-bf0c-4134-8970-5d5acc143242@github.com>
Message-ID: <IScBfNuKslT1uzc7VJpMwuGTgrLKmgTHOa2Anq4IMzo=.6eb20983-0531-4882-9d2c-af020aea8551@github.com>

On Tue, 29 Dec 2020 11:19:11 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> The [JLS 8.9.2](https://docs.oracle.com/javase/specs/jls/se15/html/jls-8.html#jls-8.9.2) states it as bellow.
> 
>> It is a compile-time error to refer to a static field of an enum type from a constructor, instance initializer, or instance variable initializer of the enum type, unless the field is a constant variable (?4.12.4).
> 
> Currently, compiler doesn't generate the compile-time error when compiling the following code.
> 
> import java.util.HashSet;
> public enum Test {
>     FOO;
>     public HashSet<Test> vals = new HashSet<Test>(){
>         Test test = FOO;
>         {
>             add(FOO);
>         }
>     };
> }
> 
> This patch fixes it and adds two corresponding tests. Thank you for taking the time to review.
> 
> Best Regards.

The bug is more complicated than I thought. I would like to close the PR and let another person fix it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1905

From github.com+13688759+lgxbslgx at openjdk.java.net  Tue Dec 29 14:03:56 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Tue, 29 Dec 2020 14:03:56 GMT
Subject: Withdrawn: 8173165: javac should reject references to enum constants
 from nested classes inside instance initializers
In-Reply-To: <-ybyMmI6j-ko4axPeDmAIhSTMMnosvR9WXzykEiG5Dw=.55bef910-bf0c-4134-8970-5d5acc143242@github.com>
References: <-ybyMmI6j-ko4axPeDmAIhSTMMnosvR9WXzykEiG5Dw=.55bef910-bf0c-4134-8970-5d5acc143242@github.com>
Message-ID: <sMfXEdU9fjQtjMRrlJQXAcpPRivlwwGBWDnOE359jZc=.8ddaf00f-1a24-4667-a6f6-8546dbc4864a@github.com>

On Tue, 29 Dec 2020 11:19:11 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> The [JLS 8.9.2](https://docs.oracle.com/javase/specs/jls/se15/html/jls-8.html#jls-8.9.2) states it as bellow.
> 
>> It is a compile-time error to refer to a static field of an enum type from a constructor, instance initializer, or instance variable initializer of the enum type, unless the field is a constant variable (?4.12.4).
> 
> Currently, compiler doesn't generate the compile-time error when compiling the following code.
> 
> import java.util.HashSet;
> public enum Test {
>     FOO;
>     public HashSet<Test> vals = new HashSet<Test>(){
>         Test test = FOO;
>         {
>             add(FOO);
>         }
>     };
> }
> 
> This patch fixes it and adds two corresponding tests. Thank you for taking the time to review.
> 
> Best Regards.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1905

From vromero at openjdk.java.net  Tue Dec 29 19:09:07 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Tue, 29 Dec 2020 19:09:07 GMT
Subject: [jdk16] RFR: 8258972: unexpected compilation error with generic
 sealed interface
Message-ID: <DbWhoIT75fWeUoToV64VgIfwM21ZaLbE_1VbQ3DuHVo=.674ca602-df3f-41b9-9359-5e1e2d18a1d9@github.com>

Hi,

Please review this fix to the implementation of section `5.1.6.1 Allowed Narrowing Reference Conversion` of the Sealed Classes spec [1](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201204/specs/sealed-classes-jls.html#jls-5.1.6.1). IMO the compiler was not implementing the spec to the letter in particular the inheritance relation between a sealed class and a subclass should be tested ignoring type arguments which is what this patch is doing. Comments?

Thanks,
Vicente

-------------

Commit messages:
 - 8258972: unexpected compilation error with generic sealed interface

Changes: https://git.openjdk.java.net/jdk16/pull/72/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk16&pr=72&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8258972
  Stats: 12 lines in 2 files changed: 11 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk16/pull/72.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk16 pull/72/head:pull/72

PR: https://git.openjdk.java.net/jdk16/pull/72

From jjg at openjdk.java.net  Wed Dec 30 03:35:03 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 30 Dec 2020 03:35:03 GMT
Subject: RFR: 8258525: Some existing tests should use /nodynamiccopyright/
 instead of the standard header [v2]
In-Reply-To: <606ChVIrA2FMkWK8AaEwzlTthd-GQBYoTdvifAUh1mQ=.8014aacf-8f9a-45d9-bd44-a9b264b30719@github.com>
References: <epkxwkylg6_rkP9V3hrA3VaZOCJmmY51bgICJN_y5wg=.f2805d11-4bd9-4f4a-a477-d94452aad2e9@github.com>
 <606ChVIrA2FMkWK8AaEwzlTthd-GQBYoTdvifAUh1mQ=.8014aacf-8f9a-45d9-bd44-a9b264b30719@github.com>
Message-ID: <RBANjLN5_bDPx-KDPaowi7uzU8iZ_r3UE6szHAN3c1s=.f53c1608-4bb5-49e3-acde-7a62e9c13bcf@github.com>

On Tue, 29 Dec 2020 07:36:32 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi all,
>> 
>> This is the background of this patch. According to the comments[1] written by Jonathan Gibbons during the review of JDK-8231622[2], I want to solve previous tests that used the bad style. I wrote a python script[3] to find the bad style tests. But it is not precise and complete.
>> 
>> [1] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015542.html
>> [2] https://github.com/openjdk/jdk/pull/1626
>> [3] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015619.html
>> 
>> Currently, I write another python script that can accurately check all the bad style tests. The procedure of this script is shown below.
>> 1.  Add a blank line at the head of the java source files(exclude the files contain `/nodynamiccopyright/`) in directory `test/langtools/tools/javac`. This step simulates the changes of the length in the legal header.
>> 2. Run the test by using the command `make test CONF=linux-x86_64-server-release JOBS=4 TEST=test/langtools/tools/javac`. This step checks whether the tests can be comfortable to the changes of the length in legal header. If a test failed, it means the test style is bad and need to be revised.
>> 3. Delete the blank line at the head of the java source files(exclude the files contain `/nodynamiccopyright/`) in directory `test/langtools/tools/javac`. This step recovers the modified files.
>> 
>> If all the tests are in good style,  all the tests in step 2 will passed. I use this script to test the branch `master` locally. 129 tests failed. I fixed them. Currently, I use this script to test the branch `test-copyright-clean` of this patch locally. All the tests passed.
>> 
>> I think this patch solves all the bad style tests if my script has no bugs and no new bad style tests were integrated to branch `master` recently.
>> 
>> The code of the new python script is shown below. You maybe need to revise the options `CONF=linux-x86_64-server-release` and `JOBS=4` when testing locally.
>> 
>> #!/usr/bin/python
>> import os
>> 
>> 
>> def runTests(find_dir):
>>     os.system('make test CONF=linux-x86_64-server-release JOBS=4 TEST=' + find_dir)
>>     return
>> 
>> 
>> def addBlankLinePerFile(full_path):
>>     search_file = open(full_path, 'r+')
>>     content = search_file.read()
>>     if content.find("/nodynamiccopyright/") < 0 and full_path.endswith(".java"):
>>         search_file.seek(0)
>>         search_file.write("\n")
>>         search_file.write(content)
>>     search_file.close()
>> 
>> 
>> def deleteBlankLinePerFile(full_path):
>>     search_file = open(full_path, 'r')
>>     old_content = search_file.readlines()
>>     search_file.close()
>>     search_file = open(full_path, 'w')
>>     if ''.join(old_content).find("/nodynamiccopyright/") < 0 and full_path.endswith(".java"):
>>         new_content = ''.join(old_content[1:])
>>         search_file.write(new_content)
>>     else:
>>         search_file.write(''.join(old_content))
>>     search_file.close()
>> 
>> 
>> def addBlankLine(find_dir):
>>     for dir_path, dir_names, file_names in os.walk(find_dir):
>>         for file_name in file_names:
>>             full_path = os.path.join(dir_path, file_name)
>>             addBlankLinePerFile(full_path)
>> 
>> 
>> def deleteBlankLine(find_dir):
>>     for dir_path, dir_names, file_names in os.walk(find_dir):
>>         for file_name in file_names:
>>             full_path = os.path.join(dir_path, file_name)
>>             deleteBlankLinePerFile(full_path)
>> 
>> 
>> if __name__ == "__main__":
>>     findDir = "test/langtools/tools/javac"
>>     addBlankLine(findDir)
>>     runTests(findDir)
>>     deleteBlankLine(findDir)
>> 
>> 
>> Thank you for taking the time to review.
>> And could I ask your help to create a new issue in the bug tracker? Thanks again.
>
> Guoxiong Li 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 four additional commits since the last revision:
> 
>  - Merge branch 'master' into test-copyright-cleanup
>  - Merge branch 'master' into test-copyright-cleanup
>  - Merge branch 'master' into test-copyright-cleanup
>  - Some tests should use /nodynamiccopyright/ instead of the copyright header.

Marked as reviewed by jjg (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1732

From github.com+13688759+lgxbslgx at openjdk.java.net  Wed Dec 30 17:24:02 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Wed, 30 Dec 2020 17:24:02 GMT
Subject: Integrated: 8258525: Some existing tests should use
 /nodynamiccopyright/ instead of the standard header
In-Reply-To: <epkxwkylg6_rkP9V3hrA3VaZOCJmmY51bgICJN_y5wg=.f2805d11-4bd9-4f4a-a477-d94452aad2e9@github.com>
References: <epkxwkylg6_rkP9V3hrA3VaZOCJmmY51bgICJN_y5wg=.f2805d11-4bd9-4f4a-a477-d94452aad2e9@github.com>
Message-ID: <CN2BozDcpFa0wp5Dul0AJsjOmVL_Mle90nLPurRoP3Q=.87c844cc-6f11-467b-81dc-665c926f90c2@github.com>

On Thu, 10 Dec 2020 13:02:28 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> This is the background of this patch. According to the comments[1] written by Jonathan Gibbons during the review of JDK-8231622[2], I want to solve previous tests that used the bad style. I wrote a python script[3] to find the bad style tests. But it is not precise and complete.
> 
> [1] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015542.html
> [2] https://github.com/openjdk/jdk/pull/1626
> [3] https://mail.openjdk.java.net/pipermail/compiler-dev/2020-December/015619.html
> 
> Currently, I write another python script that can accurately check all the bad style tests. The procedure of this script is shown below.
> 1.  Add a blank line at the head of the java source files(exclude the files contain `/nodynamiccopyright/`) in directory `test/langtools/tools/javac`. This step simulates the changes of the length in the legal header.
> 2. Run the test by using the command `make test CONF=linux-x86_64-server-release JOBS=4 TEST=test/langtools/tools/javac`. This step checks whether the tests can be comfortable to the changes of the length in legal header. If a test failed, it means the test style is bad and need to be revised.
> 3. Delete the blank line at the head of the java source files(exclude the files contain `/nodynamiccopyright/`) in directory `test/langtools/tools/javac`. This step recovers the modified files.
> 
> If all the tests are in good style,  all the tests in step 2 will passed. I use this script to test the branch `master` locally. 129 tests failed. I fixed them. Currently, I use this script to test the branch `test-copyright-clean` of this patch locally. All the tests passed.
> 
> I think this patch solves all the bad style tests if my script has no bugs and no new bad style tests were integrated to branch `master` recently.
> 
> The code of the new python script is shown below. You maybe need to revise the options `CONF=linux-x86_64-server-release` and `JOBS=4` when testing locally.
> 
> #!/usr/bin/python
> import os
> 
> 
> def runTests(find_dir):
>     os.system('make test CONF=linux-x86_64-server-release JOBS=4 TEST=' + find_dir)
>     return
> 
> 
> def addBlankLinePerFile(full_path):
>     search_file = open(full_path, 'r+')
>     content = search_file.read()
>     if content.find("/nodynamiccopyright/") < 0 and full_path.endswith(".java"):
>         search_file.seek(0)
>         search_file.write("\n")
>         search_file.write(content)
>     search_file.close()
> 
> 
> def deleteBlankLinePerFile(full_path):
>     search_file = open(full_path, 'r')
>     old_content = search_file.readlines()
>     search_file.close()
>     search_file = open(full_path, 'w')
>     if ''.join(old_content).find("/nodynamiccopyright/") < 0 and full_path.endswith(".java"):
>         new_content = ''.join(old_content[1:])
>         search_file.write(new_content)
>     else:
>         search_file.write(''.join(old_content))
>     search_file.close()
> 
> 
> def addBlankLine(find_dir):
>     for dir_path, dir_names, file_names in os.walk(find_dir):
>         for file_name in file_names:
>             full_path = os.path.join(dir_path, file_name)
>             addBlankLinePerFile(full_path)
> 
> 
> def deleteBlankLine(find_dir):
>     for dir_path, dir_names, file_names in os.walk(find_dir):
>         for file_name in file_names:
>             full_path = os.path.join(dir_path, file_name)
>             deleteBlankLinePerFile(full_path)
> 
> 
> if __name__ == "__main__":
>     findDir = "test/langtools/tools/javac"
>     addBlankLine(findDir)
>     runTests(findDir)
>     deleteBlankLine(findDir)
> 
> 
> Thank you for taking the time to review.
> And could I ask your help to create a new issue in the bug tracker? Thanks again.

This pull request has now been integrated.

Changeset: 8435f0da
Author:    Guoxiong Li <lgxbslgx at gmail.com>
Committer: Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8435f0da
Stats:     3385 lines in 265 files changed: 50 ins; 2798 del; 537 mod

8258525: Some existing tests should use /nodynamiccopyright/ instead of the standard header

Reviewed-by: jjg

-------------

PR: https://git.openjdk.java.net/jdk/pull/1732

From github.com+13688759+lgxbslgx at openjdk.java.net  Wed Dec 30 18:00:08 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Wed, 30 Dec 2020 18:00:08 GMT
Subject: RFR: 8255757: Javac emits duplicate pool entries on array::clone
Message-ID: <MuCBQnk3OEDrxF4QVee3M2FpsYYQjPaq_0xZ-RBzBRs=.2ddd46e4-8d39-46be-afd6-e9d0198ba539@github.com>

Hi all,

Currently, javac would emit duplicate pool entries when compiling array::clone.
This patch fixes it by using a cached field `Map<Type, Symbol> qualifiedSymbolCache;` and adds a corresponding test case.

Thank you for taking the time to review.

Best Regards.

-------------

Commit messages:
 - 8255757: Javac emits duplicate pool entries on array::clone

Changes: https://git.openjdk.java.net/jdk/pull/1912/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1912&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255757
  Stats: 121 lines in 2 files changed: 119 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1912.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1912/head:pull/1912

PR: https://git.openjdk.java.net/jdk/pull/1912

From vromero at openjdk.java.net  Wed Dec 30 22:51:57 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Wed, 30 Dec 2020 22:51:57 GMT
Subject: RFR: 8255757: Javac emits duplicate pool entries on array::clone
In-Reply-To: <MuCBQnk3OEDrxF4QVee3M2FpsYYQjPaq_0xZ-RBzBRs=.2ddd46e4-8d39-46be-afd6-e9d0198ba539@github.com>
References: <MuCBQnk3OEDrxF4QVee3M2FpsYYQjPaq_0xZ-RBzBRs=.2ddd46e4-8d39-46be-afd6-e9d0198ba539@github.com>
Message-ID: <Kihj1ieIiR-FD_4aR25TGesswT6ir3OymJAM-6PGZ0A=.97f14666-6982-4f4b-a0f3-235fb8babb01@github.com>

On Wed, 30 Dec 2020 17:55:48 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

> Hi all,
> 
> Currently, javac would emit duplicate pool entries when compiling array::clone.
> This patch fixes it by using a cached field `Map<Type, Symbol> qualifiedSymbolCache;` and adds a corresponding test case.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

Changes requested by vromero (Reviewer).

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 244:

> 242:             // array clone can be qualified by the array type in later targets
> 243:             if (qualifiedSymbolCache == null) {
> 244:                 qualifiedSymbolCache = new HashMap<>();

given that the map is initialized in the constructor I assume that this line should never be executed right? also I think that  you can clear the map in the `finally` block of method `Gen::genClass`

test/langtools/tools/javac/classfiles/T8255757/T8255757.java line 77:

> 75:                 .outdir(curPath)
> 76:                 .run()
> 77:                 .writeAll();

nit: I think that invoking the `writeAll` method is not necessary as the output is discarded, so it can be removed from the chain

-------------

PR: https://git.openjdk.java.net/jdk/pull/1912

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Dec 31 10:05:19 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 31 Dec 2020 10:05:19 GMT
Subject: RFR: 8255757: Javac emits duplicate pool entries on array::clone
 [v2]
In-Reply-To: <MuCBQnk3OEDrxF4QVee3M2FpsYYQjPaq_0xZ-RBzBRs=.2ddd46e4-8d39-46be-afd6-e9d0198ba539@github.com>
References: <MuCBQnk3OEDrxF4QVee3M2FpsYYQjPaq_0xZ-RBzBRs=.2ddd46e4-8d39-46be-afd6-e9d0198ba539@github.com>
Message-ID: <95Ede01CrNWuZSDy6iYKbOxf0e6TT5wlNXCwvGkgpBE=.c8b85fb8-1590-423b-b2d2-74dd09f6e306@github.com>

> Hi all,
> 
> Currently, javac would emit duplicate pool entries when compiling array::clone.
> This patch fixes it by using a cached field `Map<Type, Symbol> qualifiedSymbolCache;` and adds a corresponding test case.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup variable and useless test code.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1912/files
  - new: https://git.openjdk.java.net/jdk/pull/1912/files/ccad077d..1ab79ce1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1912&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1912&range=00-01

  Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1912.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1912/head:pull/1912

PR: https://git.openjdk.java.net/jdk/pull/1912

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Dec 31 10:11:59 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 31 Dec 2020 10:11:59 GMT
Subject: RFR: 8255757: Javac emits duplicate pool entries on array::clone
 [v2]
In-Reply-To: <Kihj1ieIiR-FD_4aR25TGesswT6ir3OymJAM-6PGZ0A=.97f14666-6982-4f4b-a0f3-235fb8babb01@github.com>
References: <MuCBQnk3OEDrxF4QVee3M2FpsYYQjPaq_0xZ-RBzBRs=.2ddd46e4-8d39-46be-afd6-e9d0198ba539@github.com>
 <Kihj1ieIiR-FD_4aR25TGesswT6ir3OymJAM-6PGZ0A=.97f14666-6982-4f4b-a0f3-235fb8babb01@github.com>
Message-ID: <b7sDzWqPZXDjjRuJiJZd9rbZUFTWcjDwHVin_CYZsxA=.b329d3fa-c830-4da5-aad9-171e0560f798@github.com>

On Wed, 30 Dec 2020 22:40:13 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup variable and useless test code.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 244:
> 
>> 242:             // array clone can be qualified by the array type in later targets
>> 243:             if (qualifiedSymbolCache == null) {
>> 244:                 qualifiedSymbolCache = new HashMap<>();
> 
> given that the map is initialized in the constructor I assume that this line should never be executed right? also I think that  you can clear the map in the `finally` block of method `Gen::genClass`

I assumed that other developers will revise `qualifiedSymbolCache` elsewhere in the future. So I judge if it is null to avoid NPE.  The newly added code in the finally block of `Gen::genClass`  states that this judgement is necessary.

> test/langtools/tools/javac/classfiles/T8255757/T8255757.java line 77:
> 
>> 75:                 .outdir(curPath)
>> 76:                 .run()
>> 77:                 .writeAll();
> 
> nit: I think that invoking the `writeAll` method is not necessary as the output is discarded, so it can be removed from the chain

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1912

From vromero at openjdk.java.net  Thu Dec 31 15:34:57 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 31 Dec 2020 15:34:57 GMT
Subject: RFR: 8255757: Javac emits duplicate pool entries on array::clone
 [v2]
In-Reply-To: <95Ede01CrNWuZSDy6iYKbOxf0e6TT5wlNXCwvGkgpBE=.c8b85fb8-1590-423b-b2d2-74dd09f6e306@github.com>
References: <MuCBQnk3OEDrxF4QVee3M2FpsYYQjPaq_0xZ-RBzBRs=.2ddd46e4-8d39-46be-afd6-e9d0198ba539@github.com>
 <95Ede01CrNWuZSDy6iYKbOxf0e6TT5wlNXCwvGkgpBE=.c8b85fb8-1590-423b-b2d2-74dd09f6e306@github.com>
Message-ID: <5Ify5MwZfTJGus3Cp5IuWNJAdCq83brrf4Sozeg1s5A=.90cae5d2-4ddf-4ef5-99ff-d9ac99c4380b@github.com>

On Thu, 31 Dec 2020 10:05:19 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi all,
>> 
>> Currently, javac would emit duplicate pool entries when compiling array::clone.
>> This patch fixes it by using a cached field `Map<Type, Symbol> qualifiedSymbolCache;` and adds a corresponding test case.
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup variable and useless test code.

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 2433:

> 2431:             endPosTable = null;
> 2432:             nerrs = 0;
> 2433:             qualifiedSymbolCache = null;

I meant `qualifiedSymbolCache.clear()` instead of assigning null to it

-------------

PR: https://git.openjdk.java.net/jdk/pull/1912

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Dec 31 16:03:15 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 31 Dec 2020 16:03:15 GMT
Subject: RFR: 8255757: Javac emits duplicate pool entries on array::clone
 [v3]
In-Reply-To: <MuCBQnk3OEDrxF4QVee3M2FpsYYQjPaq_0xZ-RBzBRs=.2ddd46e4-8d39-46be-afd6-e9d0198ba539@github.com>
References: <MuCBQnk3OEDrxF4QVee3M2FpsYYQjPaq_0xZ-RBzBRs=.2ddd46e4-8d39-46be-afd6-e9d0198ba539@github.com>
Message-ID: <1emE2SMPj-xOWirhYjekcvC90xjeXRnyGsPAWBXDDRc=.aecc36e2-71ff-4ef5-919e-bffd2926bf9a@github.com>

> Hi all,
> 
> Currently, javac would emit duplicate pool entries when compiling array::clone.
> This patch fixes it by using a cached field `Map<Type, Symbol> qualifiedSymbolCache;` and adds a corresponding test case.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Use Map::clear

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1912/files
  - new: https://git.openjdk.java.net/jdk/pull/1912/files/1ab79ce1..d59ed82f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1912&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1912&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1912.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1912/head:pull/1912

PR: https://git.openjdk.java.net/jdk/pull/1912

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Dec 31 16:03:16 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 31 Dec 2020 16:03:16 GMT
Subject: RFR: 8255757: Javac emits duplicate pool entries on array::clone
 [v2]
In-Reply-To: <N5N_fJE0P5MBivbolebFNWZp176WTjJ6PgNEJC3fd8Y=.9a6292a5-9f3a-4552-812f-caa98970ec30@github.com>
References: <MuCBQnk3OEDrxF4QVee3M2FpsYYQjPaq_0xZ-RBzBRs=.2ddd46e4-8d39-46be-afd6-e9d0198ba539@github.com>
 <95Ede01CrNWuZSDy6iYKbOxf0e6TT5wlNXCwvGkgpBE=.c8b85fb8-1590-423b-b2d2-74dd09f6e306@github.com>
 <5Ify5MwZfTJGus3Cp5IuWNJAdCq83brrf4Sozeg1s5A=.90cae5d2-4ddf-4ef5-99ff-d9ac99c4380b@github.com>
 <N5N_fJE0P5MBivbolebFNWZp176WTjJ6PgNEJC3fd8Y=.9a6292a5-9f3a-4552-812f-caa98970ec30@github.com>
Message-ID: <n-H1wJUwAPj-E5b4MVOQa9Fh5SfnB_gXipa56tnogcQ=.86d70ab8-1c73-4c09-8e38-ae61d98152d7@github.com>

On Thu, 31 Dec 2020 15:57:28 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 2433:
>> 
>>> 2431:             endPosTable = null;
>>> 2432:             nerrs = 0;
>>> 2433:             qualifiedSymbolCache = null;
>> 
>> I meant `qualifiedSymbolCache.clear()` instead of assigning null to it
>
> If we use `qualifiedSymbolCache.clear()`, maybe it is good to remove the following code currently. 
> 
> if (qualifiedSymbolCache == null) {
>                 qualifiedSymbolCache = new HashMap<>();
> }
> 
> If the `qualifiedSymbolCache` is revised elsewhere in the future, more attention should be paid.

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1912

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Dec 31 16:03:16 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 31 Dec 2020 16:03:16 GMT
Subject: RFR: 8255757: Javac emits duplicate pool entries on array::clone
 [v2]
In-Reply-To: <5Ify5MwZfTJGus3Cp5IuWNJAdCq83brrf4Sozeg1s5A=.90cae5d2-4ddf-4ef5-99ff-d9ac99c4380b@github.com>
References: <MuCBQnk3OEDrxF4QVee3M2FpsYYQjPaq_0xZ-RBzBRs=.2ddd46e4-8d39-46be-afd6-e9d0198ba539@github.com>
 <95Ede01CrNWuZSDy6iYKbOxf0e6TT5wlNXCwvGkgpBE=.c8b85fb8-1590-423b-b2d2-74dd09f6e306@github.com>
 <5Ify5MwZfTJGus3Cp5IuWNJAdCq83brrf4Sozeg1s5A=.90cae5d2-4ddf-4ef5-99ff-d9ac99c4380b@github.com>
Message-ID: <N5N_fJE0P5MBivbolebFNWZp176WTjJ6PgNEJC3fd8Y=.9a6292a5-9f3a-4552-812f-caa98970ec30@github.com>

On Thu, 31 Dec 2020 15:31:38 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup variable and useless test code.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 2433:
> 
>> 2431:             endPosTable = null;
>> 2432:             nerrs = 0;
>> 2433:             qualifiedSymbolCache = null;
> 
> I meant `qualifiedSymbolCache.clear()` instead of assigning null to it

If we use `qualifiedSymbolCache.clear()`, maybe it is good to remove the following code currently. 

if (qualifiedSymbolCache == null) {
                qualifiedSymbolCache = new HashMap<>();
}

If the `qualifiedSymbolCache` is revised elsewhere in the future, more attention should be paid.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1912

From vromero at openjdk.java.net  Thu Dec 31 16:33:58 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Thu, 31 Dec 2020 16:33:58 GMT
Subject: RFR: 8255757: Javac emits duplicate pool entries on array::clone
 [v3]
In-Reply-To: <1emE2SMPj-xOWirhYjekcvC90xjeXRnyGsPAWBXDDRc=.aecc36e2-71ff-4ef5-919e-bffd2926bf9a@github.com>
References: <MuCBQnk3OEDrxF4QVee3M2FpsYYQjPaq_0xZ-RBzBRs=.2ddd46e4-8d39-46be-afd6-e9d0198ba539@github.com>
 <1emE2SMPj-xOWirhYjekcvC90xjeXRnyGsPAWBXDDRc=.aecc36e2-71ff-4ef5-919e-bffd2926bf9a@github.com>
Message-ID: <St10DaMGjeST87NU0ABZGQ3ZGb_OcKnuISKTa7Yic8g=.d8fcf34b-9b82-4f65-8fff-6e5dd7637ba7@github.com>

On Thu, 31 Dec 2020 16:03:15 GMT, Guoxiong Li <github.com+13688759+lgxbslgx at openjdk.org> wrote:

>> Hi all,
>> 
>> Currently, javac would emit duplicate pool entries when compiling array::clone.
>> This patch fixes it by using a cached field `Map<Type, Symbol> qualifiedSymbolCache;` and adds a corresponding test case.
>> 
>> Thank you for taking the time to review.
>> 
>> Best Regards.
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Map::clear

Marked as reviewed by vromero (Reviewer).

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 47:

> 45: import com.sun.tools.javac.tree.JCTree.*;
> 46: 
> 47: import java.util.HashMap;

sorry one final matter of style these imports should come first before all the `com.sun.tools.javac.*` ones, there is no need for another review iteration just please fix it before integrating. Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/1912

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Dec 31 16:50:22 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 31 Dec 2020 16:50:22 GMT
Subject: RFR: 8255757: Javac emits duplicate pool entries on array::clone
 [v4]
In-Reply-To: <MuCBQnk3OEDrxF4QVee3M2FpsYYQjPaq_0xZ-RBzBRs=.2ddd46e4-8d39-46be-afd6-e9d0198ba539@github.com>
References: <MuCBQnk3OEDrxF4QVee3M2FpsYYQjPaq_0xZ-RBzBRs=.2ddd46e4-8d39-46be-afd6-e9d0198ba539@github.com>
Message-ID: <eKUtm4BB5aRQFxPGTG8NTD6h_4OO5762xHRsueGlmo0=.9067838d-19af-4c75-a46c-6735182afa15@github.com>

> Hi all,
> 
> Currently, javac would emit duplicate pool entries when compiling array::clone.
> This patch fixes it by using a cached field `Map<Type, Symbol> qualifiedSymbolCache;` and adds a corresponding test case.
> 
> Thank you for taking the time to review.
> 
> Best Regards.

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Fix copyright. Adjust import statements.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1912/files
  - new: https://git.openjdk.java.net/jdk/pull/1912/files/d59ed82f..3ecbe6f2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1912&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1912&range=02-03

  Stats: 7 lines in 1 file changed: 3 ins; 3 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1912.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1912/head:pull/1912

PR: https://git.openjdk.java.net/jdk/pull/1912

From github.com+13688759+lgxbslgx at openjdk.java.net  Thu Dec 31 16:50:23 2020
From: github.com+13688759+lgxbslgx at openjdk.java.net (Guoxiong Li)
Date: Thu, 31 Dec 2020 16:50:23 GMT
Subject: RFR: 8255757: Javac emits duplicate pool entries on array::clone
 [v3]
In-Reply-To: <St10DaMGjeST87NU0ABZGQ3ZGb_OcKnuISKTa7Yic8g=.d8fcf34b-9b82-4f65-8fff-6e5dd7637ba7@github.com>
References: <MuCBQnk3OEDrxF4QVee3M2FpsYYQjPaq_0xZ-RBzBRs=.2ddd46e4-8d39-46be-afd6-e9d0198ba539@github.com>
 <1emE2SMPj-xOWirhYjekcvC90xjeXRnyGsPAWBXDDRc=.aecc36e2-71ff-4ef5-919e-bffd2926bf9a@github.com>
 <St10DaMGjeST87NU0ABZGQ3ZGb_OcKnuISKTa7Yic8g=.d8fcf34b-9b82-4f65-8fff-6e5dd7637ba7@github.com>
Message-ID: <Hj13tP3xSlpN7zRuFS9DqTurmRZ1xW0csJBKpzxPOeo=.af3f4ac5-9c2e-4d7a-aaaa-38e41cb6d785@github.com>

On Thu, 31 Dec 2020 16:31:33 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use Map::clear
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java line 47:
> 
>> 45: import com.sun.tools.javac.tree.JCTree.*;
>> 46: 
>> 47: import java.util.HashMap;
> 
> sorry one final matter of style these imports should come first before all the `com.sun.tools.javac.*` ones, there is no need for another review iteration just please fix it before integrating. Thanks!

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1912