From forax at univ-mlv.fr  Fri Jan  1 14:52:31 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 1 Jan 2021 15:52:31 +0100 (CET)
Subject: Record constructor using Objects.requireNonNull
In-Reply-To: <c439cc3c-a3ba-1bf3-b767-eeabb020cd26@oracle.com>
References: <CAJi8+g7SZuYYG4ofeyBkbZNKYGEp_71csDpgPEjfopH6s4S_7g@mail.gmail.com>
 <c439cc3c-a3ba-1bf3-b767-eeabb020cd26@oracle.com>
Message-ID: <1630449433.400153.1609512751321.JavaMail.zimbra@u-pem.fr>

Yes,
definitively a bug !

R?mi

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> ?: "Christian Stein" <sormuras at gmail.com>, "amber-dev" <amber-dev at openjdk.java.net>
> Envoy?: Jeudi 31 D?cembre 2020 23:09:14
> Objet: Re: Record constructor using Objects.requireNonNull

> Looks like a bug.
> 
> On 12/31/2020 1:22 PM, Christian Stein wrote:
>> Hi,
>>
>> Sascha's finding [1] applied to all requireNonNull variants of
>> java.util.Objects
>>
>>    import static java.util.Objects.*;
>>    record Test(String v) {
>>      Test {
>>        requireNonNull(v);
>>        requireNonNull(v, "v must be provided");
>>        // requireNonNull(v, () -> "v must be provided");
>>        requireNonNullElse(v, "w");
>>        // requireNonNullElseGet(v, () -> "w");
>>      }
>>    }
>>
>> leads to this error message after uncommenting one or both of the
>> supplier-taking lines:
>>
>>    Test.java:2: error: invalid compact constructor in record <init>
>>      Test {
>>      ^
>>    (compact constructor must not have return statements)
>>    1 error
>>
>> I ran javac from 16-ea+27 and 17-ea+3.
>>
>> Shall I create an issue for this at https://bugs.openjdk.java.net or is
>> this an expected behaviour?
>>
>> Cheers,
>> Christian
>>
> > [1]: https://twitter.com/skohlmann/status/1344684426836500480

From lgxbslgx at gmail.com  Fri Jan  1 17:20:29 2021
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Sat, 2 Jan 2021 01:20:29 +0800
Subject: Record constructor using Objects.requireNonNull
In-Reply-To: <1630449433.400153.1609512751321.JavaMail.zimbra@u-pem.fr>
References: <CAJi8+g7SZuYYG4ofeyBkbZNKYGEp_71csDpgPEjfopH6s4S_7g@mail.gmail.com>
 <c439cc3c-a3ba-1bf3-b767-eeabb020cd26@oracle.com>
 <1630449433.400153.1609512751321.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAPSsVqi-uNUrgq61Pv_LHxBtiiU4zXC-COEFPE6cJ-LybMLQbA@mail.gmail.com>

Hi,

Good catch! I saw Christian filed an issue in bug tracker. Please see
https://bugs.openjdk.java.net/browse/JDK-8259025
And I have a little patch to fix this bug locally. Could I ask you which
repository should I submit the PR? JDK main-line or JDK 16? I think JDK 16
is better.

The patch is shown below for you, excluding a corresponding test case.

diff --git
a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
index e09f274309c..bae2221549e 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
@@ -2962,7 +2962,6 @@ public class Attr extends JCTree.Visitor {
                 localEnv.info.isSerializable = true;
                 localEnv.info.isSerializableLambda = true;
             }
-            localEnv.info.isLambda = true;
             List<Type> explicitParamTypes = null;
             if (that.paramKind == JCLambda.ParameterKind.EXPLICIT) {
                 //attribute lambda parameters
@@ -3404,6 +3403,7 @@ public class Attr extends JCTree.Visitor {
                 lambdaEnv = env.dup(that,
env.info.dup(env.info.scope.dup()));
             }
             lambdaEnv.info.yieldResult = null;
+            lambdaEnv.info.isLambda = true;
             return lambdaEnv;
         }


On Fri, Jan 1, 2021 at 10:54 PM Remi Forax <forax at univ-mlv.fr> wrote:

> Yes,
> definitively a bug !
>
> R?mi
>
> ----- Mail original -----
> > De: "Brian Goetz" <brian.goetz at oracle.com>
> > ?: "Christian Stein" <sormuras at gmail.com>, "amber-dev" <
> amber-dev at openjdk.java.net>
> > Envoy?: Jeudi 31 D?cembre 2020 23:09:14
> > Objet: Re: Record constructor using Objects.requireNonNull
>
> > Looks like a bug.
> >
> > On 12/31/2020 1:22 PM, Christian Stein wrote:
> >> Hi,
> >>
> >> Sascha's finding [1] applied to all requireNonNull variants of
> >> java.util.Objects
> >>
> >>    import static java.util.Objects.*;
> >>    record Test(String v) {
> >>      Test {
> >>        requireNonNull(v);
> >>        requireNonNull(v, "v must be provided");
> >>        // requireNonNull(v, () -> "v must be provided");
> >>        requireNonNullElse(v, "w");
> >>        // requireNonNullElseGet(v, () -> "w");
> >>      }
> >>    }
> >>
> >> leads to this error message after uncommenting one or both of the
> >> supplier-taking lines:
> >>
> >>    Test.java:2: error: invalid compact constructor in record <init>
> >>      Test {
> >>      ^
> >>    (compact constructor must not have return statements)
> >>    1 error
> >>
> >> I ran javac from 16-ea+27 and 17-ea+3.
> >>
> >> Shall I create an issue for this at https://bugs.openjdk.java.net or is
> >> this an expected behaviour?
> >>
> >> Cheers,
> >> Christian
> >>
> > > [1]: https://twitter.com/skohlmann/status/1344684426836500480
>

From lgxbslgx at gmail.com  Sat Jan  2 12:38:29 2021
From: lgxbslgx at gmail.com (Guoxiong Li)
Date: Sat, 2 Jan 2021 20:38:29 +0800
Subject: Record constructor using Objects.requireNonNull
In-Reply-To: <CAPSsVqi-uNUrgq61Pv_LHxBtiiU4zXC-COEFPE6cJ-LybMLQbA@mail.gmail.com>
References: <CAJi8+g7SZuYYG4ofeyBkbZNKYGEp_71csDpgPEjfopH6s4S_7g@mail.gmail.com>
 <c439cc3c-a3ba-1bf3-b767-eeabb020cd26@oracle.com>
 <1630449433.400153.1609512751321.JavaMail.zimbra@u-pem.fr>
 <CAPSsVqi-uNUrgq61Pv_LHxBtiiU4zXC-COEFPE6cJ-LybMLQbA@mail.gmail.com>
Message-ID: <CAPSsVqj1MG_VQEFp-MuZ9k_nymSVWtHDdK8XJXxoY7zUDB0nZw@mail.gmail.com>

Hi all,

I submitted a PR to JDK main-line to solve this bug. Please see
https://github.com/openjdk/jdk/pull/1917
I would like to let the corresponding reviewers decide whether it should be
backported to JDK 16.

Best Regards.


On Sat, Jan 2, 2021 at 1:20 AM Guoxiong Li <lgxbslgx at gmail.com> wrote:

> Hi,
>
> Good catch! I saw Christian filed an issue in bug tracker. Please see
> https://bugs.openjdk.java.net/browse/JDK-8259025
> And I have a little patch to fix this bug locally. Could I ask you which
> repository should I submit the PR? JDK main-line or JDK 16? I think JDK 16
> is better.
>
> The patch is shown below for you, excluding a corresponding test case.
>
> diff --git
> a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> index e09f274309c..bae2221549e 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
> @@ -2962,7 +2962,6 @@ public class Attr extends JCTree.Visitor {
>                  localEnv.info.isSerializable = true;
>                  localEnv.info.isSerializableLambda = true;
>              }
> -            localEnv.info.isLambda = true;
>              List<Type> explicitParamTypes = null;
>              if (that.paramKind == JCLambda.ParameterKind.EXPLICIT) {
>                  //attribute lambda parameters
> @@ -3404,6 +3403,7 @@ public class Attr extends JCTree.Visitor {
>                  lambdaEnv = env.dup(that,
> env.info.dup(env.info.scope.dup()));
>              }
>              lambdaEnv.info.yieldResult = null;
> +            lambdaEnv.info.isLambda = true;
>              return lambdaEnv;
>          }
>
>
> On Fri, Jan 1, 2021 at 10:54 PM Remi Forax <forax at univ-mlv.fr> wrote:
>
>> Yes,
>> definitively a bug !
>>
>> R?mi
>>
>> ----- Mail original -----
>> > De: "Brian Goetz" <brian.goetz at oracle.com>
>> > ?: "Christian Stein" <sormuras at gmail.com>, "amber-dev" <
>> amber-dev at openjdk.java.net>
>> > Envoy?: Jeudi 31 D?cembre 2020 23:09:14
>> > Objet: Re: Record constructor using Objects.requireNonNull
>>
>> > Looks like a bug.
>> >
>> > On 12/31/2020 1:22 PM, Christian Stein wrote:
>> >> Hi,
>> >>
>> >> Sascha's finding [1] applied to all requireNonNull variants of
>> >> java.util.Objects
>> >>
>> >>    import static java.util.Objects.*;
>> >>    record Test(String v) {
>> >>      Test {
>> >>        requireNonNull(v);
>> >>        requireNonNull(v, "v must be provided");
>> >>        // requireNonNull(v, () -> "v must be provided");
>> >>        requireNonNullElse(v, "w");
>> >>        // requireNonNullElseGet(v, () -> "w");
>> >>      }
>> >>    }
>> >>
>> >> leads to this error message after uncommenting one or both of the
>> >> supplier-taking lines:
>> >>
>> >>    Test.java:2: error: invalid compact constructor in record <init>
>> >>      Test {
>> >>      ^
>> >>    (compact constructor must not have return statements)
>> >>    1 error
>> >>
>> >> I ran javac from 16-ea+27 and 17-ea+3.
>> >>
>> >> Shall I create an issue for this at https://bugs.openjdk.java.net or
>> is
>> >> this an expected behaviour?
>> >>
>> >> Cheers,
>> >> Christian
>> >>
>> > > [1]: https://twitter.com/skohlmann/status/1344684426836500480
>>
>

From sirinath1978m at gmail.com  Wed Jan  6 05:44:36 2021
From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena)
Date: Wed, 6 Jan 2021 11:14:36 +0530
Subject: Array patterns (and varargs patterns)
In-Reply-To: <CAAfFNYF5bjeGeb1nhaUpmnY641cHxxa16GKAN1c6DwNY8g0Paw@mail.gmail.com>
References: <5f55e727-8a29-3bdf-57ec-6ec6245ef5c5@oracle.com>
 <CAAfFNYF5bjeGeb1nhaUpmnY641cHxxa16GKAN1c6DwNY8g0Paw@mail.gmail.com>
Message-ID: <CAAfFNYHX3MuhtpGM4qu6E+Rg7KQ9226d+Qa88rSZCUExX9DTKg@mail.gmail.com>

Can we have something like:

        if (arr instanceof String[] { var a, var b, ... } stringArray) {
... }

`stringArray` is optional but if present this will referrer to the whole
array.

>

From gavin.bierman at oracle.com  Wed Jan  6 10:01:35 2021
From: gavin.bierman at oracle.com (Gavin Bierman)
Date: Wed, 6 Jan 2021 10:01:35 +0000
Subject: Array patterns (and varargs patterns)
In-Reply-To: <CAAfFNYHX3MuhtpGM4qu6E+Rg7KQ9226d+Qa88rSZCUExX9DTKg@mail.gmail.com>
References: <5f55e727-8a29-3bdf-57ec-6ec6245ef5c5@oracle.com>
 <CAAfFNYF5bjeGeb1nhaUpmnY641cHxxa16GKAN1c6DwNY8g0Paw@mail.gmail.com>
 <CAAfFNYHX3MuhtpGM4qu6E+Rg7KQ9226d+Qa88rSZCUExX9DTKg@mail.gmail.com>
Message-ID: <D542D6C8-4C46-4F4D-8852-BF36D705AD60@oracle.com>

This is a feature that other languages call an ?as pattern?, because you are adding a new pattern variable binding to another pattern (Standard ML used ?as?, Haskell uses ?@? but calls it an as pattern). It?s on our list of things to consider; part of the consideration is whether it merits special syntax along with the parsing issues of not having special syntax.

Gavin

> On 6 Jan 2021, at 05:44, Suminda Sirinath Salpitikorala Dharmasena <sirinath1978m at gmail.com> wrote:
> 
> Can we have something like:
> 
>        if (arr instanceof String[] { var a, var b, ... } stringArray) {
> ... }
> 
> `stringArray` is optional but if present this will referrer to the whole
> array.
> 
>> 


From bsrbnd at gmail.com  Wed Jan  6 13:02:14 2021
From: bsrbnd at gmail.com (B. Blaser)
Date: Wed, 6 Jan 2021 14:02:14 +0100
Subject: Records, Intersection type and lambda
In-Reply-To: <CAEgw74D3xVQmgOdfe4ByBgZNW9TKOGLJ84CY0QgXXuE3=xGbNg@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>
 <df32ce1d-af2f-0a20-c3af-f56c17c2d203@oracle.com>
 <CAEgw74D3xVQmgOdfe4ByBgZNW9TKOGLJ84CY0QgXXuE3=xGbNg@mail.gmail.com>
Message-ID: <CAEgw74B_Dk_YYu_rc0POD2GdnA-0erqd2u-zK2oukg+Pgjd2uA@mail.gmail.com>

Hi Vicente,

I saw you've integrated the initial fix with no additional change
which seems reasonable.

However, did you also try the example I provided below as I'm not
absolutely sure this works?
Otherwise, you may look at the experimental fix I suggested.

Thanks,
Bernard

On Sun, 27 Dec 2020 at 22:31, B. Blaser <bsrbnd at gmail.com> wrote:
>
> 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 sirinath1978m at gmail.com  Wed Jan  6 15:38:29 2021
From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena)
Date: Wed, 6 Jan 2021 21:08:29 +0530
Subject: Array patterns (and varargs patterns)
In-Reply-To: <D542D6C8-4C46-4F4D-8852-BF36D705AD60@oracle.com>
References: <5f55e727-8a29-3bdf-57ec-6ec6245ef5c5@oracle.com>
 <CAAfFNYF5bjeGeb1nhaUpmnY641cHxxa16GKAN1c6DwNY8g0Paw@mail.gmail.com>
 <CAAfFNYHX3MuhtpGM4qu6E+Rg7KQ9226d+Qa88rSZCUExX9DTKg@mail.gmail.com>
 <D542D6C8-4C46-4F4D-8852-BF36D705AD60@oracle.com>
Message-ID: <CAAfFNYEXye1TX-6ax0BzZc+5zvX1=AF9N=LqfXRvG1B_CaLs5A@mail.gmail.com>

Other languages have patent matching on head and tail of lists. Adding this
may mean there should be additional syntax. So for the time being simplest
is the ability to match 1st few elements and the whole array like what I
have given below if it can be supported:

       if (arr instanceof String[] { var a, var b, ... } stringArray) { ...
}

Another issue is if the array is shorter say 0 length and one has:

       if (arr instanceof int[] { var a, var b, ... }) { ... }

Will this be an ArrayIndexOutOfBoundException or another exception? If it
is a reference type `a` and `b` can be null.



On Wed, 6 Jan 2021 at 15:31, Gavin Bierman <gavin.bierman at oracle.com> wrote:

> This is a feature that other languages call an ?as pattern?, because you
> are adding a new pattern variable binding to another pattern (Standard ML
> used ?as?, Haskell uses ?@? but calls it an as pattern). It?s on our list
> of things to consider; part of the consideration is whether it merits
> special syntax along with the parsing issues of not having special syntax.
>
> Gavin
>
> > On 6 Jan 2021, at 05:44, Suminda Sirinath Salpitikorala Dharmasena <
> sirinath1978m at gmail.com> wrote:
> >
> > Can we have something like:
> >
> >        if (arr instanceof String[] { var a, var b, ... } stringArray) {
> > ... }
> >
> > `stringArray` is optional but if present this will referrer to the whole
> > array.
> >
> >>
>
>

From brian.goetz at oracle.com  Wed Jan  6 16:43:53 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 6 Jan 2021 11:43:53 -0500
Subject: Array patterns (and varargs patterns)
In-Reply-To: <CAAfFNYEXye1TX-6ax0BzZc+5zvX1=AF9N=LqfXRvG1B_CaLs5A@mail.gmail.com>
References: <5f55e727-8a29-3bdf-57ec-6ec6245ef5c5@oracle.com>
 <CAAfFNYF5bjeGeb1nhaUpmnY641cHxxa16GKAN1c6DwNY8g0Paw@mail.gmail.com>
 <CAAfFNYHX3MuhtpGM4qu6E+Rg7KQ9226d+Qa88rSZCUExX9DTKg@mail.gmail.com>
 <D542D6C8-4C46-4F4D-8852-BF36D705AD60@oracle.com>
 <CAAfFNYEXye1TX-6ax0BzZc+5zvX1=AF9N=LqfXRvG1B_CaLs5A@mail.gmail.com>
Message-ID: <68b0c3fc-d0c5-13c7-5306-ac0b7b829ca0@oracle.com>



> Other languages have patent?matching on head and tail of lists. Adding 
> this may mean there should be additional?syntax.

I alluded to this in my mail, hoping that people wouldn't allow 
themselves to be distracted by this particular siren song:

<digression>
People are immediately going to ask "can I bind something to the 
remainder"; I think this is mostly an "attractive distraction", and 
would prefer to not have this dominate the discussion.
</digression>

The idiom of "match a list by matching (head, tail)", which works great 
in Lisp and Haskell, is that (a) the representation of lists in Lisp and 
Haskell is a cons-cell, and (b) these language have tail-call 
elimination, so that processing a list by recursion in this manner is 
natural, efficient, and doesn't SOE.? Java has neither of these, so 
grafting the illusion of this model when the runtime is not suited to it 
is just moving the problem one foot down the road, but ultimately is not 
going to be satisfying.? The performance will be poor, and we'll SOE on 
lists longer than a few tens of thousands of elements.

The bottom line here is that idioms from Language X are very much 
connected to _the rest of language X_.? Ignoring this rarely works out 
well.

> Another issue is if the array is shorter say 0 length and one has:
>
> ?????? if (arr instanceof int[] { var a, var b, ... }) { ... }
>
> Will this be an ArrayIndexOutOfBoundException or another exception? If 
> it is a reference type `a` and `b` can be null.

No.? Pattern matching is inherently conditional; the match above says 
"does `arr` match this array pattern".? Matching the array pattern means 
being an array, _and_ having the right number of elements, _and_ having 
those elements match the nested patterns. Matching should never throw 
(though, once we allow users to write patterns that have code in them, 
it will be possible to do things like NPE, but those are bugs.)

>
>
> On Wed, 6 Jan 2021 at 15:31, Gavin Bierman <gavin.bierman at oracle.com 
> <mailto:gavin.bierman at oracle.com>> wrote:
>
>     This is a feature that other languages call an ?as pattern?,
>     because you are adding a new pattern variable binding to another
>     pattern (Standard ML used ?as?, Haskell uses ?@? but calls it an
>     as pattern). It?s on our list of things to consider; part of the
>     consideration is whether it merits special syntax along with the
>     parsing issues of not having special syntax.
>
>     Gavin
>
>     > On 6 Jan 2021, at 05:44, Suminda Sirinath Salpitikorala
>     Dharmasena <sirinath1978m at gmail.com
>     <mailto:sirinath1978m at gmail.com>> wrote:
>     >
>     > Can we have something like:
>     >
>     >? ? ? ? if (arr instanceof String[] { var a, var b, ... }
>     stringArray) {
>     > ... }
>     >
>     > `stringArray` is optional but if present this will referrer to
>     the whole
>     > array.
>     >
>     >>
>


From duke at openjdk.java.net  Wed Jan  6 20:51:55 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 6 Jan 2021 20:51:55 GMT
Subject: git: openjdk/amber-docs: Add Pattern Matching in the Java Object
 model doc
Message-ID: <b2711a09-96fa-442d-ba14-2227c2b34621@openjdk.java.net>

Changeset: 54ee5b1a
Author:    briangoetz <brian at briangoetz.com>
Date:      2021-01-06 15:51:10 +0000
URL:       https://git.openjdk.java.net/amber-docs/commit/54ee5b1a

Add Pattern Matching in the Java Object model doc

! Makefile
! site/design-notes/extending-switch-for-patterns.md
+ site/design-notes/pattern-match-object-model.md
! site/design-notes/pattern-match-semantics.md
! site/design-notes/pattern-matching-for-java.md
! site/design-notes/records-and-sealed-classes.md
! site/design-notes/type-patterns-in-switch.md


From duke at openjdk.java.net  Wed Jan  6 21:12:05 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 6 Jan 2021 21:12:05 GMT
Subject: git: openjdk/amber-docs: Style sheet updates
Message-ID: <d2d54fbe-1ab5-4ac2-825a-77423a69abf2@openjdk.java.net>

Changeset: dd905745
Author:    briangoetz <brian at briangoetz.com>
Date:      2021-01-06 16:11:41 +0000
URL:       https://git.openjdk.java.net/amber-docs/commit/dd905745

Style sheet updates

! style.css


From duke at openjdk.java.net  Thu Jan  7 22:06:19 2021
From: duke at openjdk.java.net (duke)
Date: Thu, 7 Jan 2021 22:06:19 GMT
Subject: git: openjdk/amber: concise-method-declarations: 75 new changesets
Message-ID: <66e678d0-2dd9-4762-b10e-2b94e0a16856@openjdk.org>

Changeset: 497efefa
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2021-01-03 05:08:48 +0000
URL:       https://git.openjdk.java.net/amber/commit/497efefa

8225116: Test OwnedWindowsLeak.java intermittently fails

Reviewed-by: pbansal

! test/jdk/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java

Changeset: 526c0005
Author:    Guoxiong Li <lgxbslgx at gmail.com>
Committer: Jonathan Gibbons <jjg at openjdk.org>
Date:      2021-01-03 17:32:46 +0000
URL:       https://git.openjdk.java.net/amber/commit/526c0005

8255729: com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient

Reviewed-by: jjg

! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacFiler.java

Changeset: f351e155
Author:    Hao Sun <hao.sun at arm.com>
Committer: Ningsheng Jian <njian at openjdk.org>
Date:      2021-01-04 02:21:58 +0000
URL:       https://git.openjdk.java.net/amber/commit/f351e155

8258382: Fix optimization-unstable code involving pointer overflow

Reviewed-by: kbarrett

! src/hotspot/share/gc/parallel/psPromotionLAB.hpp
! src/hotspot/share/gc/parallel/psPromotionLAB.inline.hpp

Changeset: a2a3f4a3
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2021-01-04 04:33:30 +0000
URL:       https://git.openjdk.java.net/amber/commit/a2a3f4a3

8258924: javax/swing/JSplitPane/4201995/bug4201995.java fails in GTk L&F

Reviewed-by: serb

! test/jdk/ProblemList.txt
! test/jdk/javax/swing/JSplitPane/4201995/bug4201995.java

Changeset: d679caa2
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2021-01-04 06:35:37 +0000
URL:       https://git.openjdk.java.net/amber/commit/d679caa2

8196466: javax/swing/JFileChooser/8062561/bug8062561.java fails

Reviewed-by: serb

! test/jdk/ProblemList.txt

Changeset: 7f04d23b
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2021-01-04 16:44:39 +0000
URL:       https://git.openjdk.java.net/amber/commit/7f04d23b

8258800: Deprecate -XX:+AlwaysLockClassLoader

Reviewed-by: hseigel

! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/globals.hpp

Changeset: f80c63b3
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2021-01-04 18:10:36 +0000
URL:       https://git.openjdk.java.net/amber/commit/f80c63b3

8258490: Shenandoah: Full GC does not need to remark threads and drain SATB buffers

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp

Changeset: 9d160aa1
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2021-01-04 21:01:25 +0000
URL:       https://git.openjdk.java.net/amber/commit/9d160aa1

8257815: Replace global log2 functions with efficient implementations

Reviewed-by: kbarrett, stefank

! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/z/zGlobals_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp
! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp
! src/hotspot/cpu/ppc/assembler_ppc.cpp
! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp
! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp
! src/hotspot/cpu/ppc/ppc.ad
! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
! src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp
! src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp
! src/hotspot/cpu/x86/gc/z/zGlobals_x86.cpp
! src/hotspot/cpu/x86/interp_masm_x86.cpp
! src/hotspot/cpu/x86/vm_version_x86.cpp
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/compiler/compilationPolicy.cpp
! src/hotspot/share/compiler/compilerDefinitions.cpp
! src/hotspot/share/compiler/tieredThresholdPolicy.cpp
! src/hotspot/share/gc/g1/g1BiasedArray.hpp
! src/hotspot/share/gc/g1/g1FreeIdSet.cpp
! src/hotspot/share/gc/g1/g1RemSet.cpp
! src/hotspot/share/gc/g1/heapRegion.cpp
! src/hotspot/share/gc/g1/heapRegionRemSet.cpp
! src/hotspot/share/gc/shared/partialArrayTaskStepper.cpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahNumberSeq.cpp
! src/hotspot/share/gc/z/zHeuristics.cpp
! src/hotspot/share/opto/divnode.cpp
! src/hotspot/share/opto/mulnode.cpp
! src/hotspot/share/opto/parse2.cpp
! src/hotspot/share/opto/vectorIntrinsics.cpp
! src/hotspot/share/utilities/globalDefinitions.hpp
! src/hotspot/share/utilities/hashtable.cpp
! src/hotspot/share/utilities/powerOfTwo.hpp
! test/hotspot/gtest/utilities/test_globalDefinitions.cpp
! test/hotspot/gtest/utilities/test_powerOfTwo.cpp

Changeset: e6f99260
Author:    Phil Race <prr at openjdk.org>
Date:      2021-01-04 21:09:01 +0000
URL:       https://git.openjdk.java.net/amber/commit/e6f99260

8257809: JNI warnings from Toolkit JPEG image decoding

Reviewed-by: serb

! src/java.desktop/share/native/libjavajpeg/jpegdecoder.c
+ test/jdk/java/awt/image/GetImageJNICheck/GetImageJNICheck.java
+ test/jdk/java/awt/image/GetImageJNICheck/GetImageJNICheck.sh
= test/jdk/java/awt/image/GetImageJNICheck/duke.jpg

Changeset: f0aae81e
Author:    Xin Liu <xliu at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2021-01-04 23:58:53 +0000
URL:       https://git.openjdk.java.net/amber/commit/f0aae81e

8259020: null-check of g1 write_ref_field_pre_entry is not necessary

Reviewed-by: kbarrett, ayang, phh

! src/hotspot/share/gc/g1/g1BarrierSetRuntime.cpp

Changeset: 2499ac3d
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
Date:      2021-01-05 00:11:55 +0000
URL:       https://git.openjdk.java.net/amber/commit/2499ac3d

8259069: Fields could be final

Reviewed-by: wetmore

! src/java.base/share/classes/sun/security/ssl/DHClientKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/EphemeralKeyManager.java
! src/java.base/share/classes/sun/security/ssl/HelloCookieManager.java
! src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java
! src/java.base/share/classes/sun/security/ssl/SSLCipher.java
! src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java
! src/java.base/share/classes/sun/security/ssl/SSLEngineOutputRecord.java
! src/java.base/share/classes/sun/security/ssl/SSLExtensions.java
! src/java.base/share/classes/sun/security/ssl/SSLKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java
! src/java.base/share/classes/sun/security/ssl/SunJSSE.java
! src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java
! src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java

Changeset: 5ea96072
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2021-01-05 05:57:08 +0000
URL:       https://git.openjdk.java.net/amber/commit/5ea96072

8258459: Decouple gc_globals.hpp from globals.hpp

Reviewed-by: lfoltan, coleenp

! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/z/zGlobals_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/z/z_aarch64.ad
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp
! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
! src/hotspot/cpu/arm/c1_Runtime1_arm.cpp
! src/hotspot/cpu/arm/templateTable_arm.cpp
! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
! src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp
! src/hotspot/cpu/s390/templateTable_s390.cpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp
! src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/gc/shenandoah/c1/shenandoahBarrierSetC1_x86.cpp
! src/hotspot/cpu/x86/gc/z/zGlobals_x86.cpp
! src/hotspot/cpu/x86/gc/z/z_x86_64.ad
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/share/aot/aotCodeHeap.cpp
! src/hotspot/share/gc/epsilon/epsilonArguments.cpp
! src/hotspot/share/gc/epsilon/epsilonInitLogger.cpp
! src/hotspot/share/gc/epsilon/epsilonThreadLocalData.hpp
! src/hotspot/share/gc/g1/g1AllocRegion.cpp
! src/hotspot/share/gc/g1/g1Allocator.cpp
! src/hotspot/share/gc/g1/g1Analytics.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1EvacStats.cpp
! src/hotspot/share/gc/g1/g1FromCardCache.cpp
! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp
! src/hotspot/share/gc/g1/g1HeapVerifier.cpp
! src/hotspot/share/gc/g1/g1InitLogger.cpp
! src/hotspot/share/gc/g1/g1ThreadLocalData.hpp
! src/hotspot/share/gc/parallel/jvmFlagConstraintsParallel.cpp
! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp
! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp
! src/hotspot/share/gc/serial/defNewGeneration.hpp
! src/hotspot/share/gc/serial/markSweep.cpp
! src/hotspot/share/gc/shared/ageTable.cpp
! src/hotspot/share/gc/shared/blockOffsetTable.hpp
! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp
! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp
! src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp
! src/hotspot/share/gc/shared/collectedHeap.cpp
! src/hotspot/share/gc/shared/gcConfiguration.cpp
! src/hotspot/share/gc/shared/gcInitLogger.cpp
! src/hotspot/share/gc/shared/gcOverheadChecker.hpp
! src/hotspot/share/gc/shared/gcPolicyCounters.cpp
! src/hotspot/share/gc/shared/gcStats.cpp
! src/hotspot/share/gc/shared/gcVMOperations.cpp
! src/hotspot/share/gc/shared/gc_globals.hpp
! src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp
! src/hotspot/share/gc/shared/memAllocator.cpp
! src/hotspot/share/gc/shared/plab.cpp
! src/hotspot/share/gc/shared/pretouchTask.cpp
! src/hotspot/share/gc/shared/referencePolicy.cpp
! src/hotspot/share/gc/shared/referenceProcessor.cpp
! src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp
! src/hotspot/share/gc/shared/suspendibleThreadSet.cpp
! src/hotspot/share/gc/shared/taskTerminator.cpp
! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp
! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp
! src/hotspot/share/gc/shared/threadLocalAllocBuffer.inline.hpp
+ src/hotspot/share/gc/shared/tlab_globals.hpp
! src/hotspot/share/gc/shared/weakProcessor.cpp
! src/hotspot/share/gc/shared/workerManager.hpp
! src/hotspot/share/gc/shared/workgroup.cpp
! src/hotspot/share/gc/shared/workgroup.hpp
! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp
! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp
! src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp
! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp
! src/hotspot/share/gc/shenandoah/shenandoahWorkerPolicy.cpp
! src/hotspot/share/gc/z/zAddressSpaceLimit.cpp
! src/hotspot/share/gc/z/zDirector.cpp
! src/hotspot/share/gc/z/zHeap.cpp
! src/hotspot/share/gc/z/zHeapIterator.cpp
! src/hotspot/share/gc/z/zHeuristics.cpp
! src/hotspot/share/gc/z/zMarkStackAllocator.cpp
! src/hotspot/share/gc/z/zRelocate.cpp
! src/hotspot/share/gc/z/zRelocationSetSelector.cpp
! src/hotspot/share/gc/z/zRuntimeWorkers.cpp
! src/hotspot/share/gc/z/zStat.cpp
! src/hotspot/share/gc/z/zThreadLocalAllocBuffer.cpp
! src/hotspot/share/gc/z/zUncommitter.cpp
! src/hotspot/share/gc/z/zUnmapper.cpp
! src/hotspot/share/gc/z/zValue.inline.hpp
! src/hotspot/share/gc/z/zVerify.cpp
! src/hotspot/share/gc/z/zWorkers.inline.hpp
! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp
! src/hotspot/share/jfr/leakprofiler/chains/pathToGcRootsOperation.cpp
! src/hotspot/share/jfr/support/jfrObjectAllocationSample.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
! src/hotspot/share/memory/dynamicArchive.cpp
! src/hotspot/share/memory/heapShared.hpp
! src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/oops/oop.cpp
! src/hotspot/share/oops/oop.hpp
! src/hotspot/share/oops/oop.inline.hpp
! src/hotspot/share/opto/arraycopynode.cpp
! src/hotspot/share/opto/lcm.cpp
! src/hotspot/share/opto/macro.cpp
! src/hotspot/share/opto/macroArrayCopy.cpp
! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/flags/allFlags.hpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/interfaceSupport.inline.hpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/thread.inline.hpp
! src/hotspot/share/runtime/threadSMR.inline.hpp
! test/hotspot/gtest/runtime/test_globals.cpp

Changeset: dd8996c5
Author:    Hao Sun <hao.sun at arm.com>
Committer: Ningsheng Jian <njian at openjdk.org>
Date:      2021-01-05 07:31:44 +0000
URL:       https://git.openjdk.java.net/amber/commit/dd8996c5

8258946: Fix optimization-unstable code involving signed integer overflow

Reviewed-by: thartmann, kvn

! src/hotspot/share/opto/ifnode.cpp
! src/hotspot/share/opto/loopTransform.cpp
! src/hotspot/share/opto/parse2.cpp

Changeset: 17d1645e
Author:    Hao Sun <hao.sun at arm.com>
Committer: Ningsheng Jian <njian at openjdk.org>
Date:      2021-01-05 08:29:41 +0000
URL:       https://git.openjdk.java.net/amber/commit/17d1645e

8258751: Improve ExceptionHandlerTable dump

Reviewed-by: thartmann, chagedorn, njian

! src/hotspot/share/code/exceptionHandlerTable.cpp
! src/hotspot/share/code/exceptionHandlerTable.hpp
! src/hotspot/share/code/nmethod.cpp

Changeset: 3817c32f
Author:    Lehua Ding <lehuading at tencent.com>
Committer: Jie Fu <jiefu at openjdk.org>
Date:      2021-01-05 08:34:11 +0000
URL:       https://git.openjdk.java.net/amber/commit/3817c32f

8258534: Epsilon: clean up unused includes

Reviewed-by: shade, jiefu

! src/hotspot/share/gc/epsilon/epsilonArguments.cpp
! src/hotspot/share/gc/epsilon/epsilonBarrierSet.cpp

Changeset: db6f3930
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-05 08:37:06 +0000
URL:       https://git.openjdk.java.net/amber/commit/db6f3930

8251944: Add Shenandoah test config to compiler/gcbarriers/UnsafeIntrinsicsTest.java

Reviewed-by: rkennke, adityam

! test/hotspot/jtreg/compiler/gcbarriers/UnsafeIntrinsicsTest.java

Changeset: 9f151649
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2021-01-05 09:54:18 +0000
URL:       https://git.openjdk.java.net/amber/commit/9f151649

8259049: Uninitialized variable after JDK-8257513

Reviewed-by: kvn, thartmann

! src/hotspot/share/opto/constantTable.cpp

Changeset: a6c08813
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2021-01-05 12:47:33 +0000
URL:       https://git.openjdk.java.net/amber/commit/a6c08813

8256321: Some "inactive" color profiles use the wrong profile class

Reviewed-by: prr

! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java
+ test/jdk/java/awt/color/CheckDefaultProperties.java

Changeset: fc3b45c0
Author:    Alexander Zuev <kizune at openjdk.org>
Date:      2021-01-05 14:46:03 +0000
URL:       https://git.openjdk.java.net/amber/commit/fc3b45c0

8258643: javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button"

Reviewed-by: psadhukhan

! test/jdk/javax/swing/JComponent/7154030/bug7154030.java

Changeset: f4122d6a
Author:    Harold Seigel <hseigel at openjdk.org>
Date:      2021-01-05 16:14:58 +0000
URL:       https://git.openjdk.java.net/amber/commit/f4122d6a

8258896: Remove the JVM ForceFloatExceptions option

Reviewed-by: lfoltan, iklam, coleenp

! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/runtime/globals.hpp

Changeset: 82bdbfd7
Author:    Hao Sun <hao.sun at arm.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-05 16:28:28 +0000
URL:       https://git.openjdk.java.net/amber/commit/82bdbfd7

8258857: Zero: non-PCH release build fails after JDK-8258074

Reviewed-by: jiefu, shade, iklam

! src/hotspot/share/compiler/compiler_globals.hpp

Changeset: d5aa49d1
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2021-01-05 16:41:17 +0000
URL:       https://git.openjdk.java.net/amber/commit/d5aa49d1

8259236: C2 compilation fails with assert(is_power_of_2(value)) failed: value must be a power of 2: 8000000000000000

Reviewed-by: thartmann

! src/hotspot/cpu/x86/x86_64.ad

Changeset: 85bac8c4
Author:    Peter Levart <plevart at openjdk.org>
Date:      2021-01-05 17:41:50 +0000
URL:       https://git.openjdk.java.net/amber/commit/85bac8c4

8259021: SharedSecrets should avoid double racy reads from non-volatile fields

Reviewed-by: shade, redestad, rriggs, mchung, rrich, alanb

! src/java.base/share/classes/jdk/internal/access/SharedSecrets.java

Changeset: 7ddc2b56
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
Date:      2021-01-05 18:29:35 +0000
URL:       https://git.openjdk.java.net/amber/commit/7ddc2b56

8258852: Arrays.asList() for single item could be replaced with List.of()

Reviewed-by: mullan

! src/java.base/share/classes/sun/security/ssl/ClientHello.java
! src/java.base/share/classes/sun/security/ssl/KeyShareExtension.java
! src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java

Changeset: 1b60acd8
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2021-01-05 18:33:41 +0000
URL:       https://git.openjdk.java.net/amber/commit/1b60acd8

8259252: Shenandoah: Shenandoah build failed on AArch64 after JDK-8258459

Reviewed-by: rkennke, shade

! src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp

Changeset: 4d3d5991
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
Date:      2021-01-05 19:32:46 +0000
URL:       https://git.openjdk.java.net/amber/commit/4d3d5991

8259223: Simplify boolean expression in the SunJSSE provider

Reviewed-by: mullan

! src/java.base/share/classes/sun/security/ssl/CipherSuite.java
! src/java.base/share/classes/sun/security/ssl/EphemeralKeyManager.java
! src/java.base/share/classes/sun/security/ssl/Finished.java
! src/java.base/share/classes/sun/security/ssl/HandshakeContext.java
! src/java.base/share/classes/sun/security/ssl/KeyManagerFactoryImpl.java
! src/java.base/share/classes/sun/security/ssl/ProtocolVersion.java
! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java
! src/java.base/share/classes/sun/security/ssl/SignatureScheme.java
! src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java
! src/java.base/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java
! src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java

Changeset: cf9908b4
Author:    Harold Seigel <hseigel at openjdk.org>
Date:      2021-01-05 21:15:13 +0000
URL:       https://git.openjdk.java.net/amber/commit/cf9908b4

8258937: Remove JVM IgnoreRewrites flag

Reviewed-by: coleenp

! src/hotspot/share/oops/generateOopMap.cpp
! src/hotspot/share/runtime/globals.hpp

Changeset: 7d769663
Author:    Guoxiong Li <lgxbslgx at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
Date:      2021-01-05 22:21:19 +0000
URL:       https://git.openjdk.java.net/amber/commit/7d769663

8255757: Javac emits duplicate pool entries on array::clone

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/langtools/tools/javac/classfiles/T8255757/T8255757.java

Changeset: 8b454977
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2021-01-05 22:36:09 +0000
URL:       https://git.openjdk.java.net/amber/commit/8b454977

8259037: livenmethods cannot find hsdis library

Reviewed-by: cjplummer, sspitsyn

! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/asm/Disassembler.java
! src/jdk.hotspot.agent/share/native/libsaproc/sadis.c

Changeset: 52d3feec
Author:    Xiaohong Gong <xgong at openjdk.org>
Committer: Ningsheng Jian <njian at openjdk.org>
Date:      2021-01-06 01:40:34 +0000
URL:       https://git.openjdk.java.net/amber/commit/52d3feec

8258813: [TESTBUG] Fix incorrect Vector API test output message

Reviewed-by: psandoz, njian

! test/jdk/jdk/incubator/vector/AbstractVectorTest.java
! test/jdk/jdk/incubator/vector/Byte128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Byte128VectorTests.java
! test/jdk/jdk/incubator/vector/Byte256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Byte256VectorTests.java
! test/jdk/jdk/incubator/vector/Byte512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Byte512VectorTests.java
! test/jdk/jdk/incubator/vector/Byte64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Byte64VectorTests.java
! test/jdk/jdk/incubator/vector/ByteMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Double128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Double128VectorTests.java
! test/jdk/jdk/incubator/vector/Double256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Double256VectorTests.java
! test/jdk/jdk/incubator/vector/Double512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Double512VectorTests.java
! test/jdk/jdk/incubator/vector/Double64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Double64VectorTests.java
! test/jdk/jdk/incubator/vector/DoubleMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Float128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Float128VectorTests.java
! test/jdk/jdk/incubator/vector/Float256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Float256VectorTests.java
! test/jdk/jdk/incubator/vector/Float512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Float512VectorTests.java
! test/jdk/jdk/incubator/vector/Float64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Float64VectorTests.java
! test/jdk/jdk/incubator/vector/FloatMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Int128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Int128VectorTests.java
! test/jdk/jdk/incubator/vector/Int256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Int256VectorTests.java
! test/jdk/jdk/incubator/vector/Int512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Int512VectorTests.java
! test/jdk/jdk/incubator/vector/Int64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Int64VectorTests.java
! test/jdk/jdk/incubator/vector/IntMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Long128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Long128VectorTests.java
! test/jdk/jdk/incubator/vector/Long256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Long256VectorTests.java
! test/jdk/jdk/incubator/vector/Long512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Long512VectorTests.java
! test/jdk/jdk/incubator/vector/Long64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Long64VectorTests.java
! test/jdk/jdk/incubator/vector/LongMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Short128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Short128VectorTests.java
! test/jdk/jdk/incubator/vector/Short256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Short256VectorTests.java
! test/jdk/jdk/incubator/vector/Short512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Short512VectorTests.java
! test/jdk/jdk/incubator/vector/Short64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Short64VectorTests.java
! test/jdk/jdk/incubator/vector/ShortMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java
! test/jdk/jdk/incubator/vector/VectorReshapeTests.java
! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-Long-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-Masked-Long-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-op-math.template
! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Binary-op-math.template
! test/jdk/jdk/incubator/vector/templates/Unit-Binary-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Blend-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-BoolReduction-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Broadcast.template
! test/jdk/jdk/incubator/vector/templates/Unit-Gather-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Gather-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Get-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Miscellaneous.template
! test/jdk/jdk/incubator/vector/templates/Unit-Rearrange.template
! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-Max-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-Min-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Max-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Min-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Scatter-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Scatter-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Shift-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Shift-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Single-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Slice-Masked-bop.template
! test/jdk/jdk/incubator/vector/templates/Unit-Slice-bop.template
! test/jdk/jdk/incubator/vector/templates/Unit-Slice-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Broadcast-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Broadcast-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Double-Broadcast-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Double-Broadcast-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Unary-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Unary-op-math.template
! test/jdk/jdk/incubator/vector/templates/Unit-Unary-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Unslice-Masked-bop.template
! test/jdk/jdk/incubator/vector/templates/Unit-Unslice-bop.template
! test/jdk/jdk/incubator/vector/templates/Unit-Unslice-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-With-Op.template
! test/jdk/jdk/incubator/vector/templates/Unit-header.template
! test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template

Changeset: 32538b5b
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2021-01-06 06:45:48 +0000
URL:       https://git.openjdk.java.net/amber/commit/32538b5b

8193942: Regression automated test '/open/test/jdk/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java' fails

Reviewed-by: serb

! test/jdk/ProblemList.txt
! test/jdk/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java

Changeset: e3b9da14
Author:    Xin Liu <xliu at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-06 09:51:18 +0000
URL:       https://git.openjdk.java.net/amber/commit/e3b9da14

8259287: AbstractCompiler marks const in wrong position for is_c1/is_c2/is_jvmci

Reviewed-by: thartmann, chagedorn, shade

! src/hotspot/share/compiler/abstractCompiler.hpp

Changeset: 8a05d605
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2021-01-06 10:07:03 +0000
URL:       https://git.openjdk.java.net/amber/commit/8a05d605

8259042: Inconsistent use of general primitives loops

Reviewed-by: prr

! src/java.desktop/share/classes/sun/java2d/loops/Blit.java
! src/java.desktop/share/classes/sun/java2d/loops/BlitBg.java
! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphList.java
! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphListAA.java
! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphListLCD.java
! src/java.desktop/share/classes/sun/java2d/loops/DrawLine.java
! src/java.desktop/share/classes/sun/java2d/loops/DrawParallelogram.java
! src/java.desktop/share/classes/sun/java2d/loops/DrawPath.java
! src/java.desktop/share/classes/sun/java2d/loops/DrawPolygons.java
! src/java.desktop/share/classes/sun/java2d/loops/DrawRect.java
! src/java.desktop/share/classes/sun/java2d/loops/FillParallelogram.java
! src/java.desktop/share/classes/sun/java2d/loops/FillPath.java
! src/java.desktop/share/classes/sun/java2d/loops/FillRect.java
! src/java.desktop/share/classes/sun/java2d/loops/FillSpans.java
! src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitive.java
! src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitiveMgr.java
! src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitiveProxy.java
! src/java.desktop/share/classes/sun/java2d/loops/MaskBlit.java
! src/java.desktop/share/classes/sun/java2d/loops/MaskFill.java
! src/java.desktop/share/classes/sun/java2d/loops/ScaledBlit.java
! src/java.desktop/share/classes/sun/java2d/loops/TransformBlit.java
! src/java.desktop/share/classes/sun/java2d/loops/TransformHelper.java

Changeset: 7e01bc96
Author:    Mat Carter <macarte at microsoft.com>
Committer: Alan Bateman <alanb at openjdk.org>
Date:      2021-01-06 10:39:07 +0000
URL:       https://git.openjdk.java.net/amber/commit/7e01bc96

8255264: Support for identifying the full range of IPv4 localhost addresses on Windows

Reviewed-by: alanb

! src/java.base/windows/native/libnet/net_util_md.h

Changeset: c0540ffd
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2021-01-06 14:34:55 +0000
URL:       https://git.openjdk.java.net/amber/commit/c0540ffd

8231627: ThreadsListHandleInErrorHandlingTest.java fails in printing all threads

Reviewed-by: eosterlund, coleenp, pchilanomate, sspitsyn

! src/hotspot/share/runtime/threadSMR.cpp
! test/hotspot/jtreg/runtime/ErrorHandling/NestedThreadsListHandleInErrorHandlingTest.java
! test/hotspot/jtreg/runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java

Changeset: f6cb8c55
Author:    Harold Seigel <hseigel at openjdk.org>
Date:      2021-01-06 15:11:52 +0000
URL:       https://git.openjdk.java.net/amber/commit/f6cb8c55

8258908: Remove JVM option CleanChunkPoolAsync

Reviewed-by: coleenp

! src/hotspot/share/gc/serial/defNewGeneration.cpp
! src/hotspot/share/gc/shared/genCollectedHeap.cpp
! src/hotspot/share/memory/arena.cpp
! src/hotspot/share/memory/arena.hpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/thread.cpp

Changeset: 722f2361
Author:    Lehua Ding <lehuading at tencent.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-06 15:36:57 +0000
URL:       https://git.openjdk.java.net/amber/commit/722f2361

8259231: Epsilon: improve performance under contention during virtual space expansion

Reviewed-by: shade

! src/hotspot/share/gc/epsilon/epsilonHeap.cpp

Changeset: 3be6e069
Author:    Rajan Halade <rhalade at openjdk.org>
Date:      2021-01-06 16:20:24 +0000
URL:       https://git.openjdk.java.net/amber/commit/3be6e069

8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days

Reviewed-by: mullan

! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java

Changeset: d20d2fa9
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2021-01-06 16:26:23 +0000
URL:       https://git.openjdk.java.net/amber/commit/d20d2fa9

8258143: Update --release 16 symbol information for JDK 16 build 30 or later

Reviewed-by: iris, erikj

! make/data/symbols/java.desktop-G.sym.txt

Changeset: df721f0c
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
Date:      2021-01-06 16:57:17 +0000
URL:       https://git.openjdk.java.net/amber/commit/df721f0c

8259291: Cleanup unnecessary local variables

Reviewed-by: mullan

! src/java.base/share/classes/sun/security/ssl/Finished.java
! src/java.base/share/classes/sun/security/ssl/OutputRecord.java
! src/java.base/share/classes/sun/security/ssl/SSLExtension.java
! src/java.base/share/classes/sun/security/ssl/SSLSocketOutputRecord.java
! src/java.base/share/classes/sun/security/ssl/ServerNameExtension.java
! src/java.base/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java

Changeset: 940b0530
Author:    Phil Race <prr at openjdk.org>
Date:      2021-01-06 17:34:15 +0000
URL:       https://git.openjdk.java.net/amber/commit/940b0530

8259232: Bad JNI lookup during printing

Reviewed-by: psadhukhan

! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m
! test/jdk/java/awt/print/bug8023392/bug8023392.java

Changeset: 80544e4d
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2021-01-06 18:05:33 +0000
URL:       https://git.openjdk.java.net/amber/commit/80544e4d

8250564: Remove terminally deprecated constructor in GSSUtil
8250565: Remove terminally deprecated constructor in java.net.URLDecoder

Reviewed-by: bpb, smarks, alanb, mullan

! src/java.base/share/classes/java/net/URLDecoder.java
! src/jdk.security.jgss/share/classes/com/sun/security/jgss/GSSUtil.java
! test/jdk/java/net/URLDecoder/B6463990.java

Changeset: 28e1f4d9
Author:    Yoshiki Sato <ysatowse at openjdk.org>
Committer: Jonathan Gibbons <jjg at openjdk.org>
Date:      2021-01-06 22:48:00 +0000
URL:       https://git.openjdk.java.net/amber/commit/28e1f4d9

8247957: remove doclint support for HTML 4
8257204: Remove usage of -Xhtmlversion option from javac
8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option
8258460: Remove --doclint-format option from javac
8256312: Valid anchor 'id' value not allowed

Reviewed-by: jjg, ihse

! make/common/JavaCompilation.gmk
! src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseConfiguration.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Env.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlVersion.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties
! test/langtools/jdk/javadoc/doclet/testHtmlTableStyles/TestHtmlTableStyles.java
! test/langtools/tools/doclint/AccessibilityTest.java
! test/langtools/tools/doclint/AccessibilityTest.out
- test/langtools/tools/doclint/AccessibilityTest5.java
- test/langtools/tools/doclint/AccessibilityTest5.out
! test/langtools/tools/doclint/AnchorTest.java
! test/langtools/tools/doclint/AnchorTest.out
! test/langtools/tools/doclint/AnchorTest2.java
! test/langtools/tools/doclint/AnchorTest2.out
! test/langtools/tools/doclint/AnchorTest2a.java
! test/langtools/tools/doclint/EndTagsTest.java
! test/langtools/tools/doclint/HtmlAttrsTest.java
! test/langtools/tools/doclint/HtmlAttrsTest.out
! test/langtools/tools/doclint/HtmlTagsTest.java
! test/langtools/tools/doclint/HtmlTagsTest.out
- test/langtools/tools/doclint/HtmlVersionTest.java
! test/langtools/tools/doclint/anchorTests/p/Test.java
! test/langtools/tools/doclint/anchorTests/p/Test.out
! test/langtools/tools/doclint/anchorTests/p/package-info.java
! test/langtools/tools/doclint/anchorTests/p/package-info.javac.out
! test/langtools/tools/doclint/anchorTests/p/package-info.out
! test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTest.java
+ test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTest.out
- test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTestHtml4.out
- test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTestHtml5.out
+ test/langtools/tools/doclint/html/InlineTagTest.out
! test/langtools/tools/doclint/html/InlineTagsTest.java
! test/langtools/tools/doclint/html/OtherTagsTest.java
! test/langtools/tools/doclint/html/OtherTagsTest.out
+ test/langtools/tools/doclint/html/TableTagTest.out
! test/langtools/tools/doclint/html/TableTagsTest.java
! test/langtools/tools/doclint/html/TagNotAllowed.java
! test/langtools/tools/doclint/html/TagNotAllowed.out
! test/langtools/tools/doclint/html/TextNotAllowed.java
! test/langtools/tools/doclint/html/TextNotAllowed.out
! test/langtools/tools/doclint/tidy/AnchorAlreadyDefined.java
! test/langtools/tools/doclint/tidy/AnchorAlreadyDefined.out
! test/langtools/tools/doclint/tidy/BadEnd.java
! test/langtools/tools/doclint/tidy/BadEnd.out
! test/langtools/tools/doclint/tidy/InvalidName.java
! test/langtools/tools/doclint/tidy/InvalidName.out
! test/langtools/tools/doclint/tidy/TextNotAllowed.java
! test/langtools/tools/doclint/tidy/TextNotAllowed.out
! test/langtools/tools/doclint/tidy/TrimmingEmptyTag.java
! test/langtools/tools/doclint/tidy/TrimmingEmptyTag.out
! test/langtools/tools/javac/doclint/DocLintFormatTest.java

Changeset: 67c22114
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2021-01-06 23:59:52 +0000
URL:       https://git.openjdk.java.net/amber/commit/67c22114

8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale

Reviewed-by: erikj, cjplummer, iklam

! make/modules/jdk.hotspot.agent/Lib.gmk
! src/jdk.hotspot.agent/share/native/libsaproc/sadis.c

Changeset: 227f99d3
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2021-01-07 03:57:43 +0000
URL:       https://git.openjdk.java.net/amber/commit/227f99d3

8233555: [TESTBUG] JRadioButton tests failing on MacoS

Reviewed-by: serb

! test/jdk/ProblemList.txt

Changeset: 81c06242
Author:    Carter Kozak <ckozak at ckozak.net>
Committer: Erik Gahlin <egahlin at openjdk.org>
Date:      2021-01-07 06:11:32 +0000
URL:       https://git.openjdk.java.net/amber/commit/81c06242

8259354: Fix race condition in AbstractEventStream.nextThreadName

Reviewed-by: egahlin

! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java

Changeset: 0e6de4eb
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2021-01-07 12:15:23 +0000
URL:       https://git.openjdk.java.net/amber/commit/0e6de4eb

8259339: AllocateUninitializedArray C2 intrinsic fails with void.class input

Reviewed-by: kvn, chagedorn

! src/hotspot/share/opto/library_call.cpp
! test/hotspot/jtreg/compiler/intrinsics/unsafe/AllocateUninitializedArray.java

Changeset: 1c33847b
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2021-01-07 12:35:16 +0000
URL:       https://git.openjdk.java.net/amber/commit/1c33847b

8259067: bootclasspath append takes out object lock

Reviewed-by: lfoltan, sspitsyn, iklam, dholmes

! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/classLoader.hpp
! src/hotspot/share/classfile/classLoader.inline.hpp
! src/hotspot/share/prims/jvmtiEnv.cpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/mutexLocker.hpp

Changeset: 3f9f86f0
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2021-01-07 12:39:44 +0000
URL:       https://git.openjdk.java.net/amber/commit/3f9f86f0

8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006

Reviewed-by: clanger, mdoerr

! make/modules/java.desktop/lib/Awt2dLibraries.gmk

Changeset: f91f92dc
Author:    Harold Seigel <hseigel at openjdk.org>
Date:      2021-01-07 13:18:50 +0000
URL:       https://git.openjdk.java.net/amber/commit/f91f92dc

8259317: Remove JVM option BreakAtWarning

Reviewed-by: lfoltan, coleenp

! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/utilities/debug.cpp

Changeset: 8530ef0e
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2021-01-07 17:13:41 +0000
URL:       https://git.openjdk.java.net/amber/commit/8530ef0e

8259375: JvmtiExport::jni_Get/SetField_probe calls do not need ResetNoHandleMark

Reviewed-by: lfoltan, dcubed

! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvmtiExport.cpp

Changeset: 2e99e28f
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2021-01-07 17:49:48 +0000
URL:       https://git.openjdk.java.net/amber/commit/2e99e28f

8213126: java/awt/Window/MainKeyWindow/TestMainKeyWindow.java time-out on mac10.13

Reviewed-by: psadhukhan

! test/jdk/ProblemList.txt
! test/jdk/java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java

Changeset: 4ce83f2a
Author:    Rajan Halade <rhalade at openjdk.org>
Date:      2021-01-07 18:47:43 +0000
URL:       https://git.openjdk.java.net/amber/commit/4ce83f2a

8039278: console.sh failed Automatically with exit code 1

Reviewed-by: xuelei, weijun

! test/jdk/TEST.groups
- test/jdk/sun/security/tools/keytool/console.sh

Changeset: d8ad6301
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
Date:      2021-01-07 18:57:58 +0000
URL:       https://git.openjdk.java.net/amber/commit/d8ad6301

8258772: Some runtime/cds tests fail with +LogCompilation or +StressX

Emit warning about TraceDependencies results in
ClassHierarchyWalker::count_find_witness_calls() only if TraceDependencies is
actually enabled. Use standard warning() function instead of ad hoc printing.
Remove warning about using Stress(LCM|GCM|IGVN) without LogCompilation in
Compile::Compile(), and add the information to the description of the StressSeed
option instead. These changes prevent false test failures when using
LogCompilation or Stress(LCM|GCM|IGVN).

Reviewed-by: chagedorn, kvn, thartmann

! src/hotspot/share/code/dependencies.cpp
! src/hotspot/share/opto/c2_globals.hpp
! src/hotspot/share/opto/compile.cpp

Changeset: bc565414
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
Date:      2021-01-07 20:43:48 +0000
URL:       https://git.openjdk.java.net/amber/commit/bc565414

8256535: C2: randomize CCP processing order for stress testing

Add 'StressCCP' option to randomize the selection of the node to be examined in
each CCP iteration.

Reviewed-by: chagedorn, kvn, thartmann

! src/hotspot/share/opto/c2_globals.hpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/phaseX.cpp
- test/hotspot/jtreg/compiler/arguments/TestStressIGVNOptions.java
+ test/hotspot/jtreg/compiler/arguments/TestStressOptions.java
! test/hotspot/jtreg/compiler/debug/TestGenerateStressSeed.java
- test/hotspot/jtreg/compiler/debug/TestStressIGVN.java
+ test/hotspot/jtreg/compiler/debug/TestStressIGVNAndCCP.java

Changeset: 2659bc44
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2021-01-07 20:57:11 +0000
URL:       https://git.openjdk.java.net/amber/commit/2659bc44

8259274: Increase timeout duration in sun/nio/ch/TestMaxCachedBufferSize.java

Reviewed-by: lancea

! test/jdk/sun/nio/ch/TestMaxCachedBufferSize.java

Changeset: 73f54153
Author:    Chris Hegarty <chegar at openjdk.org>
Date:      2021-01-02 19:29:50 +0000
URL:       https://git.openjdk.java.net/amber/commit/73f54153

8258955: (bf) slice(int, int) on view buffers fails to adjust index according to primitive size

Reviewed-by: alanb

! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template
! test/jdk/java/nio/Buffer/ByteBufferViews.java

Changeset: 216c2ec0
Author:    Jie Fu <jiefu at openjdk.org>
Date:      2021-01-04 23:41:51 +0000
URL:       https://git.openjdk.java.net/amber/commit/216c2ec0

8258703: Incorrect 512-bit vector registers restore on x86_32

Reviewed-by: kvn, sviswanathan

! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp

Changeset: 4ffbe841
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2021-01-05 11:40:25 +0000
URL:       https://git.openjdk.java.net/amber/commit/4ffbe841

8256266: Binding variables don't correctly support declaration annotations and the final modifier

Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/langtools/tools/javac/patterns/Annotations.java
! test/langtools/tools/javac/patterns/BindingsTest1.java
! test/langtools/tools/javac/patterns/BindingsTest2.java
! test/langtools/tools/javac/patterns/BindingsTest2.out
+ test/langtools/tools/javac/patterns/NoModifiersOnBinding.java
+ test/langtools/tools/javac/patterns/NoModifiersOnBinding.out

Changeset: 6775113c
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2021-01-05 13:06:54 +0000
URL:       https://git.openjdk.java.net/amber/commit/6775113c

8258393: Shenandoah: "graph should be schedulable" assert failure

Reviewed-by: rkennke, thartmann

! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp
! src/hotspot/share/opto/loopnode.cpp
+ test/hotspot/jtreg/gc/shenandoah/compiler/TestBadRawMemoryAfterCall.java

Changeset: bbc2e951
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2021-01-05 13:39:57 +0000
URL:       https://git.openjdk.java.net/amber/commit/bbc2e951

8257906: JFR: RecordingStream leaks memory

Reviewed-by: mgronlun
Backport-of: 3c6648501589bf36945340cb1e82c833ebd7485d

! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingStream.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ChunkParser.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventDirectoryStream.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventFileStream.java

Changeset: b7940aa1
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2021-01-05 16:15:28 +0000
URL:       https://git.openjdk.java.net/amber/commit/b7940aa1

8259027: NullPointerException in makeMappedSegment due to NULL Unmapper when length of segment is 0

Reviewed-by: chegar, uschindler

! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MappedMemorySegmentImpl.java
! test/jdk/java/foreign/TestByteBuffer.java

Changeset: 50bf4330
Author:    Sandhya Viswanathan <sviswanathan at openjdk.org>
Date:      2021-01-05 17:42:22 +0000
URL:       https://git.openjdk.java.net/amber/commit/50bf4330

8259213: Vector conversion with part > 0 is not getting intrinsic implementation

Reviewed-by: psandoz

! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractShuffle.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java

Changeset: d5293067
Author:    Vicente Romero <vromero at openjdk.org>
Date:      2021-01-05 21:35:47 +0000
URL:       https://git.openjdk.java.net/amber/commit/d5293067

8213032: program fails with LambdaConversionException at execution time

Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/langtools/tools/javac/lambda/methodReferenceExecution/MethodReferenceIntersection4.java

Changeset: 554e60c4
Author:    Wang Huang <whuang at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2021-01-06 01:49:15 +0000
URL:       https://git.openjdk.java.net/amber/commit/554e60c4

8258989: JVM is failed to inline in jdk.internal.vm.vector.VectorSupport::convert

Co-authored-by: He Xuejin <hexuejin2 at huawei.com>
Reviewed-by: vlivanov, thartmann

! src/hotspot/share/opto/vectorIntrinsics.cpp

Changeset: 80110dac
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2021-01-06 06:36:29 +0000
URL:       https://git.openjdk.java.net/amber/commit/80110dac

8259007: This test printed a blank page

Reviewed-by: prr, serb

! src/java.desktop/windows/classes/sun/awt/windows/WPathGraphics.java
! src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp
- test/jdk/java/awt/print/PathPrecisionScaleFactor/PathPrecisionScaleFactorTest.java

Changeset: e66187d8
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2021-01-06 12:18:43 +0000
URL:       https://git.openjdk.java.net/amber/commit/e66187d8

8259032: MappedMemorySegmentImpl#makeMappedSegment() ignores Unmapper#pagePosition

Co-authored-by: Uwe Schindler <uschindler at openjdk.org>
Reviewed-by: alanb

! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java
! test/jdk/java/foreign/TestByteBuffer.java

Changeset: ad456787
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-06 13:27:57 +0000
URL:       https://git.openjdk.java.net/amber/commit/ad456787

8258558: Revert changes for JDK-8252505 and related issues

Reviewed-by: kvn

! src/hotspot/share/c1/c1_Compiler.cpp
! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/c1/c1_LIRGenerator.cpp
! src/hotspot/share/c1/c1_LIRGenerator.hpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/ci/ciMethod.hpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/vmIntrinsics.cpp
! src/hotspot/share/classfile/vmIntrinsics.hpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/compiler/compilerOracle.cpp
! src/hotspot/share/compiler/compilerOracle.hpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/classes.hpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/library_call.hpp
! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/memnode.hpp
! src/hotspot/share/opto/node.hpp
! src/hotspot/share/opto/regmask.cpp
! src/hotspot/share/opto/regmask.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! test/hotspot/jtreg/ProblemList-Xcomp.txt
! test/hotspot/jtreg/TEST.groups
- test/hotspot/jtreg/compiler/blackhole/BlackholeDiagnosticUnlockTest.java
- test/hotspot/jtreg/compiler/blackhole/BlackholeInstanceReturnTest.java
- test/hotspot/jtreg/compiler/blackhole/BlackholeInstanceTest.java
- test/hotspot/jtreg/compiler/blackhole/BlackholeNonVoidWarningTest.java
- test/hotspot/jtreg/compiler/blackhole/BlackholeNullCheckTest.java
- test/hotspot/jtreg/compiler/blackhole/BlackholeStaticReturnTest.java
- test/hotspot/jtreg/compiler/blackhole/BlackholeStaticTest.java
- test/hotspot/jtreg/compiler/blackhole/BlackholeTarget.java

Changeset: d25a1bed
Author:    Rafael Winterhalter <winterhalter at openjdk.org>
Committer: Joel Borggr?n-Franck <jfranck at openjdk.org>
Date:      2021-01-06 15:46:33 +0000
URL:       https://git.openjdk.java.net/amber/commit/d25a1bed

8259224: (ann) getAnnotatedReceiverType should not parameterize owner(s) of statically nested classes

Reviewed-by: jfranck

! src/java.base/share/classes/java/lang/reflect/Executable.java
+ test/jdk/java/lang/annotation/typeAnnotations/TestReceiverTypeOwnerType.java

Changeset: 4a5786b5
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2021-01-06 16:30:30 +0000
URL:       https://git.openjdk.java.net/amber/commit/4a5786b5

8259075: Update the copyright notice in the files generated by CLDR Converter tool

Reviewed-by: joehw

! make/jdk/src/classes/build/tools/cldrconverter/CopyrightHeaders.java

Changeset: f1bc4e05
Author:    Rajan Halade <rhalade at openjdk.org>
Date:      2021-01-06 16:39:08 +0000
URL:       https://git.openjdk.java.net/amber/commit/f1bc4e05

8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days

Backport-of: 3be6e06958c4304cafee707a29d06d6b2cc5b76b

! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java

Changeset: eef43be7
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2021-01-06 18:52:59 +0000
URL:       https://git.openjdk.java.net/amber/commit/eef43be7

8251200: False positive messages about missing comments for serialization

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/SerializedFormBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java
+ test/langtools/jdk/javadoc/doclet/testSerialMissing/TestSerialMissing.java

Changeset: 4f914e21
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2021-01-06 19:26:17 +0000
URL:       https://git.openjdk.java.net/amber/commit/4f914e21

8249633: doclint reports missing javadoc for JavaFX property methods that have a property description

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MemberSummaryBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java
! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java

Changeset: 555641ed
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
Date:      2021-01-07 21:17:35 +0000
URL:       https://git.openjdk.java.net/amber/commit/555641ed

Merge

! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/ci/ciMethod.hpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/vmIntrinsics.cpp
! src/hotspot/share/classfile/vmIntrinsics.hpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/compiler/compilerOracle.cpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/vectorIntrinsics.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! test/hotspot/jtreg/TEST.groups
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/ci/ciMethod.hpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/vmIntrinsics.cpp
! src/hotspot/share/classfile/vmIntrinsics.hpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/compiler/compilerOracle.cpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/vectorIntrinsics.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! test/hotspot/jtreg/TEST.groups

Changeset: 867a8db0
Author:    duke <duke at openjdk.org>
Date:      2021-01-07 22:01:26 +0000
URL:       https://git.openjdk.java.net/amber/commit/867a8db0

Automatic merge of master into concise-method-declarations

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java


From duke at openjdk.java.net  Thu Jan  7 22:10:46 2021
From: duke at openjdk.java.net (duke)
Date: Thu, 7 Jan 2021 22:10:46 GMT
Subject: git: openjdk/amber: stats-before-this-super: 75 new changesets
Message-ID: <b3ebce1f-e7a8-4231-ad1f-fefef550dfd4@openjdk.org>

Changeset: 497efefa
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2021-01-03 05:08:48 +0000
URL:       https://git.openjdk.java.net/amber/commit/497efefa

8225116: Test OwnedWindowsLeak.java intermittently fails

Reviewed-by: pbansal

! test/jdk/java/awt/Window/OwnedWindowsLeak/OwnedWindowsLeak.java

Changeset: 526c0005
Author:    Guoxiong Li <lgxbslgx at gmail.com>
Committer: Jonathan Gibbons <jjg at openjdk.org>
Date:      2021-01-03 17:32:46 +0000
URL:       https://git.openjdk.java.net/amber/commit/526c0005

8255729: com.sun.tools.javac.processing.JavacFiler.FilerOutputStream is inefficient

Reviewed-by: jjg

! src/jdk.compiler/share/classes/com/sun/tools/javac/processing/JavacFiler.java

Changeset: f351e155
Author:    Hao Sun <hao.sun at arm.com>
Committer: Ningsheng Jian <njian at openjdk.org>
Date:      2021-01-04 02:21:58 +0000
URL:       https://git.openjdk.java.net/amber/commit/f351e155

8258382: Fix optimization-unstable code involving pointer overflow

Reviewed-by: kbarrett

! src/hotspot/share/gc/parallel/psPromotionLAB.hpp
! src/hotspot/share/gc/parallel/psPromotionLAB.inline.hpp

Changeset: a2a3f4a3
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2021-01-04 04:33:30 +0000
URL:       https://git.openjdk.java.net/amber/commit/a2a3f4a3

8258924: javax/swing/JSplitPane/4201995/bug4201995.java fails in GTk L&F

Reviewed-by: serb

! test/jdk/ProblemList.txt
! test/jdk/javax/swing/JSplitPane/4201995/bug4201995.java

Changeset: d679caa2
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2021-01-04 06:35:37 +0000
URL:       https://git.openjdk.java.net/amber/commit/d679caa2

8196466: javax/swing/JFileChooser/8062561/bug8062561.java fails

Reviewed-by: serb

! test/jdk/ProblemList.txt

Changeset: 7f04d23b
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2021-01-04 16:44:39 +0000
URL:       https://git.openjdk.java.net/amber/commit/7f04d23b

8258800: Deprecate -XX:+AlwaysLockClassLoader

Reviewed-by: hseigel

! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/globals.hpp

Changeset: f80c63b3
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2021-01-04 18:10:36 +0000
URL:       https://git.openjdk.java.net/amber/commit/f80c63b3

8258490: Shenandoah: Full GC does not need to remark threads and drain SATB buffers

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp

Changeset: 9d160aa1
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2021-01-04 21:01:25 +0000
URL:       https://git.openjdk.java.net/amber/commit/9d160aa1

8257815: Replace global log2 functions with efficient implementations

Reviewed-by: kbarrett, stefank

! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/z/zGlobals_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/arm/c1_LIRAssembler_arm.cpp
! src/hotspot/cpu/arm/c1_LIRGenerator_arm.cpp
! src/hotspot/cpu/ppc/assembler_ppc.cpp
! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp
! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp
! src/hotspot/cpu/ppc/ppc.ad
! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
! src/hotspot/cpu/s390/c1_LIRAssembler_s390.cpp
! src/hotspot/cpu/s390/c1_LIRGenerator_s390.cpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_LIRGenerator_x86.cpp
! src/hotspot/cpu/x86/gc/z/zGlobals_x86.cpp
! src/hotspot/cpu/x86/interp_masm_x86.cpp
! src/hotspot/cpu/x86/vm_version_x86.cpp
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/compiler/compilationPolicy.cpp
! src/hotspot/share/compiler/compilerDefinitions.cpp
! src/hotspot/share/compiler/tieredThresholdPolicy.cpp
! src/hotspot/share/gc/g1/g1BiasedArray.hpp
! src/hotspot/share/gc/g1/g1FreeIdSet.cpp
! src/hotspot/share/gc/g1/g1RemSet.cpp
! src/hotspot/share/gc/g1/heapRegion.cpp
! src/hotspot/share/gc/g1/heapRegionRemSet.cpp
! src/hotspot/share/gc/shared/partialArrayTaskStepper.cpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahNumberSeq.cpp
! src/hotspot/share/gc/z/zHeuristics.cpp
! src/hotspot/share/opto/divnode.cpp
! src/hotspot/share/opto/mulnode.cpp
! src/hotspot/share/opto/parse2.cpp
! src/hotspot/share/opto/vectorIntrinsics.cpp
! src/hotspot/share/utilities/globalDefinitions.hpp
! src/hotspot/share/utilities/hashtable.cpp
! src/hotspot/share/utilities/powerOfTwo.hpp
! test/hotspot/gtest/utilities/test_globalDefinitions.cpp
! test/hotspot/gtest/utilities/test_powerOfTwo.cpp

Changeset: e6f99260
Author:    Phil Race <prr at openjdk.org>
Date:      2021-01-04 21:09:01 +0000
URL:       https://git.openjdk.java.net/amber/commit/e6f99260

8257809: JNI warnings from Toolkit JPEG image decoding

Reviewed-by: serb

! src/java.desktop/share/native/libjavajpeg/jpegdecoder.c
+ test/jdk/java/awt/image/GetImageJNICheck/GetImageJNICheck.java
+ test/jdk/java/awt/image/GetImageJNICheck/GetImageJNICheck.sh
= test/jdk/java/awt/image/GetImageJNICheck/duke.jpg

Changeset: f0aae81e
Author:    Xin Liu <xliu at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2021-01-04 23:58:53 +0000
URL:       https://git.openjdk.java.net/amber/commit/f0aae81e

8259020: null-check of g1 write_ref_field_pre_entry is not necessary

Reviewed-by: kbarrett, ayang, phh

! src/hotspot/share/gc/g1/g1BarrierSetRuntime.cpp

Changeset: 2499ac3d
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
Date:      2021-01-05 00:11:55 +0000
URL:       https://git.openjdk.java.net/amber/commit/2499ac3d

8259069: Fields could be final

Reviewed-by: wetmore

! src/java.base/share/classes/sun/security/ssl/DHClientKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/EphemeralKeyManager.java
! src/java.base/share/classes/sun/security/ssl/HelloCookieManager.java
! src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java
! src/java.base/share/classes/sun/security/ssl/SSLCipher.java
! src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java
! src/java.base/share/classes/sun/security/ssl/SSLEngineOutputRecord.java
! src/java.base/share/classes/sun/security/ssl/SSLExtensions.java
! src/java.base/share/classes/sun/security/ssl/SSLKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java
! src/java.base/share/classes/sun/security/ssl/SunJSSE.java
! src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java
! src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java

Changeset: 5ea96072
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2021-01-05 05:57:08 +0000
URL:       https://git.openjdk.java.net/amber/commit/5ea96072

8258459: Decouple gc_globals.hpp from globals.hpp

Reviewed-by: lfoltan, coleenp

! src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/shared/cardTableBarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/z/zGlobals_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/z/z_aarch64.ad
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp
! src/hotspot/cpu/arm/c1_MacroAssembler_arm.cpp
! src/hotspot/cpu/arm/c1_Runtime1_arm.cpp
! src/hotspot/cpu/arm/templateTable_arm.cpp
! src/hotspot/cpu/ppc/c1_MacroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
! src/hotspot/cpu/s390/c1_MacroAssembler_s390.cpp
! src/hotspot/cpu/s390/templateTable_s390.cpp
! src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp
! src/hotspot/cpu/x86/gc/shared/cardTableBarrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/gc/shenandoah/c1/shenandoahBarrierSetC1_x86.cpp
! src/hotspot/cpu/x86/gc/z/zGlobals_x86.cpp
! src/hotspot/cpu/x86/gc/z/z_x86_64.ad
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/share/aot/aotCodeHeap.cpp
! src/hotspot/share/gc/epsilon/epsilonArguments.cpp
! src/hotspot/share/gc/epsilon/epsilonInitLogger.cpp
! src/hotspot/share/gc/epsilon/epsilonThreadLocalData.hpp
! src/hotspot/share/gc/g1/g1AllocRegion.cpp
! src/hotspot/share/gc/g1/g1Allocator.cpp
! src/hotspot/share/gc/g1/g1Analytics.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/g1/g1EvacStats.cpp
! src/hotspot/share/gc/g1/g1FromCardCache.cpp
! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp
! src/hotspot/share/gc/g1/g1HeapVerifier.cpp
! src/hotspot/share/gc/g1/g1InitLogger.cpp
! src/hotspot/share/gc/g1/g1ThreadLocalData.hpp
! src/hotspot/share/gc/parallel/jvmFlagConstraintsParallel.cpp
! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp
! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp
! src/hotspot/share/gc/serial/defNewGeneration.hpp
! src/hotspot/share/gc/serial/markSweep.cpp
! src/hotspot/share/gc/shared/ageTable.cpp
! src/hotspot/share/gc/shared/blockOffsetTable.hpp
! src/hotspot/share/gc/shared/c1/cardTableBarrierSetC1.cpp
! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp
! src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp
! src/hotspot/share/gc/shared/collectedHeap.cpp
! src/hotspot/share/gc/shared/gcConfiguration.cpp
! src/hotspot/share/gc/shared/gcInitLogger.cpp
! src/hotspot/share/gc/shared/gcOverheadChecker.hpp
! src/hotspot/share/gc/shared/gcPolicyCounters.cpp
! src/hotspot/share/gc/shared/gcStats.cpp
! src/hotspot/share/gc/shared/gcVMOperations.cpp
! src/hotspot/share/gc/shared/gc_globals.hpp
! src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp
! src/hotspot/share/gc/shared/memAllocator.cpp
! src/hotspot/share/gc/shared/plab.cpp
! src/hotspot/share/gc/shared/pretouchTask.cpp
! src/hotspot/share/gc/shared/referencePolicy.cpp
! src/hotspot/share/gc/shared/referenceProcessor.cpp
! src/hotspot/share/gc/shared/stringdedup/stringDedupTable.cpp
! src/hotspot/share/gc/shared/suspendibleThreadSet.cpp
! src/hotspot/share/gc/shared/taskTerminator.cpp
! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp
! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp
! src/hotspot/share/gc/shared/threadLocalAllocBuffer.inline.hpp
+ src/hotspot/share/gc/shared/tlab_globals.hpp
! src/hotspot/share/gc/shared/weakProcessor.cpp
! src/hotspot/share/gc/shared/workerManager.hpp
! src/hotspot/share/gc/shared/workgroup.cpp
! src/hotspot/share/gc/shared/workgroup.hpp
! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp
! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp
! src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp
! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp
! src/hotspot/share/gc/shenandoah/shenandoahWorkerPolicy.cpp
! src/hotspot/share/gc/z/zAddressSpaceLimit.cpp
! src/hotspot/share/gc/z/zDirector.cpp
! src/hotspot/share/gc/z/zHeap.cpp
! src/hotspot/share/gc/z/zHeapIterator.cpp
! src/hotspot/share/gc/z/zHeuristics.cpp
! src/hotspot/share/gc/z/zMarkStackAllocator.cpp
! src/hotspot/share/gc/z/zRelocate.cpp
! src/hotspot/share/gc/z/zRelocationSetSelector.cpp
! src/hotspot/share/gc/z/zRuntimeWorkers.cpp
! src/hotspot/share/gc/z/zStat.cpp
! src/hotspot/share/gc/z/zThreadLocalAllocBuffer.cpp
! src/hotspot/share/gc/z/zUncommitter.cpp
! src/hotspot/share/gc/z/zUnmapper.cpp
! src/hotspot/share/gc/z/zValue.inline.hpp
! src/hotspot/share/gc/z/zVerify.cpp
! src/hotspot/share/gc/z/zWorkers.inline.hpp
! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp
! src/hotspot/share/jfr/leakprofiler/chains/pathToGcRootsOperation.cpp
! src/hotspot/share/jfr/support/jfrObjectAllocationSample.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
! src/hotspot/share/memory/dynamicArchive.cpp
! src/hotspot/share/memory/heapShared.hpp
! src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/oops/oop.cpp
! src/hotspot/share/oops/oop.hpp
! src/hotspot/share/oops/oop.inline.hpp
! src/hotspot/share/opto/arraycopynode.cpp
! src/hotspot/share/opto/lcm.cpp
! src/hotspot/share/opto/macro.cpp
! src/hotspot/share/opto/macroArrayCopy.cpp
! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/flags/allFlags.hpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/interfaceSupport.inline.hpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/thread.inline.hpp
! src/hotspot/share/runtime/threadSMR.inline.hpp
! test/hotspot/gtest/runtime/test_globals.cpp

Changeset: dd8996c5
Author:    Hao Sun <hao.sun at arm.com>
Committer: Ningsheng Jian <njian at openjdk.org>
Date:      2021-01-05 07:31:44 +0000
URL:       https://git.openjdk.java.net/amber/commit/dd8996c5

8258946: Fix optimization-unstable code involving signed integer overflow

Reviewed-by: thartmann, kvn

! src/hotspot/share/opto/ifnode.cpp
! src/hotspot/share/opto/loopTransform.cpp
! src/hotspot/share/opto/parse2.cpp

Changeset: 17d1645e
Author:    Hao Sun <hao.sun at arm.com>
Committer: Ningsheng Jian <njian at openjdk.org>
Date:      2021-01-05 08:29:41 +0000
URL:       https://git.openjdk.java.net/amber/commit/17d1645e

8258751: Improve ExceptionHandlerTable dump

Reviewed-by: thartmann, chagedorn, njian

! src/hotspot/share/code/exceptionHandlerTable.cpp
! src/hotspot/share/code/exceptionHandlerTable.hpp
! src/hotspot/share/code/nmethod.cpp

Changeset: 3817c32f
Author:    Lehua Ding <lehuading at tencent.com>
Committer: Jie Fu <jiefu at openjdk.org>
Date:      2021-01-05 08:34:11 +0000
URL:       https://git.openjdk.java.net/amber/commit/3817c32f

8258534: Epsilon: clean up unused includes

Reviewed-by: shade, jiefu

! src/hotspot/share/gc/epsilon/epsilonArguments.cpp
! src/hotspot/share/gc/epsilon/epsilonBarrierSet.cpp

Changeset: db6f3930
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-05 08:37:06 +0000
URL:       https://git.openjdk.java.net/amber/commit/db6f3930

8251944: Add Shenandoah test config to compiler/gcbarriers/UnsafeIntrinsicsTest.java

Reviewed-by: rkennke, adityam

! test/hotspot/jtreg/compiler/gcbarriers/UnsafeIntrinsicsTest.java

Changeset: 9f151649
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2021-01-05 09:54:18 +0000
URL:       https://git.openjdk.java.net/amber/commit/9f151649

8259049: Uninitialized variable after JDK-8257513

Reviewed-by: kvn, thartmann

! src/hotspot/share/opto/constantTable.cpp

Changeset: a6c08813
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2021-01-05 12:47:33 +0000
URL:       https://git.openjdk.java.net/amber/commit/a6c08813

8256321: Some "inactive" color profiles use the wrong profile class

Reviewed-by: prr

! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java
+ test/jdk/java/awt/color/CheckDefaultProperties.java

Changeset: fc3b45c0
Author:    Alexander Zuev <kizune at openjdk.org>
Date:      2021-01-05 14:46:03 +0000
URL:       https://git.openjdk.java.net/amber/commit/fc3b45c0

8258643: javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button"

Reviewed-by: psadhukhan

! test/jdk/javax/swing/JComponent/7154030/bug7154030.java

Changeset: f4122d6a
Author:    Harold Seigel <hseigel at openjdk.org>
Date:      2021-01-05 16:14:58 +0000
URL:       https://git.openjdk.java.net/amber/commit/f4122d6a

8258896: Remove the JVM ForceFloatExceptions option

Reviewed-by: lfoltan, iklam, coleenp

! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/share/runtime/globals.hpp

Changeset: 82bdbfd7
Author:    Hao Sun <hao.sun at arm.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-05 16:28:28 +0000
URL:       https://git.openjdk.java.net/amber/commit/82bdbfd7

8258857: Zero: non-PCH release build fails after JDK-8258074

Reviewed-by: jiefu, shade, iklam

! src/hotspot/share/compiler/compiler_globals.hpp

Changeset: d5aa49d1
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2021-01-05 16:41:17 +0000
URL:       https://git.openjdk.java.net/amber/commit/d5aa49d1

8259236: C2 compilation fails with assert(is_power_of_2(value)) failed: value must be a power of 2: 8000000000000000

Reviewed-by: thartmann

! src/hotspot/cpu/x86/x86_64.ad

Changeset: 85bac8c4
Author:    Peter Levart <plevart at openjdk.org>
Date:      2021-01-05 17:41:50 +0000
URL:       https://git.openjdk.java.net/amber/commit/85bac8c4

8259021: SharedSecrets should avoid double racy reads from non-volatile fields

Reviewed-by: shade, redestad, rriggs, mchung, rrich, alanb

! src/java.base/share/classes/jdk/internal/access/SharedSecrets.java

Changeset: 7ddc2b56
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
Date:      2021-01-05 18:29:35 +0000
URL:       https://git.openjdk.java.net/amber/commit/7ddc2b56

8258852: Arrays.asList() for single item could be replaced with List.of()

Reviewed-by: mullan

! src/java.base/share/classes/sun/security/ssl/ClientHello.java
! src/java.base/share/classes/sun/security/ssl/KeyShareExtension.java
! src/java.base/share/classes/sun/security/ssl/SSLConfiguration.java

Changeset: 1b60acd8
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2021-01-05 18:33:41 +0000
URL:       https://git.openjdk.java.net/amber/commit/1b60acd8

8259252: Shenandoah: Shenandoah build failed on AArch64 after JDK-8258459

Reviewed-by: rkennke, shade

! src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp

Changeset: 4d3d5991
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
Date:      2021-01-05 19:32:46 +0000
URL:       https://git.openjdk.java.net/amber/commit/4d3d5991

8259223: Simplify boolean expression in the SunJSSE provider

Reviewed-by: mullan

! src/java.base/share/classes/sun/security/ssl/CipherSuite.java
! src/java.base/share/classes/sun/security/ssl/EphemeralKeyManager.java
! src/java.base/share/classes/sun/security/ssl/Finished.java
! src/java.base/share/classes/sun/security/ssl/HandshakeContext.java
! src/java.base/share/classes/sun/security/ssl/KeyManagerFactoryImpl.java
! src/java.base/share/classes/sun/security/ssl/ProtocolVersion.java
! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java
! src/java.base/share/classes/sun/security/ssl/SignatureScheme.java
! src/java.base/share/classes/sun/security/ssl/SunX509KeyManagerImpl.java
! src/java.base/share/classes/sun/security/ssl/TrustManagerFactoryImpl.java
! src/java.base/share/classes/sun/security/ssl/X509KeyManagerImpl.java

Changeset: cf9908b4
Author:    Harold Seigel <hseigel at openjdk.org>
Date:      2021-01-05 21:15:13 +0000
URL:       https://git.openjdk.java.net/amber/commit/cf9908b4

8258937: Remove JVM IgnoreRewrites flag

Reviewed-by: coleenp

! src/hotspot/share/oops/generateOopMap.cpp
! src/hotspot/share/runtime/globals.hpp

Changeset: 7d769663
Author:    Guoxiong Li <lgxbslgx at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
Date:      2021-01-05 22:21:19 +0000
URL:       https://git.openjdk.java.net/amber/commit/7d769663

8255757: Javac emits duplicate pool entries on array::clone

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/Gen.java
+ test/langtools/tools/javac/classfiles/T8255757/T8255757.java

Changeset: 8b454977
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2021-01-05 22:36:09 +0000
URL:       https://git.openjdk.java.net/amber/commit/8b454977

8259037: livenmethods cannot find hsdis library

Reviewed-by: cjplummer, sspitsyn

! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/asm/Disassembler.java
! src/jdk.hotspot.agent/share/native/libsaproc/sadis.c

Changeset: 52d3feec
Author:    Xiaohong Gong <xgong at openjdk.org>
Committer: Ningsheng Jian <njian at openjdk.org>
Date:      2021-01-06 01:40:34 +0000
URL:       https://git.openjdk.java.net/amber/commit/52d3feec

8258813: [TESTBUG] Fix incorrect Vector API test output message

Reviewed-by: psandoz, njian

! test/jdk/jdk/incubator/vector/AbstractVectorTest.java
! test/jdk/jdk/incubator/vector/Byte128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Byte128VectorTests.java
! test/jdk/jdk/incubator/vector/Byte256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Byte256VectorTests.java
! test/jdk/jdk/incubator/vector/Byte512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Byte512VectorTests.java
! test/jdk/jdk/incubator/vector/Byte64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Byte64VectorTests.java
! test/jdk/jdk/incubator/vector/ByteMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Double128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Double128VectorTests.java
! test/jdk/jdk/incubator/vector/Double256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Double256VectorTests.java
! test/jdk/jdk/incubator/vector/Double512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Double512VectorTests.java
! test/jdk/jdk/incubator/vector/Double64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Double64VectorTests.java
! test/jdk/jdk/incubator/vector/DoubleMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Float128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Float128VectorTests.java
! test/jdk/jdk/incubator/vector/Float256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Float256VectorTests.java
! test/jdk/jdk/incubator/vector/Float512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Float512VectorTests.java
! test/jdk/jdk/incubator/vector/Float64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Float64VectorTests.java
! test/jdk/jdk/incubator/vector/FloatMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Int128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Int128VectorTests.java
! test/jdk/jdk/incubator/vector/Int256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Int256VectorTests.java
! test/jdk/jdk/incubator/vector/Int512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Int512VectorTests.java
! test/jdk/jdk/incubator/vector/Int64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Int64VectorTests.java
! test/jdk/jdk/incubator/vector/IntMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/IntMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Long128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Long128VectorTests.java
! test/jdk/jdk/incubator/vector/Long256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Long256VectorTests.java
! test/jdk/jdk/incubator/vector/Long512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Long512VectorTests.java
! test/jdk/jdk/incubator/vector/Long64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Long64VectorTests.java
! test/jdk/jdk/incubator/vector/LongMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/LongMaxVectorTests.java
! test/jdk/jdk/incubator/vector/Short128VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Short128VectorTests.java
! test/jdk/jdk/incubator/vector/Short256VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Short256VectorTests.java
! test/jdk/jdk/incubator/vector/Short512VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Short512VectorTests.java
! test/jdk/jdk/incubator/vector/Short64VectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/Short64VectorTests.java
! test/jdk/jdk/incubator/vector/ShortMaxVectorLoadStoreTests.java
! test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java
! test/jdk/jdk/incubator/vector/VectorReshapeTests.java
! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-Long-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-Masked-Long-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-op-math.template
! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Binary-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Binary-op-math.template
! test/jdk/jdk/incubator/vector/templates/Unit-Binary-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Blend-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-BoolReduction-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Broadcast.template
! test/jdk/jdk/incubator/vector/templates/Unit-Gather-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Gather-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Get-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Miscellaneous.template
! test/jdk/jdk/incubator/vector/templates/Unit-Rearrange.template
! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-Max-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-Min-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Max-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Min-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Reduction-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Scatter-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Scatter-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Shift-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Shift-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Single-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Slice-Masked-bop.template
! test/jdk/jdk/incubator/vector/templates/Unit-Slice-bop.template
! test/jdk/jdk/incubator/vector/templates/Unit-Slice-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Broadcast-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Broadcast-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Double-Broadcast-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Double-Broadcast-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Ternary-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Unary-Masked-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Unary-op-math.template
! test/jdk/jdk/incubator/vector/templates/Unit-Unary-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-Unslice-Masked-bop.template
! test/jdk/jdk/incubator/vector/templates/Unit-Unslice-bop.template
! test/jdk/jdk/incubator/vector/templates/Unit-Unslice-op.template
! test/jdk/jdk/incubator/vector/templates/Unit-With-Op.template
! test/jdk/jdk/incubator/vector/templates/Unit-header.template
! test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template

Changeset: 32538b5b
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2021-01-06 06:45:48 +0000
URL:       https://git.openjdk.java.net/amber/commit/32538b5b

8193942: Regression automated test '/open/test/jdk/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java' fails

Reviewed-by: serb

! test/jdk/ProblemList.txt
! test/jdk/javax/swing/JFrame/8175301/ScaledFrameBackgroundTest.java

Changeset: e3b9da14
Author:    Xin Liu <xliu at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-06 09:51:18 +0000
URL:       https://git.openjdk.java.net/amber/commit/e3b9da14

8259287: AbstractCompiler marks const in wrong position for is_c1/is_c2/is_jvmci

Reviewed-by: thartmann, chagedorn, shade

! src/hotspot/share/compiler/abstractCompiler.hpp

Changeset: 8a05d605
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2021-01-06 10:07:03 +0000
URL:       https://git.openjdk.java.net/amber/commit/8a05d605

8259042: Inconsistent use of general primitives loops

Reviewed-by: prr

! src/java.desktop/share/classes/sun/java2d/loops/Blit.java
! src/java.desktop/share/classes/sun/java2d/loops/BlitBg.java
! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphList.java
! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphListAA.java
! src/java.desktop/share/classes/sun/java2d/loops/DrawGlyphListLCD.java
! src/java.desktop/share/classes/sun/java2d/loops/DrawLine.java
! src/java.desktop/share/classes/sun/java2d/loops/DrawParallelogram.java
! src/java.desktop/share/classes/sun/java2d/loops/DrawPath.java
! src/java.desktop/share/classes/sun/java2d/loops/DrawPolygons.java
! src/java.desktop/share/classes/sun/java2d/loops/DrawRect.java
! src/java.desktop/share/classes/sun/java2d/loops/FillParallelogram.java
! src/java.desktop/share/classes/sun/java2d/loops/FillPath.java
! src/java.desktop/share/classes/sun/java2d/loops/FillRect.java
! src/java.desktop/share/classes/sun/java2d/loops/FillSpans.java
! src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitive.java
! src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitiveMgr.java
! src/java.desktop/share/classes/sun/java2d/loops/GraphicsPrimitiveProxy.java
! src/java.desktop/share/classes/sun/java2d/loops/MaskBlit.java
! src/java.desktop/share/classes/sun/java2d/loops/MaskFill.java
! src/java.desktop/share/classes/sun/java2d/loops/ScaledBlit.java
! src/java.desktop/share/classes/sun/java2d/loops/TransformBlit.java
! src/java.desktop/share/classes/sun/java2d/loops/TransformHelper.java

Changeset: 7e01bc96
Author:    Mat Carter <macarte at microsoft.com>
Committer: Alan Bateman <alanb at openjdk.org>
Date:      2021-01-06 10:39:07 +0000
URL:       https://git.openjdk.java.net/amber/commit/7e01bc96

8255264: Support for identifying the full range of IPv4 localhost addresses on Windows

Reviewed-by: alanb

! src/java.base/windows/native/libnet/net_util_md.h

Changeset: c0540ffd
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2021-01-06 14:34:55 +0000
URL:       https://git.openjdk.java.net/amber/commit/c0540ffd

8231627: ThreadsListHandleInErrorHandlingTest.java fails in printing all threads

Reviewed-by: eosterlund, coleenp, pchilanomate, sspitsyn

! src/hotspot/share/runtime/threadSMR.cpp
! test/hotspot/jtreg/runtime/ErrorHandling/NestedThreadsListHandleInErrorHandlingTest.java
! test/hotspot/jtreg/runtime/ErrorHandling/ThreadsListHandleInErrorHandlingTest.java

Changeset: f6cb8c55
Author:    Harold Seigel <hseigel at openjdk.org>
Date:      2021-01-06 15:11:52 +0000
URL:       https://git.openjdk.java.net/amber/commit/f6cb8c55

8258908: Remove JVM option CleanChunkPoolAsync

Reviewed-by: coleenp

! src/hotspot/share/gc/serial/defNewGeneration.cpp
! src/hotspot/share/gc/shared/genCollectedHeap.cpp
! src/hotspot/share/memory/arena.cpp
! src/hotspot/share/memory/arena.hpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/thread.cpp

Changeset: 722f2361
Author:    Lehua Ding <lehuading at tencent.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-06 15:36:57 +0000
URL:       https://git.openjdk.java.net/amber/commit/722f2361

8259231: Epsilon: improve performance under contention during virtual space expansion

Reviewed-by: shade

! src/hotspot/share/gc/epsilon/epsilonHeap.cpp

Changeset: 3be6e069
Author:    Rajan Halade <rhalade at openjdk.org>
Date:      2021-01-06 16:20:24 +0000
URL:       https://git.openjdk.java.net/amber/commit/3be6e069

8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days

Reviewed-by: mullan

! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java

Changeset: d20d2fa9
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2021-01-06 16:26:23 +0000
URL:       https://git.openjdk.java.net/amber/commit/d20d2fa9

8258143: Update --release 16 symbol information for JDK 16 build 30 or later

Reviewed-by: iris, erikj

! make/data/symbols/java.desktop-G.sym.txt

Changeset: df721f0c
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
Date:      2021-01-06 16:57:17 +0000
URL:       https://git.openjdk.java.net/amber/commit/df721f0c

8259291: Cleanup unnecessary local variables

Reviewed-by: mullan

! src/java.base/share/classes/sun/security/ssl/Finished.java
! src/java.base/share/classes/sun/security/ssl/OutputRecord.java
! src/java.base/share/classes/sun/security/ssl/SSLExtension.java
! src/java.base/share/classes/sun/security/ssl/SSLSocketOutputRecord.java
! src/java.base/share/classes/sun/security/ssl/ServerNameExtension.java
! src/java.base/share/classes/sun/security/ssl/SignatureAlgorithmsExtension.java

Changeset: 940b0530
Author:    Phil Race <prr at openjdk.org>
Date:      2021-01-06 17:34:15 +0000
URL:       https://git.openjdk.java.net/amber/commit/940b0530

8259232: Bad JNI lookup during printing

Reviewed-by: psadhukhan

! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m
! test/jdk/java/awt/print/bug8023392/bug8023392.java

Changeset: 80544e4d
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2021-01-06 18:05:33 +0000
URL:       https://git.openjdk.java.net/amber/commit/80544e4d

8250564: Remove terminally deprecated constructor in GSSUtil
8250565: Remove terminally deprecated constructor in java.net.URLDecoder

Reviewed-by: bpb, smarks, alanb, mullan

! src/java.base/share/classes/java/net/URLDecoder.java
! src/jdk.security.jgss/share/classes/com/sun/security/jgss/GSSUtil.java
! test/jdk/java/net/URLDecoder/B6463990.java

Changeset: 28e1f4d9
Author:    Yoshiki Sato <ysatowse at openjdk.org>
Committer: Jonathan Gibbons <jjg at openjdk.org>
Date:      2021-01-06 22:48:00 +0000
URL:       https://git.openjdk.java.net/amber/commit/28e1f4d9

8247957: remove doclint support for HTML 4
8257204: Remove usage of -Xhtmlversion option from javac
8256313: JavaCompilation.gmk needs to be updated not to use --doclint-format html5 option
8258460: Remove --doclint-format option from javac
8256312: Valid anchor 'id' value not allowed

Reviewed-by: jjg, ihse

! make/common/JavaCompilation.gmk
! src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Arguments.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/BaseConfiguration.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Checker.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/DocLint.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/Env.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlTag.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/HtmlVersion.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties
! test/langtools/jdk/javadoc/doclet/testHtmlTableStyles/TestHtmlTableStyles.java
! test/langtools/tools/doclint/AccessibilityTest.java
! test/langtools/tools/doclint/AccessibilityTest.out
- test/langtools/tools/doclint/AccessibilityTest5.java
- test/langtools/tools/doclint/AccessibilityTest5.out
! test/langtools/tools/doclint/AnchorTest.java
! test/langtools/tools/doclint/AnchorTest.out
! test/langtools/tools/doclint/AnchorTest2.java
! test/langtools/tools/doclint/AnchorTest2.out
! test/langtools/tools/doclint/AnchorTest2a.java
! test/langtools/tools/doclint/EndTagsTest.java
! test/langtools/tools/doclint/HtmlAttrsTest.java
! test/langtools/tools/doclint/HtmlAttrsTest.out
! test/langtools/tools/doclint/HtmlTagsTest.java
! test/langtools/tools/doclint/HtmlTagsTest.out
- test/langtools/tools/doclint/HtmlVersionTest.java
! test/langtools/tools/doclint/anchorTests/p/Test.java
! test/langtools/tools/doclint/anchorTests/p/Test.out
! test/langtools/tools/doclint/anchorTests/p/package-info.java
! test/langtools/tools/doclint/anchorTests/p/package-info.javac.out
! test/langtools/tools/doclint/anchorTests/p/package-info.out
! test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTest.java
+ test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTest.out
- test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTestHtml4.out
- test/langtools/tools/doclint/html/HtmlVersionTagsAttrsTestHtml5.out
+ test/langtools/tools/doclint/html/InlineTagTest.out
! test/langtools/tools/doclint/html/InlineTagsTest.java
! test/langtools/tools/doclint/html/OtherTagsTest.java
! test/langtools/tools/doclint/html/OtherTagsTest.out
+ test/langtools/tools/doclint/html/TableTagTest.out
! test/langtools/tools/doclint/html/TableTagsTest.java
! test/langtools/tools/doclint/html/TagNotAllowed.java
! test/langtools/tools/doclint/html/TagNotAllowed.out
! test/langtools/tools/doclint/html/TextNotAllowed.java
! test/langtools/tools/doclint/html/TextNotAllowed.out
! test/langtools/tools/doclint/tidy/AnchorAlreadyDefined.java
! test/langtools/tools/doclint/tidy/AnchorAlreadyDefined.out
! test/langtools/tools/doclint/tidy/BadEnd.java
! test/langtools/tools/doclint/tidy/BadEnd.out
! test/langtools/tools/doclint/tidy/InvalidName.java
! test/langtools/tools/doclint/tidy/InvalidName.out
! test/langtools/tools/doclint/tidy/TextNotAllowed.java
! test/langtools/tools/doclint/tidy/TextNotAllowed.out
! test/langtools/tools/doclint/tidy/TrimmingEmptyTag.java
! test/langtools/tools/doclint/tidy/TrimmingEmptyTag.out
! test/langtools/tools/javac/doclint/DocLintFormatTest.java

Changeset: 67c22114
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2021-01-06 23:59:52 +0000
URL:       https://git.openjdk.java.net/amber/commit/67c22114

8259045: Exception message from saproc.dll is garbled on Windows with Japanese locale

Reviewed-by: erikj, cjplummer, iklam

! make/modules/jdk.hotspot.agent/Lib.gmk
! src/jdk.hotspot.agent/share/native/libsaproc/sadis.c

Changeset: 227f99d3
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2021-01-07 03:57:43 +0000
URL:       https://git.openjdk.java.net/amber/commit/227f99d3

8233555: [TESTBUG] JRadioButton tests failing on MacoS

Reviewed-by: serb

! test/jdk/ProblemList.txt

Changeset: 81c06242
Author:    Carter Kozak <ckozak at ckozak.net>
Committer: Erik Gahlin <egahlin at openjdk.org>
Date:      2021-01-07 06:11:32 +0000
URL:       https://git.openjdk.java.net/amber/commit/81c06242

8259354: Fix race condition in AbstractEventStream.nextThreadName

Reviewed-by: egahlin

! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java

Changeset: 0e6de4eb
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2021-01-07 12:15:23 +0000
URL:       https://git.openjdk.java.net/amber/commit/0e6de4eb

8259339: AllocateUninitializedArray C2 intrinsic fails with void.class input

Reviewed-by: kvn, chagedorn

! src/hotspot/share/opto/library_call.cpp
! test/hotspot/jtreg/compiler/intrinsics/unsafe/AllocateUninitializedArray.java

Changeset: 1c33847b
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2021-01-07 12:35:16 +0000
URL:       https://git.openjdk.java.net/amber/commit/1c33847b

8259067: bootclasspath append takes out object lock

Reviewed-by: lfoltan, sspitsyn, iklam, dholmes

! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/classLoader.hpp
! src/hotspot/share/classfile/classLoader.inline.hpp
! src/hotspot/share/prims/jvmtiEnv.cpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/mutexLocker.hpp

Changeset: 3f9f86f0
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2021-01-07 12:39:44 +0000
URL:       https://git.openjdk.java.net/amber/commit/3f9f86f0

8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006

Reviewed-by: clanger, mdoerr

! make/modules/java.desktop/lib/Awt2dLibraries.gmk

Changeset: f91f92dc
Author:    Harold Seigel <hseigel at openjdk.org>
Date:      2021-01-07 13:18:50 +0000
URL:       https://git.openjdk.java.net/amber/commit/f91f92dc

8259317: Remove JVM option BreakAtWarning

Reviewed-by: lfoltan, coleenp

! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/utilities/debug.cpp

Changeset: 8530ef0e
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2021-01-07 17:13:41 +0000
URL:       https://git.openjdk.java.net/amber/commit/8530ef0e

8259375: JvmtiExport::jni_Get/SetField_probe calls do not need ResetNoHandleMark

Reviewed-by: lfoltan, dcubed

! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvmtiExport.cpp

Changeset: 2e99e28f
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2021-01-07 17:49:48 +0000
URL:       https://git.openjdk.java.net/amber/commit/2e99e28f

8213126: java/awt/Window/MainKeyWindow/TestMainKeyWindow.java time-out on mac10.13

Reviewed-by: psadhukhan

! test/jdk/ProblemList.txt
! test/jdk/java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java

Changeset: 4ce83f2a
Author:    Rajan Halade <rhalade at openjdk.org>
Date:      2021-01-07 18:47:43 +0000
URL:       https://git.openjdk.java.net/amber/commit/4ce83f2a

8039278: console.sh failed Automatically with exit code 1

Reviewed-by: xuelei, weijun

! test/jdk/TEST.groups
- test/jdk/sun/security/tools/keytool/console.sh

Changeset: d8ad6301
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
Date:      2021-01-07 18:57:58 +0000
URL:       https://git.openjdk.java.net/amber/commit/d8ad6301

8258772: Some runtime/cds tests fail with +LogCompilation or +StressX

Emit warning about TraceDependencies results in
ClassHierarchyWalker::count_find_witness_calls() only if TraceDependencies is
actually enabled. Use standard warning() function instead of ad hoc printing.
Remove warning about using Stress(LCM|GCM|IGVN) without LogCompilation in
Compile::Compile(), and add the information to the description of the StressSeed
option instead. These changes prevent false test failures when using
LogCompilation or Stress(LCM|GCM|IGVN).

Reviewed-by: chagedorn, kvn, thartmann

! src/hotspot/share/code/dependencies.cpp
! src/hotspot/share/opto/c2_globals.hpp
! src/hotspot/share/opto/compile.cpp

Changeset: bc565414
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
Date:      2021-01-07 20:43:48 +0000
URL:       https://git.openjdk.java.net/amber/commit/bc565414

8256535: C2: randomize CCP processing order for stress testing

Add 'StressCCP' option to randomize the selection of the node to be examined in
each CCP iteration.

Reviewed-by: chagedorn, kvn, thartmann

! src/hotspot/share/opto/c2_globals.hpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/phaseX.cpp
- test/hotspot/jtreg/compiler/arguments/TestStressIGVNOptions.java
+ test/hotspot/jtreg/compiler/arguments/TestStressOptions.java
! test/hotspot/jtreg/compiler/debug/TestGenerateStressSeed.java
- test/hotspot/jtreg/compiler/debug/TestStressIGVN.java
+ test/hotspot/jtreg/compiler/debug/TestStressIGVNAndCCP.java

Changeset: 2659bc44
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2021-01-07 20:57:11 +0000
URL:       https://git.openjdk.java.net/amber/commit/2659bc44

8259274: Increase timeout duration in sun/nio/ch/TestMaxCachedBufferSize.java

Reviewed-by: lancea

! test/jdk/sun/nio/ch/TestMaxCachedBufferSize.java

Changeset: 73f54153
Author:    Chris Hegarty <chegar at openjdk.org>
Date:      2021-01-02 19:29:50 +0000
URL:       https://git.openjdk.java.net/amber/commit/73f54153

8258955: (bf) slice(int, int) on view buffers fails to adjust index according to primitive size

Reviewed-by: alanb

! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template
! test/jdk/java/nio/Buffer/ByteBufferViews.java

Changeset: 216c2ec0
Author:    Jie Fu <jiefu at openjdk.org>
Date:      2021-01-04 23:41:51 +0000
URL:       https://git.openjdk.java.net/amber/commit/216c2ec0

8258703: Incorrect 512-bit vector registers restore on x86_32

Reviewed-by: kvn, sviswanathan

! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp

Changeset: 4ffbe841
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2021-01-05 11:40:25 +0000
URL:       https://git.openjdk.java.net/amber/commit/4ffbe841

8256266: Binding variables don't correctly support declaration annotations and the final modifier

Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotations.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
+ test/langtools/tools/javac/patterns/Annotations.java
! test/langtools/tools/javac/patterns/BindingsTest1.java
! test/langtools/tools/javac/patterns/BindingsTest2.java
! test/langtools/tools/javac/patterns/BindingsTest2.out
+ test/langtools/tools/javac/patterns/NoModifiersOnBinding.java
+ test/langtools/tools/javac/patterns/NoModifiersOnBinding.out

Changeset: 6775113c
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2021-01-05 13:06:54 +0000
URL:       https://git.openjdk.java.net/amber/commit/6775113c

8258393: Shenandoah: "graph should be schedulable" assert failure

Reviewed-by: rkennke, thartmann

! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp
! src/hotspot/share/opto/loopnode.cpp
+ test/hotspot/jtreg/gc/shenandoah/compiler/TestBadRawMemoryAfterCall.java

Changeset: bbc2e951
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2021-01-05 13:39:57 +0000
URL:       https://git.openjdk.java.net/amber/commit/bbc2e951

8257906: JFR: RecordingStream leaks memory

Reviewed-by: mgronlun
Backport-of: 3c6648501589bf36945340cb1e82c833ebd7485d

! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingStream.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ChunkParser.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventDirectoryStream.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventFileStream.java

Changeset: b7940aa1
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2021-01-05 16:15:28 +0000
URL:       https://git.openjdk.java.net/amber/commit/b7940aa1

8259027: NullPointerException in makeMappedSegment due to NULL Unmapper when length of segment is 0

Reviewed-by: chegar, uschindler

! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MappedMemorySegmentImpl.java
! test/jdk/java/foreign/TestByteBuffer.java

Changeset: 50bf4330
Author:    Sandhya Viswanathan <sviswanathan at openjdk.org>
Date:      2021-01-05 17:42:22 +0000
URL:       https://git.openjdk.java.net/amber/commit/50bf4330

8259213: Vector conversion with part > 0 is not getting intrinsic implementation

Reviewed-by: psandoz

! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractShuffle.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java

Changeset: d5293067
Author:    Vicente Romero <vromero at openjdk.org>
Date:      2021-01-05 21:35:47 +0000
URL:       https://git.openjdk.java.net/amber/commit/d5293067

8213032: program fails with LambdaConversionException at execution time

Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/langtools/tools/javac/lambda/methodReferenceExecution/MethodReferenceIntersection4.java

Changeset: 554e60c4
Author:    Wang Huang <whuang at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2021-01-06 01:49:15 +0000
URL:       https://git.openjdk.java.net/amber/commit/554e60c4

8258989: JVM is failed to inline in jdk.internal.vm.vector.VectorSupport::convert

Co-authored-by: He Xuejin <hexuejin2 at huawei.com>
Reviewed-by: vlivanov, thartmann

! src/hotspot/share/opto/vectorIntrinsics.cpp

Changeset: 80110dac
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2021-01-06 06:36:29 +0000
URL:       https://git.openjdk.java.net/amber/commit/80110dac

8259007: This test printed a blank page

Reviewed-by: prr, serb

! src/java.desktop/windows/classes/sun/awt/windows/WPathGraphics.java
! src/java.desktop/windows/classes/sun/awt/windows/WPrinterJob.java
! src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp
- test/jdk/java/awt/print/PathPrecisionScaleFactor/PathPrecisionScaleFactorTest.java

Changeset: e66187d8
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2021-01-06 12:18:43 +0000
URL:       https://git.openjdk.java.net/amber/commit/e66187d8

8259032: MappedMemorySegmentImpl#makeMappedSegment() ignores Unmapper#pagePosition

Co-authored-by: Uwe Schindler <uschindler at openjdk.org>
Reviewed-by: alanb

! src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java
! test/jdk/java/foreign/TestByteBuffer.java

Changeset: ad456787
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-06 13:27:57 +0000
URL:       https://git.openjdk.java.net/amber/commit/ad456787

8258558: Revert changes for JDK-8252505 and related issues

Reviewed-by: kvn

! src/hotspot/share/c1/c1_Compiler.cpp
! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/c1/c1_LIRGenerator.cpp
! src/hotspot/share/c1/c1_LIRGenerator.hpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/ci/ciMethod.hpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/vmIntrinsics.cpp
! src/hotspot/share/classfile/vmIntrinsics.hpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/compiler/compilerOracle.cpp
! src/hotspot/share/compiler/compilerOracle.hpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/classes.hpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/library_call.hpp
! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/memnode.hpp
! src/hotspot/share/opto/node.hpp
! src/hotspot/share/opto/regmask.cpp
! src/hotspot/share/opto/regmask.hpp
! src/hotspot/share/runtime/vmStructs.cpp
! test/hotspot/jtreg/ProblemList-Xcomp.txt
! test/hotspot/jtreg/TEST.groups
- test/hotspot/jtreg/compiler/blackhole/BlackholeDiagnosticUnlockTest.java
- test/hotspot/jtreg/compiler/blackhole/BlackholeInstanceReturnTest.java
- test/hotspot/jtreg/compiler/blackhole/BlackholeInstanceTest.java
- test/hotspot/jtreg/compiler/blackhole/BlackholeNonVoidWarningTest.java
- test/hotspot/jtreg/compiler/blackhole/BlackholeNullCheckTest.java
- test/hotspot/jtreg/compiler/blackhole/BlackholeStaticReturnTest.java
- test/hotspot/jtreg/compiler/blackhole/BlackholeStaticTest.java
- test/hotspot/jtreg/compiler/blackhole/BlackholeTarget.java

Changeset: d25a1bed
Author:    Rafael Winterhalter <winterhalter at openjdk.org>
Committer: Joel Borggr?n-Franck <jfranck at openjdk.org>
Date:      2021-01-06 15:46:33 +0000
URL:       https://git.openjdk.java.net/amber/commit/d25a1bed

8259224: (ann) getAnnotatedReceiverType should not parameterize owner(s) of statically nested classes

Reviewed-by: jfranck

! src/java.base/share/classes/java/lang/reflect/Executable.java
+ test/jdk/java/lang/annotation/typeAnnotations/TestReceiverTypeOwnerType.java

Changeset: 4a5786b5
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2021-01-06 16:30:30 +0000
URL:       https://git.openjdk.java.net/amber/commit/4a5786b5

8259075: Update the copyright notice in the files generated by CLDR Converter tool

Reviewed-by: joehw

! make/jdk/src/classes/build/tools/cldrconverter/CopyrightHeaders.java

Changeset: f1bc4e05
Author:    Rajan Halade <rhalade at openjdk.org>
Date:      2021-01-06 16:39:08 +0000
URL:       https://git.openjdk.java.net/amber/commit/f1bc4e05

8259312: VerifyCACerts.java fails as soneraclass2ca cert will expire in 90 days

Backport-of: 3be6e06958c4304cafee707a29d06d6b2cc5b76b

! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java

Changeset: eef43be7
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2021-01-06 18:52:59 +0000
URL:       https://git.openjdk.java.net/amber/commit/eef43be7

8251200: False positive messages about missing comments for serialization

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/SerializedFormBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java
+ test/langtools/jdk/javadoc/doclet/testSerialMissing/TestSerialMissing.java

Changeset: 4f914e21
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2021-01-06 19:26:17 +0000
URL:       https://git.openjdk.java.net/amber/commit/4f914e21

8249633: doclint reports missing javadoc for JavaFX property methods that have a property description

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MemberSummaryBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java
! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java

Changeset: 555641ed
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
Date:      2021-01-07 21:17:35 +0000
URL:       https://git.openjdk.java.net/amber/commit/555641ed

Merge

! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/ci/ciMethod.hpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/vmIntrinsics.cpp
! src/hotspot/share/classfile/vmIntrinsics.hpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/compiler/compilerOracle.cpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/vectorIntrinsics.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! test/hotspot/jtreg/TEST.groups
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/ci/ciMethod.hpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/vmIntrinsics.cpp
! src/hotspot/share/classfile/vmIntrinsics.hpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/compiler/compilerOracle.cpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/library_call.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/vectorIntrinsics.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! test/hotspot/jtreg/TEST.groups

Changeset: 1133c43f
Author:    duke <duke at openjdk.org>
Date:      2021-01-07 22:01:41 +0000
URL:       https://git.openjdk.java.net/amber/commit/1133c43f

Automatic merge of master into stats-before-this-super

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java


From attila at hontvari.net  Fri Jan  8 12:59:56 2021
From: attila at hontvari.net (=?UTF-8?Q?Hontv=c3=a1ri_Attila?=)
Date: Fri, 8 Jan 2021 13:59:56 +0100
Subject: patterns as types
Message-ID: <e2a37734-cc71-4c77-d3b2-1a2b5efb988a@hontvari.net>

Hello,

I have a question about the static patterns feature described in the 
last published document [1]. If we have a code such as if (s instanceof 
Shape.redCube(__)) { ... }, then can Shape.redCube be looked as a 
"type"? Probably Shape instances are only classified by some field 
values, but I feel these patterns as ad-hoc types, which could be part 
of the type system (if we ignore that that they bind the extracted 
values to some variables).

If they were real types, then for example we could write code like this 
variable definition:
 ??? LocalDate.of(__, JANUARY, 1) firstDayOfSomeYear = ...;
So it would be explicitly specified and automatically ensured that this 
variable can only contain LocalDate objects that represents the first 
day of any year.

This can be probably an overkill, but the same technique can be used to 
solve part of the nullability problem, if we defined a static pattern 
Objects.nonNull:

 ??? class Person {
 ??????? private final Objects.nonNull(String) firstName, lastName;
 ??????? ...
 ??? }

Combined with static imports:

 ??? import static java.lang.Objects.nonNull;

 ??? class Person {
 ??????? private final nonNull(String) firstName, lastName;
 ??????? ...
 ??? }

And nullable String values could be assigned to the fields with an ugly 
cast such as ((nonNull(String)) someName) which would throw an exception 
if the value doesn't conform to the nonNull pattern. Or if the return 
type of Objects.requireNonNull is changed to the pattern 
nonNull(String), then it can be also used instead to get a 
nonNull(String) value, in the plain old way: this.firstName = 
Objects.requireNonNull(someName);

What do you think?


[1] 
https://github.com/openjdk/amber-docs/blob/master/site/design-notes/pattern-match-object-model.md


From sarma.swaranga at gmail.com  Fri Jan  8 20:32:19 2021
From: sarma.swaranga at gmail.com (Swaranga Sarma)
Date: Fri, 8 Jan 2021 12:32:19 -0800
Subject: Array patterns (and varargs patterns)
In-Reply-To: <68b0c3fc-d0c5-13c7-5306-ac0b7b829ca0@oracle.com>
References: <5f55e727-8a29-3bdf-57ec-6ec6245ef5c5@oracle.com>
 <CAAfFNYF5bjeGeb1nhaUpmnY641cHxxa16GKAN1c6DwNY8g0Paw@mail.gmail.com>
 <CAAfFNYHX3MuhtpGM4qu6E+Rg7KQ9226d+Qa88rSZCUExX9DTKg@mail.gmail.com>
 <D542D6C8-4C46-4F4D-8852-BF36D705AD60@oracle.com>
 <CAAfFNYEXye1TX-6ax0BzZc+5zvX1=AF9N=LqfXRvG1B_CaLs5A@mail.gmail.com>
 <68b0c3fc-d0c5-13c7-5306-ac0b7b829ca0@oracle.com>
Message-ID: <CAGZD2TBh58XtwnMFsQd6SX5Z1jXrn+uYm29f1g8xufe9LyuwyA@mail.gmail.com>

I am a little confused by the expression on the matcher, i.e the
Integer.parseInt(var i) - it is not clear what is happening there and I
don't think I have seen it before. Can someone explain what is being
expressed by that case label? Is it "match a String array with two elements
the second of which is a valid Integer represented as a String value"?

Here is the snippet:

    switch (limitString.split(":")) {
        case String[] { var _, Integer.parseInt(var i) } ->
setMultilineLimit(DEPTH, i);
        case String[] { Integer.parseInt(var i) } ->
setMultilineLimit(LENGTH, i);
        default -> { setMultilineLimit(DEPTH, -1);
setMultilineLimit(LENGTH, -1); }

    }


Regards

Swaranga


On Wed, Jan 6, 2021 at 8:44 AM Brian Goetz <brian.goetz at oracle.com> wrote:

>
>
> > Other languages have patent matching on head and tail of lists. Adding
> > this may mean there should be additional syntax.
>
> I alluded to this in my mail, hoping that people wouldn't allow
> themselves to be distracted by this particular siren song:
>
> <digression>
> People are immediately going to ask "can I bind something to the
> remainder"; I think this is mostly an "attractive distraction", and
> would prefer to not have this dominate the discussion.
> </digression>
>
> The idiom of "match a list by matching (head, tail)", which works great
> in Lisp and Haskell, is that (a) the representation of lists in Lisp and
> Haskell is a cons-cell, and (b) these language have tail-call
> elimination, so that processing a list by recursion in this manner is
> natural, efficient, and doesn't SOE.  Java has neither of these, so
> grafting the illusion of this model when the runtime is not suited to it
> is just moving the problem one foot down the road, but ultimately is not
> going to be satisfying.  The performance will be poor, and we'll SOE on
> lists longer than a few tens of thousands of elements.
>
> The bottom line here is that idioms from Language X are very much
> connected to _the rest of language X_.  Ignoring this rarely works out
> well.
>
> > Another issue is if the array is shorter say 0 length and one has:
> >
> >        if (arr instanceof int[] { var a, var b, ... }) { ... }
> >
> > Will this be an ArrayIndexOutOfBoundException or another exception? If
> > it is a reference type `a` and `b` can be null.
>
> No.  Pattern matching is inherently conditional; the match above says
> "does `arr` match this array pattern".  Matching the array pattern means
> being an array, _and_ having the right number of elements, _and_ having
> those elements match the nested patterns. Matching should never throw
> (though, once we allow users to write patterns that have code in them,
> it will be possible to do things like NPE, but those are bugs.)
>
> >
> >
> > On Wed, 6 Jan 2021 at 15:31, Gavin Bierman <gavin.bierman at oracle.com
> > <mailto:gavin.bierman at oracle.com>> wrote:
> >
> >     This is a feature that other languages call an ?as pattern?,
> >     because you are adding a new pattern variable binding to another
> >     pattern (Standard ML used ?as?, Haskell uses ?@? but calls it an
> >     as pattern). It?s on our list of things to consider; part of the
> >     consideration is whether it merits special syntax along with the
> >     parsing issues of not having special syntax.
> >
> >     Gavin
> >
> >     > On 6 Jan 2021, at 05:44, Suminda Sirinath Salpitikorala
> >     Dharmasena <sirinath1978m at gmail.com
> >     <mailto:sirinath1978m at gmail.com>> wrote:
> >     >
> >     > Can we have something like:
> >     >
> >     >        if (arr instanceof String[] { var a, var b, ... }
> >     stringArray) {
> >     > ... }
> >     >
> >     > `stringArray` is optional but if present this will referrer to
> >     the whole
> >     > array.
> >     >
> >     >>
> >
>
>

From youngty1997 at gmail.com  Sat Jan  9 03:22:38 2021
From: youngty1997 at gmail.com (Ty Young)
Date: Fri, 8 Jan 2021 21:22:38 -0600
Subject: Array patterns (and varargs patterns)
In-Reply-To: <CAGZD2TBh58XtwnMFsQd6SX5Z1jXrn+uYm29f1g8xufe9LyuwyA@mail.gmail.com>
References: <5f55e727-8a29-3bdf-57ec-6ec6245ef5c5@oracle.com>
 <CAAfFNYF5bjeGeb1nhaUpmnY641cHxxa16GKAN1c6DwNY8g0Paw@mail.gmail.com>
 <CAAfFNYHX3MuhtpGM4qu6E+Rg7KQ9226d+Qa88rSZCUExX9DTKg@mail.gmail.com>
 <D542D6C8-4C46-4F4D-8852-BF36D705AD60@oracle.com>
 <CAAfFNYEXye1TX-6ax0BzZc+5zvX1=AF9N=LqfXRvG1B_CaLs5A@mail.gmail.com>
 <68b0c3fc-d0c5-13c7-5306-ac0b7b829ca0@oracle.com>
 <CAGZD2TBh58XtwnMFsQd6SX5Z1jXrn+uYm29f1g8xufe9LyuwyA@mail.gmail.com>
Message-ID: <4e081831-7e59-924f-377f-a731c807cc57@gmail.com>


On 1/8/21 2:32 PM, Swaranga Sarma wrote:
> I am a little confused by the expression on the matcher, i.e the
> Integer.parseInt(var i) - it is not clear what is happening there and I
> don't think I have seen it before. Can someone explain what is being
> expressed by that case label? Is it "match a String array with two elements
> the second of which is a valid Integer represented as a String value"?
>
> Here is the snippet:
>
>      switch (limitString.split(":")) {
>          case String[] { var _, Integer.parseInt(var i) } ->
> setMultilineLimit(DEPTH, i);
>          case String[] { Integer.parseInt(var i) } ->
> setMultilineLimit(LENGTH, i);
>          default -> { setMultilineLimit(DEPTH, -1);
> setMultilineLimit(LENGTH, -1); }
>
>      }


You aren't alone. People on social media are having trouble figuring out 
this code too.


I think in the case of the first switch, it was intended to be written like:


case String[] { String _, int i = Integer.parseInt(String b) } -> 
setMultilineLimit(DEPTH, i);


Where String _ and String b replaces var _ and var i respectively and a 
variable is used to store the returned int from Integer.parseInt, which 
is called i, and passed to setMultilineLimit.


setMultilineLimit supposedly accepts an int and if var i, as defined in 
Brian's example, was meant to be a String, then there is no way that 
code would have worked unless setMultilineLimit accepted a String and 
the call to Integer.parseInt was a mistake. Variable i is already 
defined as a String as it's passed to Integer.parseint, so it can't be 
reused as an int later. A pure underscore(_) isn't even a valid variable 
name.


It was a really bad example not helped by the variable naming and the 
use of var, IMO. It is somewhat amusing that JDK developers lecture 
other people about their variable and method naming yet write names a 
high school computer science teacher would not find acceptable. var was 
a bad addition to the language already and its use in code examples and 
documentation like this really drives that point home.


But I digress, pot shots and clapbacks are more meant for social 
media... although I suspect Brian seems to be the type to just block 
people on Twitter for disagreements.


>
>
> Regards
>
> Swaranga
>
>
> On Wed, Jan 6, 2021 at 8:44 AM Brian Goetz <brian.goetz at oracle.com> wrote:
>
>>
>>> Other languages have patent matching on head and tail of lists. Adding
>>> this may mean there should be additional syntax.
>> I alluded to this in my mail, hoping that people wouldn't allow
>> themselves to be distracted by this particular siren song:
>>
>> <digression>
>> People are immediately going to ask "can I bind something to the
>> remainder"; I think this is mostly an "attractive distraction", and
>> would prefer to not have this dominate the discussion.
>> </digression>
>>
>> The idiom of "match a list by matching (head, tail)", which works great
>> in Lisp and Haskell, is that (a) the representation of lists in Lisp and
>> Haskell is a cons-cell, and (b) these language have tail-call
>> elimination, so that processing a list by recursion in this manner is
>> natural, efficient, and doesn't SOE.  Java has neither of these, so
>> grafting the illusion of this model when the runtime is not suited to it
>> is just moving the problem one foot down the road, but ultimately is not
>> going to be satisfying.  The performance will be poor, and we'll SOE on
>> lists longer than a few tens of thousands of elements.
>>
>> The bottom line here is that idioms from Language X are very much
>> connected to _the rest of language X_.  Ignoring this rarely works out
>> well.
>>
>>> Another issue is if the array is shorter say 0 length and one has:
>>>
>>>         if (arr instanceof int[] { var a, var b, ... }) { ... }
>>>
>>> Will this be an ArrayIndexOutOfBoundException or another exception? If
>>> it is a reference type `a` and `b` can be null.
>> No.  Pattern matching is inherently conditional; the match above says
>> "does `arr` match this array pattern".  Matching the array pattern means
>> being an array, _and_ having the right number of elements, _and_ having
>> those elements match the nested patterns. Matching should never throw
>> (though, once we allow users to write patterns that have code in them,
>> it will be possible to do things like NPE, but those are bugs.)
>>
>>>
>>> On Wed, 6 Jan 2021 at 15:31, Gavin Bierman <gavin.bierman at oracle.com
>>> <mailto:gavin.bierman at oracle.com>> wrote:
>>>
>>>      This is a feature that other languages call an ?as pattern?,
>>>      because you are adding a new pattern variable binding to another
>>>      pattern (Standard ML used ?as?, Haskell uses ?@? but calls it an
>>>      as pattern). It?s on our list of things to consider; part of the
>>>      consideration is whether it merits special syntax along with the
>>>      parsing issues of not having special syntax.
>>>
>>>      Gavin
>>>
>>>      > On 6 Jan 2021, at 05:44, Suminda Sirinath Salpitikorala
>>>      Dharmasena <sirinath1978m at gmail.com
>>>      <mailto:sirinath1978m at gmail.com>> wrote:
>>>      >
>>>      > Can we have something like:
>>>      >
>>>      >        if (arr instanceof String[] { var a, var b, ... }
>>>      stringArray) {
>>>      > ... }
>>>      >
>>>      > `stringArray` is optional but if present this will referrer to
>>>      the whole
>>>      > array.
>>>      >
>>>      >>
>>>
>>

From youngty1997 at gmail.com  Sat Jan  9 12:02:00 2021
From: youngty1997 at gmail.com (Ty Young)
Date: Sat, 9 Jan 2021 06:02:00 -0600
Subject: Array patterns (and varargs patterns)
In-Reply-To: <4e081831-7e59-924f-377f-a731c807cc57@gmail.com>
References: <5f55e727-8a29-3bdf-57ec-6ec6245ef5c5@oracle.com>
 <CAAfFNYF5bjeGeb1nhaUpmnY641cHxxa16GKAN1c6DwNY8g0Paw@mail.gmail.com>
 <CAAfFNYHX3MuhtpGM4qu6E+Rg7KQ9226d+Qa88rSZCUExX9DTKg@mail.gmail.com>
 <D542D6C8-4C46-4F4D-8852-BF36D705AD60@oracle.com>
 <CAAfFNYEXye1TX-6ax0BzZc+5zvX1=AF9N=LqfXRvG1B_CaLs5A@mail.gmail.com>
 <68b0c3fc-d0c5-13c7-5306-ac0b7b829ca0@oracle.com>
 <CAGZD2TBh58XtwnMFsQd6SX5Z1jXrn+uYm29f1g8xufe9LyuwyA@mail.gmail.com>
 <4e081831-7e59-924f-377f-a731c807cc57@gmail.com>
Message-ID: <92df15a0-3379-7558-f35f-b0a0dacb9e4a@gmail.com>


On 1/8/21 9:22 PM, Ty Young wrote:
>
> On 1/8/21 2:32 PM, Swaranga Sarma wrote:
>> I am a little confused by the expression on the matcher, i.e the
>> Integer.parseInt(var i) - it is not clear what is happening there and I
>> don't think I have seen it before. Can someone explain what is being
>> expressed by that case label? Is it "match a String array with two 
>> elements
>> the second of which is a valid Integer represented as a String value"?
>>
>> Here is the snippet:
>>
>> ???? switch (limitString.split(":")) {
>> ???????? case String[] { var _, Integer.parseInt(var i) } ->
>> setMultilineLimit(DEPTH, i);
>> ???????? case String[] { Integer.parseInt(var i) } ->
>> setMultilineLimit(LENGTH, i);
>> ???????? default -> { setMultilineLimit(DEPTH, -1);
>> setMultilineLimit(LENGTH, -1); }
>>
>> ???? }
>
>
> You aren't alone. People on social media are having trouble figuring 
> out this code too.
>
>
> I think in the case of the first switch, it was intended to be written 
> like:
>
>
> case String[] { String _, int i = Integer.parseInt(String b) } -> 
> setMultilineLimit(DEPTH, i);
>
>
> Where String _ and String b replaces var _ and var i respectively and 
> a variable is used to store the returned int from Integer.parseInt, 
> which is called i, and passed to setMultilineLimit.
>
>
> setMultilineLimit supposedly accepts an int and if var i, as defined 
> in Brian's example, was meant to be a String, then there is no way 
> that code would have worked unless setMultilineLimit accepted a String 
> and the call to Integer.parseInt was a mistake. Variable i is already 
> defined as a String as it's passed to Integer.parseint, so it can't be 
> reused as an int later. A pure underscore(_) isn't even a valid 
> variable name.
>
>
> It was a really bad example not helped by the variable naming and the 
> use of var, IMO. It is somewhat amusing that JDK developers lecture 
> other people about their variable and method naming yet write names a 
> high school computer science teacher would not find acceptable. var 
> was a bad addition to the language already and its use in code 
> examples and documentation like this really drives that point home.
>
>
> But I digress, pot shots and clapbacks are more meant for social 
> media... although I suspect Brian seems to be the type to just block 
> people on Twitter for disagreements.


So I've been yelled at elsewhere about how rude this seemingly is and, 
in hindsight, it wasn't the best choice of words. I stand by that it's 
somewhat humorous that better variable names were not chosen in 
combination with var given the defense of var in the past, but parts of 
that were not needed. I apologies for that and the comment about 
blocking people, it wasn't needed either.


>
>
>>
>>
>> Regards
>>
>> Swaranga
>>
>>
>> On Wed, Jan 6, 2021 at 8:44 AM Brian Goetz <brian.goetz at oracle.com> 
>> wrote:
>>
>>>
>>>> Other languages have patent matching on head and tail of lists. Adding
>>>> this may mean there should be additional syntax.
>>> I alluded to this in my mail, hoping that people wouldn't allow
>>> themselves to be distracted by this particular siren song:
>>>
>>> <digression>
>>> People are immediately going to ask "can I bind something to the
>>> remainder"; I think this is mostly an "attractive distraction", and
>>> would prefer to not have this dominate the discussion.
>>> </digression>
>>>
>>> The idiom of "match a list by matching (head, tail)", which works great
>>> in Lisp and Haskell, is that (a) the representation of lists in Lisp 
>>> and
>>> Haskell is a cons-cell, and (b) these language have tail-call
>>> elimination, so that processing a list by recursion in this manner is
>>> natural, efficient, and doesn't SOE.? Java has neither of these, so
>>> grafting the illusion of this model when the runtime is not suited 
>>> to it
>>> is just moving the problem one foot down the road, but ultimately is 
>>> not
>>> going to be satisfying.? The performance will be poor, and we'll SOE on
>>> lists longer than a few tens of thousands of elements.
>>>
>>> The bottom line here is that idioms from Language X are very much
>>> connected to _the rest of language X_.? Ignoring this rarely works out
>>> well.
>>>
>>>> Another issue is if the array is shorter say 0 length and one has:
>>>>
>>>> ??????? if (arr instanceof int[] { var a, var b, ... }) { ... }
>>>>
>>>> Will this be an ArrayIndexOutOfBoundException or another exception? If
>>>> it is a reference type `a` and `b` can be null.
>>> No.? Pattern matching is inherently conditional; the match above says
>>> "does `arr` match this array pattern".? Matching the array pattern 
>>> means
>>> being an array, _and_ having the right number of elements, _and_ having
>>> those elements match the nested patterns. Matching should never throw
>>> (though, once we allow users to write patterns that have code in them,
>>> it will be possible to do things like NPE, but those are bugs.)
>>>
>>>>
>>>> On Wed, 6 Jan 2021 at 15:31, Gavin Bierman <gavin.bierman at oracle.com
>>>> <mailto:gavin.bierman at oracle.com>> wrote:
>>>>
>>>> ???? This is a feature that other languages call an ?as pattern?,
>>>> ???? because you are adding a new pattern variable binding to another
>>>> ???? pattern (Standard ML used ?as?, Haskell uses ?@? but calls it an
>>>> ???? as pattern). It?s on our list of things to consider; part of the
>>>> ???? consideration is whether it merits special syntax along with the
>>>> ???? parsing issues of not having special syntax.
>>>>
>>>> ???? Gavin
>>>>
>>>> ???? > On 6 Jan 2021, at 05:44, Suminda Sirinath Salpitikorala
>>>> ???? Dharmasena <sirinath1978m at gmail.com
>>>> ???? <mailto:sirinath1978m at gmail.com>> wrote:
>>>> ???? >
>>>> ???? > Can we have something like:
>>>> ???? >
>>>> ???? >??????? if (arr instanceof String[] { var a, var b, ... }
>>>> ???? stringArray) {
>>>> ???? > ... }
>>>> ???? >
>>>> ???? > `stringArray` is optional but if present this will referrer to
>>>> ???? the whole
>>>> ???? > array.
>>>> ???? >
>>>> ???? >>
>>>>
>>>

From brian.goetz at oracle.com  Sun Jan 10 19:44:06 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 10 Jan 2021 14:44:06 -0500
Subject: patterns as types
In-Reply-To: <e2a37734-cc71-4c77-d3b2-1a2b5efb988a@hontvari.net>
References: <e2a37734-cc71-4c77-d3b2-1a2b5efb988a@hontvari.net>
Message-ID: <62c2f82f-83ec-714c-45c6-f11949db1699@oracle.com>



> I have a question about the static patterns feature described in the 
> last published document [1]. If we have a code such as if (s 
> instanceof Shape.redCube(__)) { ... }, then can Shape.redCube be 
> looked as a "type"? Probably Shape instances are only classified by 
> some field values, but I feel these patterns as ad-hoc types, which 
> could be part of the type system (if we ignore that that they bind the 
> extracted values to some variables).

It depends what you mean by types.? At their most basic, types are sets 
of values, so yes, you could build a type system in which types were 
described by patterns.? (This is a form of _refinement type_.) But, what 
you are describing is a far cry from how the Java type system currently 
works.

That said, "patterns as types" is only a means to an end to at least 
part of what you're trying to do, so let's focus on that instead.

> If they were real types, then for example we could write code like 
> this variable definition:
> ??? LocalDate.of(__, JANUARY, 1) firstDayOfSomeYear = ...;

What you are alluding to is some form of _imperative match statement_, 
where you take a pattern and forcibly match it to a target.? This 
doesn't require types; it requires either a *total* pattern, or some 
sort of alternative in the event of non-match. This is exactly what 
https://github.com/openjdk/amber-docs/blob/master/site/design-notes/pattern-matching-for-java.md#pattern-bind-statements 
("pattern bind statement") is getting at.

The current thinking is that the LHS has to be a pattern that is total 
(or, optimistically total) on the static type of the RHS, as in:

 ??? Point(var x, var y) = aPoint;

Without encouraging a syntax bikeshed, there are several options for how 
to expose this:

 ?- A more traditional statement, like "let P = e".? This allows for 
more flexible handling of non-total patterns through an optional "else" 
clause, but is more limiting;
 ?- Treating this as a generalization of local variable declaration. 
Note that `Foo f = e`, which is currently a local variable declaration 
statement, could be reinterpreted as a pattern bind! Then we could bring 
in other total patterns (such as deconstruction patterns) too.

So the bottom line here is we can get to what you want, without the 
detour of calling the set of values matched by a pattern a "type".

> This can be probably an overkill, but the same technique can be used 
> to solve part of the nullability problem, if we defined a static 
> pattern Objects.nonNull:
>
> ??? class Person {
> ??????? private final Objects.nonNull(String) firstName, lastName;
> ??????? ...
> ??? }

This is a cute idea, but it sort of pushes the problem down the street a 
little bit -- how would we type-check assignments to `firstName`?? 
Assignments in Java don't throw; we statically type the RHS, and this 
guarantees that, if the RHS can be evaluated at all, the assignment will 
be type-safe and exception-free.? To do this, we'd have to also match 
against the same pattern at the assignment site, which I think would be 
pretty frustrating in practice.

I suspect you're thinking that "it would just throw if it didn't match", 
but that's a pretty new interpretation of both assignment and pattern 
matching; neither is supposed to throw.

Cheers,
-Brian

From brian.goetz at oracle.com  Sun Jan 10 19:50:39 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 10 Jan 2021 14:50:39 -0500
Subject: Array patterns (and varargs patterns)
In-Reply-To: <CAGZD2TBh58XtwnMFsQd6SX5Z1jXrn+uYm29f1g8xufe9LyuwyA@mail.gmail.com>
References: <5f55e727-8a29-3bdf-57ec-6ec6245ef5c5@oracle.com>
 <CAAfFNYF5bjeGeb1nhaUpmnY641cHxxa16GKAN1c6DwNY8g0Paw@mail.gmail.com>
 <CAAfFNYHX3MuhtpGM4qu6E+Rg7KQ9226d+Qa88rSZCUExX9DTKg@mail.gmail.com>
 <D542D6C8-4C46-4F4D-8852-BF36D705AD60@oracle.com>
 <CAAfFNYEXye1TX-6ax0BzZc+5zvX1=AF9N=LqfXRvG1B_CaLs5A@mail.gmail.com>
 <68b0c3fc-d0c5-13c7-5306-ac0b7b829ca0@oracle.com>
 <CAGZD2TBh58XtwnMFsQd6SX5Z1jXrn+uYm29f1g8xufe9LyuwyA@mail.gmail.com>
Message-ID: <9ef909eb-178e-1f0b-66ce-d27e040b0ebf@oracle.com>


> I am a little confused?by the expression on the matcher, i.e the 
> Integer.parseInt(var i) - it is not clear what is happening there and 
> I don't think I have seen it before. Can someone explain what is being 
> expressed by that case label?

This is a _nested pattern_.? One of the powerful things about patterns 
is that they compose; when I say:

 ??? if (p instanceof Point(int x, int y)) { ... }

the `int x` and `int y` that are the "arguments" of the deconstructor 
are actually _nested patterns_.? What this means is:

 ?? - test if p is a Point;
 ?? - if so, cast to Point, and invoke its (int, int) deconstruction 
pattern, which yields ints for the x and y components
 ?? - further match the resulting components to the patterns `int x` and 
`int y`, which happen to be total on `int`, and bind their target 
without reinterpretation.

We can compose more interesting patterns.? Suppose I have a record 
Point(int x, int y) , and a record Circle(Point center, int radius).? 
Then I can match:

 ??? if (shape instanceof Circle(Point(var x, var y) p, int r)) { ... }

This tests for circle-hood, extracts center and radius, and then further 
matches the center against Point(var x, var y), which happens to be 
total on Point.

So the nested patterns inside the STring[] { ... } are matched against 
the elements of the array.? Now, what does `Integer.parseInt(var i)` 
mean?? This is an example of a _static pattern_, which we don't have 
yet, but is part of the long-term story -- this is a (partial) pattern 
which applies to a String, which tries to parse the string as an int, 
and if so, binds the int.? In this way, we can compose the destructuring 
of the String array with the (possible) conversion from String to int, 
and either the whole thing matches (the thing is a string array, it has 
two elements, the first one can be parsed to an int, and we extract the 
int), or none of it does.

> Is it "match a String array with two elements the second of which is a 
> valid Integer represented as a String value"?

Yes :)

The code for this pattern would live in Integer, as a declared pattern, 
when such a thing is supported.

Cheers,
-Brian

> Here is the snippet:
>      switch (limitString.split(":")) {
>          case String[] { var _, Integer.parseInt(var i) } -> setMultilineLimit(DEPTH, i);
>          case String[] { Integer.parseInt(var i) } -> setMultilineLimit(LENGTH, i);
>          default -> { setMultilineLimit(DEPTH, -1); setMultilineLimit(LENGTH, -1); }
>      }
> Regards
> Swaranga
>
>
> On Wed, Jan 6, 2021 at 8:44 AM Brian Goetz <brian.goetz at oracle.com 
> <mailto:brian.goetz at oracle.com>> wrote:
>
>
>
>     > Other languages have patent?matching on head and tail of lists.
>     Adding
>     > this may mean there should be additional?syntax.
>
>     I alluded to this in my mail, hoping that people wouldn't allow
>     themselves to be distracted by this particular siren song:
>
>     <digression>
>     People are immediately going to ask "can I bind something to the
>     remainder"; I think this is mostly an "attractive distraction", and
>     would prefer to not have this dominate the discussion.
>     </digression>
>
>     The idiom of "match a list by matching (head, tail)", which works
>     great
>     in Lisp and Haskell, is that (a) the representation of lists in
>     Lisp and
>     Haskell is a cons-cell, and (b) these language have tail-call
>     elimination, so that processing a list by recursion in this manner is
>     natural, efficient, and doesn't SOE.? Java has neither of these, so
>     grafting the illusion of this model when the runtime is not suited
>     to it
>     is just moving the problem one foot down the road, but ultimately
>     is not
>     going to be satisfying.? The performance will be poor, and we'll
>     SOE on
>     lists longer than a few tens of thousands of elements.
>
>     The bottom line here is that idioms from Language X are very much
>     connected to _the rest of language X_.? Ignoring this rarely works
>     out
>     well.
>
>     > Another issue is if the array is shorter say 0 length and one has:
>     >
>     > ?????? if (arr instanceof int[] { var a, var b, ... }) { ... }
>     >
>     > Will this be an ArrayIndexOutOfBoundException or another
>     exception? If
>     > it is a reference type `a` and `b` can be null.
>
>     No.? Pattern matching is inherently conditional; the match above says
>     "does `arr` match this array pattern".? Matching the array pattern
>     means
>     being an array, _and_ having the right number of elements, _and_
>     having
>     those elements match the nested patterns. Matching should never throw
>     (though, once we allow users to write patterns that have code in
>     them,
>     it will be possible to do things like NPE, but those are bugs.)
>
>     >
>     >
>     > On Wed, 6 Jan 2021 at 15:31, Gavin Bierman
>     <gavin.bierman at oracle.com <mailto:gavin.bierman at oracle.com>
>     > <mailto:gavin.bierman at oracle.com
>     <mailto:gavin.bierman at oracle.com>>> wrote:
>     >
>     >? ? ?This is a feature that other languages call an ?as pattern?,
>     >? ? ?because you are adding a new pattern variable binding to another
>     >? ? ?pattern (Standard ML used ?as?, Haskell uses ?@? but calls it an
>     >? ? ?as pattern). It?s on our list of things to consider; part of the
>     >? ? ?consideration is whether it merits special syntax along with the
>     >? ? ?parsing issues of not having special syntax.
>     >
>     >? ? ?Gavin
>     >
>     >? ? ?> On 6 Jan 2021, at 05:44, Suminda Sirinath Salpitikorala
>     >? ? ?Dharmasena <sirinath1978m at gmail.com
>     <mailto:sirinath1978m at gmail.com>
>     >? ? ?<mailto:sirinath1978m at gmail.com
>     <mailto:sirinath1978m at gmail.com>>> wrote:
>     >? ? ?>
>     >? ? ?> Can we have something like:
>     >? ? ?>
>     >? ? ?>? ? ? ? if (arr instanceof String[] { var a, var b, ... }
>     >? ? ?stringArray) {
>     >? ? ?> ... }
>     >? ? ?>
>     >? ? ?> `stringArray` is optional but if present this will referrer to
>     >? ? ?the whole
>     >? ? ?> array.
>     >? ? ?>
>     >? ? ?>>
>     >
>


From brian.goetz at oracle.com  Sun Jan 10 20:24:52 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 10 Jan 2021 15:24:52 -0500
Subject: Array patterns (and varargs patterns)
In-Reply-To: <4e081831-7e59-924f-377f-a731c807cc57@gmail.com>
References: <5f55e727-8a29-3bdf-57ec-6ec6245ef5c5@oracle.com>
 <CAAfFNYF5bjeGeb1nhaUpmnY641cHxxa16GKAN1c6DwNY8g0Paw@mail.gmail.com>
 <CAAfFNYHX3MuhtpGM4qu6E+Rg7KQ9226d+Qa88rSZCUExX9DTKg@mail.gmail.com>
 <D542D6C8-4C46-4F4D-8852-BF36D705AD60@oracle.com>
 <CAAfFNYEXye1TX-6ax0BzZc+5zvX1=AF9N=LqfXRvG1B_CaLs5A@mail.gmail.com>
 <68b0c3fc-d0c5-13c7-5306-ac0b7b829ca0@oracle.com>
 <CAGZD2TBh58XtwnMFsQd6SX5Z1jXrn+uYm29f1g8xufe9LyuwyA@mail.gmail.com>
 <4e081831-7e59-924f-377f-a731c807cc57@gmail.com>
Message-ID: <3d7857f1-3f77-1278-9fcc-ee74410e1f2f@oracle.com>



On 1/8/2021 10:22 PM, Ty Young wrote:
>
> On 1/8/21 2:32 PM, Swaranga Sarma wrote:
>> I am a little confused by the expression on the matcher, i.e the
>> Integer.parseInt(var i) - it is not clear what is happening there and I
>> don't think I have seen it before. Can someone explain what is being
>> expressed by that case label? Is it "match a String array with two 
>> elements
>> the second of which is a valid Integer represented as a String value"?
>>
>> Here is the snippet:
>>
>> ???? switch (limitString.split(":")) {
>> ???????? case String[] { var _, Integer.parseInt(var i) } ->
>> setMultilineLimit(DEPTH, i);
>> ???????? case String[] { Integer.parseInt(var i) } ->
>> setMultilineLimit(LENGTH, i);
>> ???????? default -> { setMultilineLimit(DEPTH, -1);
>> setMultilineLimit(LENGTH, -1); }
>>
>> ???? }
>
>
> You aren't alone. People on social media are having trouble figuring 
> out this code too.

And, this is not surprising; this wasn't a message intended for the 
broad public, it was a message within the Expert Group, about a possible 
direction, who has been swimming in these issues for a long time, and 
involving the conjunction of several speculative features.? (Which is an 
important part of the EG discussion; looking down the road at how 
potential features fit together, before making decisions.)? It's fine to 
listen in, but you shouldn't necessarily expect that all the discussions 
will be unpacked for the consumption of casual observers, because that 
was not the audience for this message.?? That said, we're usually happy 
to explain when asked constructively (as Swaranga did), though sometimes 
the explanation is still "we don't know yet" or "its probably best to 
wait until XYZ settles down before trying to unpack all this."

> I think in the case of the first switch, it was intended to be written 
> like:

Nope.? The example was right, and your "corrections" were not. (Which is 
fine; as mentioned above, this is a speculative discussion in the EG 
about the conjunction of a number of features that are still on the 
drawing board.? This was not supposed to be a textbook example, it was 
an example offered in the course of informal discussion, to illustrate a 
specific point, between participants who are well-versed in the domain.)

> It was a really bad example 

Whoa there, cowboy.? Let me explain (again, unfortunately) how this works.

The EG lists are publicly readable, to provide transparency, but it is 
not the case that every message on the EG lists have to be written for 
the audience of casual outside observers -- nor is it reasonable to 
demand, or expect, this to be the case.? If and when we decide to commit 
to this particular constellation of features, a for-a-broader-audience 
explanation will be provided.? (When a feature is ready for broader 
consumption, you see the detail that goes into the writeups, which 
consume a great deal of time and effort.)? Expecting we do so for every 
idea being kicked around the EG would only serve to either (a) slow down 
the process even more, (b) stifle EG discussion, or (c) ensure we only 
discuss things when they are 100% perfect, complete, and written up for 
the least-common-denominator audience.? Neither of these outcomes is 
what you want (and in the case of the latter, you'd surely be screaming 
"behind closed doors") -- so we don't do that.? The cost of this is that 
the EG discussions are ... for the EG.? You are welcome to try and 
follow them, and even ask sensible clarifying questions (as Swaranga 
did), but recognize that you are not the target audience, and that the 
EG discussions have a necessarily different style and focus than "for 
public consumption" communications.? This is the compromise we make when 
we do this work in the open; those who want to listen in can, but should 
recognize that doing so can be hard work, and that they are not 
necessarily the target audience.

For the record, here's what a constructive amber-dev response to 
Swaranga might have looked like (if you still felt the need to respond):

"Brian's example combined a number of speculative pattern matching 
features, some of which have only been discussed on the EG list, so it 
is probably not surprising that seeing them put together for the first 
time was a lot to take in.? There's at least four prospective features 
being used together here: array patterns, nested patterns, unnamed 
(underscore) patterns, and static patterns.? We don't know which of 
these will actually make it into the language, but in this specific 
example, Brian was trying to show how array patterns could combine with 
the other forms of patterns to...."

See the difference?

We welcome constructive engagement, but if you can't contribute 
constructively (and we've had many examples that suggest this is a major 
challenge for you), perhaps the best path is to listen at home, quietly?



From sarma.swaranga at gmail.com  Mon Jan 11 00:29:01 2021
From: sarma.swaranga at gmail.com (Swaranga Sarma)
Date: Sun, 10 Jan 2021 16:29:01 -0800
Subject: Array patterns (and varargs patterns)
In-Reply-To: <9ef909eb-178e-1f0b-66ce-d27e040b0ebf@oracle.com>
References: <5f55e727-8a29-3bdf-57ec-6ec6245ef5c5@oracle.com>
 <CAAfFNYF5bjeGeb1nhaUpmnY641cHxxa16GKAN1c6DwNY8g0Paw@mail.gmail.com>
 <CAAfFNYHX3MuhtpGM4qu6E+Rg7KQ9226d+Qa88rSZCUExX9DTKg@mail.gmail.com>
 <D542D6C8-4C46-4F4D-8852-BF36D705AD60@oracle.com>
 <CAAfFNYEXye1TX-6ax0BzZc+5zvX1=AF9N=LqfXRvG1B_CaLs5A@mail.gmail.com>
 <68b0c3fc-d0c5-13c7-5306-ac0b7b829ca0@oracle.com>
 <CAGZD2TBh58XtwnMFsQd6SX5Z1jXrn+uYm29f1g8xufe9LyuwyA@mail.gmail.com>
 <9ef909eb-178e-1f0b-66ce-d27e040b0ebf@oracle.com>
Message-ID: <CAGZD2TAt2uZQZaj27N=q9jVLKSX0sKNSxvhdAP-C51qSMvu_Yg@mail.gmail.com>

Thank you. I read the pattern matching doc (
https://github.com/openjdk/amber-docs/blob/master/site/design-notes/pattern-matching-for-java.md)
and although the example in the main is a little more complicated than the
one in the doc, I think I understand it now.

I recall in one of your earlier talks, (probably
https://www.youtube.com/watch?v=n3_8YcYKScw) you talked about how at
runtime, switch dispatch could be implemented as a decision tree with
constant time (O(1)) complexity. Is this still true with static patterns in
the mix? I think with static patterns since the method will need to be
executed, from the code author's perspective, it is no longer a constant
time evaluation - is that fair to say?

Regards
Swaranga


On Sun, Jan 10, 2021 at 11:50 AM Brian Goetz <brian.goetz at oracle.com> wrote:

>
> I am a little confused by the expression on the matcher, i.e the
> Integer.parseInt(var i) - it is not clear what is happening there and I
> don't think I have seen it before. Can someone explain what is being
> expressed by that case label?
>
>
> This is a _nested pattern_.  One of the powerful things about patterns is
> that they compose; when I say:
>
>     if (p instanceof Point(int x, int y)) { ... }
>
> the `int x` and `int y` that are the "arguments" of the deconstructor are
> actually _nested patterns_.  What this means is:
>
>    - test if p is a Point;
>    - if so, cast to Point, and invoke its (int, int) deconstruction
> pattern, which yields ints for the x and y components
>    - further match the resulting components to the patterns `int x` and
> `int y`, which happen to be total on `int`, and bind their target without
> reinterpretation.
>
> We can compose more interesting patterns.  Suppose I have a record
> Point(int x, int y) , and a record Circle(Point center, int radius).  Then
> I can match:
>
>     if (shape instanceof Circle(Point(var x, var y) p, int r)) { ... }
>
> This tests for circle-hood, extracts center and radius, and then further
> matches the center against Point(var x, var y), which happens to be total
> on Point.
>
> So the nested patterns inside the STring[] { ... } are matched against the
> elements of the array.  Now, what does `Integer.parseInt(var i)` mean?
> This is an example of a _static pattern_, which we don't have yet, but is
> part of the long-term story -- this is a (partial) pattern which applies to
> a String, which tries to parse the string as an int, and if so, binds the
> int.  In this way, we can compose the destructuring of the String array
> with the (possible) conversion from String to int, and either the whole
> thing matches (the thing is a string array, it has two elements, the first
> one can be parsed to an int, and we extract the int), or none of it does.
>
> Is it "match a String array with two elements the second of which is a
> valid Integer represented as a String value"?
>
>
> Yes :)
>
> The code for this pattern would live in Integer, as a declared pattern,
> when such a thing is supported.
>
> Cheers,
> -Brian
>
> Here is the snippet:
>
>     switch (limitString.split(":")) {
>         case String[] { var _, Integer.parseInt(var i) } -> setMultilineLimit(DEPTH, i);
>         case String[] { Integer.parseInt(var i) } -> setMultilineLimit(LENGTH, i);
>         default -> { setMultilineLimit(DEPTH, -1); setMultilineLimit(LENGTH, -1); }
>
>     }
>
>  Regards
>
> Swaranga
>
>
> On Wed, Jan 6, 2021 at 8:44 AM Brian Goetz <brian.goetz at oracle.com> wrote:
>
>>
>>
>> > Other languages have patent matching on head and tail of lists. Adding
>> > this may mean there should be additional syntax.
>>
>> I alluded to this in my mail, hoping that people wouldn't allow
>> themselves to be distracted by this particular siren song:
>>
>> <digression>
>> People are immediately going to ask "can I bind something to the
>> remainder"; I think this is mostly an "attractive distraction", and
>> would prefer to not have this dominate the discussion.
>> </digression>
>>
>> The idiom of "match a list by matching (head, tail)", which works great
>> in Lisp and Haskell, is that (a) the representation of lists in Lisp and
>> Haskell is a cons-cell, and (b) these language have tail-call
>> elimination, so that processing a list by recursion in this manner is
>> natural, efficient, and doesn't SOE.  Java has neither of these, so
>> grafting the illusion of this model when the runtime is not suited to it
>> is just moving the problem one foot down the road, but ultimately is not
>> going to be satisfying.  The performance will be poor, and we'll SOE on
>> lists longer than a few tens of thousands of elements.
>>
>> The bottom line here is that idioms from Language X are very much
>> connected to _the rest of language X_.  Ignoring this rarely works out
>> well.
>>
>> > Another issue is if the array is shorter say 0 length and one has:
>> >
>> >        if (arr instanceof int[] { var a, var b, ... }) { ... }
>> >
>> > Will this be an ArrayIndexOutOfBoundException or another exception? If
>> > it is a reference type `a` and `b` can be null.
>>
>> No.  Pattern matching is inherently conditional; the match above says
>> "does `arr` match this array pattern".  Matching the array pattern means
>> being an array, _and_ having the right number of elements, _and_ having
>> those elements match the nested patterns. Matching should never throw
>> (though, once we allow users to write patterns that have code in them,
>> it will be possible to do things like NPE, but those are bugs.)
>>
>> >
>> >
>> > On Wed, 6 Jan 2021 at 15:31, Gavin Bierman <gavin.bierman at oracle.com
>> > <mailto:gavin.bierman at oracle.com>> wrote:
>> >
>> >     This is a feature that other languages call an ?as pattern?,
>> >     because you are adding a new pattern variable binding to another
>> >     pattern (Standard ML used ?as?, Haskell uses ?@? but calls it an
>> >     as pattern). It?s on our list of things to consider; part of the
>> >     consideration is whether it merits special syntax along with the
>> >     parsing issues of not having special syntax.
>> >
>> >     Gavin
>> >
>> >     > On 6 Jan 2021, at 05:44, Suminda Sirinath Salpitikorala
>> >     Dharmasena <sirinath1978m at gmail.com
>> >     <mailto:sirinath1978m at gmail.com>> wrote:
>> >     >
>> >     > Can we have something like:
>> >     >
>> >     >        if (arr instanceof String[] { var a, var b, ... }
>> >     stringArray) {
>> >     > ... }
>> >     >
>> >     > `stringArray` is optional but if present this will referrer to
>> >     the whole
>> >     > array.
>> >     >
>> >     >>
>> >
>>
>>
>

From brian.goetz at oracle.com  Mon Jan 11 00:54:22 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 10 Jan 2021 19:54:22 -0500
Subject: Array patterns (and varargs patterns)
In-Reply-To: <CAGZD2TAt2uZQZaj27N=q9jVLKSX0sKNSxvhdAP-C51qSMvu_Yg@mail.gmail.com>
References: <5f55e727-8a29-3bdf-57ec-6ec6245ef5c5@oracle.com>
 <CAAfFNYF5bjeGeb1nhaUpmnY641cHxxa16GKAN1c6DwNY8g0Paw@mail.gmail.com>
 <CAAfFNYHX3MuhtpGM4qu6E+Rg7KQ9226d+Qa88rSZCUExX9DTKg@mail.gmail.com>
 <D542D6C8-4C46-4F4D-8852-BF36D705AD60@oracle.com>
 <CAAfFNYEXye1TX-6ax0BzZc+5zvX1=AF9N=LqfXRvG1B_CaLs5A@mail.gmail.com>
 <68b0c3fc-d0c5-13c7-5306-ac0b7b829ca0@oracle.com>
 <CAGZD2TBh58XtwnMFsQd6SX5Z1jXrn+uYm29f1g8xufe9LyuwyA@mail.gmail.com>
 <9ef909eb-178e-1f0b-66ce-d27e040b0ebf@oracle.com>
 <CAGZD2TAt2uZQZaj27N=q9jVLKSX0sKNSxvhdAP-C51qSMvu_Yg@mail.gmail.com>
Message-ID: <e861f929-89f5-b9b3-746f-4a8f157cdd1a@oracle.com>



> I recall in one of your earlier talks, (probably 
> https://www.youtube.com/watch?v=n3_8YcYKScw 
> <https://urldefense.com/v3/__https://www.youtube.com/watch?v=n3_8YcYKScw__;!!GqivPVa7Brio!NNoWuHFSTT_CWr3esqqvb8CcBj440fvfjTEkaTpudwsi8FeLitelRqFUb3xGO9CeCg$>) 
> you talked about how at runtime, switch dispatch could be implemented 
> as a decision tree with constant time (O(1)) complexity. Is this still 
> true?with static patterns in the mix? I think with static patterns 
> since the method will need to be executed, from the code author's 
> perspective, it is no longer a constant time evaluation - is that fair 
> to say?
>

Your intuition is right, but we can still do a lot to minimize the 
cost.? We don't statically inline all the patterns as is done in e.g. 
this paper: https://dl.acm.org/doi/abs/10.1145/1411304.1411311 (Java is 
separately compiled), but we can at least do an O(1) dispatch on the 
type of the target, which is often enough to prune down the search space 
a lot, if not down to one candidate.? For example, in a switch with 
heterogeneous target types:

 ??? case Point(var x, var y):
 ??? case LocalDate(int year, int month, int day):
 ??? case Optional.of(var x):

we can still select which of the three are candidates in O(1) time (at 
most one is), because the target type of each pattern is different 
(String, LocalDate, Optioal) and we can do a hash-based lookup on 
target.getClass().? If we fall into the `case Optional.of()` pattern, we 
still have to execute the pattern to see if there is a value present, 
and might keep going after that if there are more, but we don't have to 
backtrack.

If we had a pathological case where the target types were all the same:

 ??? case palindromicString(var s):
 ??? case integerString(int i):
 ??? case floatString(float f):
 ??? case complexNumberString(Complex c):
 ??? ...

we would indeed have to linearly execute the patterns until we found a 
match.? But, even in this pathological case, the JIT may offer some help 
(inlining, etc) that optimizes the selection.



From udo at hoefel.eu  Mon Jan 11 11:06:36 2021
From: udo at hoefel.eu (=?utf-8?Q?Udo_H=C3=B6fel?=)
Date: Mon, 11 Jan 2021 12:06:36 +0100
Subject: sealed interfaces vs. default methods
Message-ID: <50680fx0BB6aMcx.RZmta@mo4-p00-ob.smtp.rzone.de>

Dear all,
I found some behavior of sealed generic interfaces with default methods that I find a bit unexpected. I put the examples from below also on GitHub ( https://github.com/uhoefel/java15_sealed_vs_default ).
Example:
Say we have an interface 

public sealed interface Interface<T> permits Impl_1 {}

and, separately, the implementation

public record Impl_1(Double value) implements Interface<Double> {}

Running the following works just fine:

public static void main(String[] args) {
    Interface<Double> q = new Impl_1(3.0);
    System.out.println(q instanceof Impl_1);
}

However, changing the interface to

public sealed interface Interface<T> permits Impl_1 {
	default int foo() {
		return 1;
	}
}

That is, adding just a simple default method to the interface produces the following compile error:

Exception in thread "main" java.lang.Error: Unresolved compilation problem: 
	Permitted type Impl_1 does not declare eu.hoefel.java15_sealed_vs_default.using_both.Interface<T> as direct super interface 

	at eu.hoefel.java15_sealed_vs_default.using_both.Interface.<clinit>(Interface.java:3)
	at eu.hoefel.java15_sealed_vs_default.using_both.Play.main(Play.java:5)

Putting the record inside the interface and removing the permits clause makes it work again, though:

public sealed interface Interface<T> {

	default int foo() {
		return 1;
	}

	public record Impl_1(Double value) implements Interface<Double> {}
}

I am on Windows 10 using 
openjdk version "15" 2020-09-15
OpenJDK Runtime Environment (build 15+36-1562)
OpenJDK 64-Bit Server VM (build 15+36-1562, mixed mode, sharing)

Also tested by a colleague with
openjdk version "15.0.1" 2020-10-20
OpenJDK Runtime Environment (build 15.0.1+9)
OpenJDK 64-Bit Server VM (build 15.0.1+9, mixed mode)

(Sorry if this doesn?t belong to this list)

Best regards & stay healthy,
Udo

-- 
Dr. Udo H?fel
Max Planck Institute for Plasma Physics, Branch Greifswald
Wendelsteinstra?e 1 (Room: 7.1 003), D-17491, Greifswald, Germany
Phone: +49 (0)3834 88 1825
Fax:?? +49 (0)3834 88 2509


From forax at univ-mlv.fr  Tue Jan 12 16:53:00 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 12 Jan 2021 17:53:00 +0100 (CET)
Subject: patterns as types
In-Reply-To: <e2a37734-cc71-4c77-d3b2-1a2b5efb988a@hontvari.net>
References: <e2a37734-cc71-4c77-d3b2-1a2b5efb988a@hontvari.net>
Message-ID: <193551285.1694745.1610470380255.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Hontv?ri Attila" <attila at hontvari.net>
> ?: "amber-dev" <amber-dev at openjdk.java.net>
> Envoy?: Vendredi 8 Janvier 2021 13:59:56
> Objet: patterns as types

> Hello,
> 
> I have a question about the static patterns feature described in the
> last published document [1]. If we have a code such as if (s instanceof
> Shape.redCube(__)) { ... }, then can Shape.redCube be looked as a
> "type"? Probably Shape instances are only classified by some field
> values, but I feel these patterns as ad-hoc types, which could be part
> of the type system (if we ignore that that they bind the extracted
> values to some variables).

Shape.redCube(_) is not a type, because the pattern requires to call the pattern method redCube() inside the class Shape at runtime,
so you only know if the shape is a red cube at runtime and not at compile time.

> 
> If they were real types, then for example we could write code like this
> variable definition:
> ??? LocalDate.of(__, JANUARY, 1) firstDayOfSomeYear = ...;
> So it would be explicitly specified and automatically ensured that this
> variable can only contain LocalDate objects that represents the first
> day of any year.
> 
> This can be probably an overkill, but the same technique can be used to
> solve part of the nullability problem, if we defined a static pattern
> Objects.nonNull:
> 
> ??? class Person {
> ??????? private final Objects.nonNull(String) firstName, lastName;
> ??????? ...
> ??? }
> 
> Combined with static imports:
> 
> ??? import static java.lang.Objects.nonNull;
> 
> ??? class Person {
> ??????? private final nonNull(String) firstName, lastName;
> ??????? ...
> ??? }
> 
> And nullable String values could be assigned to the fields with an ugly
> cast such as ((nonNull(String)) someName) which would throw an exception
> if the value doesn't conform to the nonNull pattern. Or if the return
> type of Objects.requireNonNull is changed to the pattern
> nonNull(String), then it can be also used instead to get a
> nonNull(String) value, in the plain old way: this.firstName =
> Objects.requireNonNull(someName);
> 
> What do you think?

You are moving the requireNonNull from each call site to one declaration site which isgood but at the same time, you will not have any error at compile time like in Kotlin / C#, which is bad.

> 
> 
> [1]
> https://github.com/openjdk/amber-docs/blob/master/site/design-notes/pattern-match-object-model.md

regards,
R?mi

From vicente.romero at oracle.com  Tue Jan 12 17:05:01 2021
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 12 Jan 2021 12:05:01 -0500
Subject: sealed interfaces vs. default methods
In-Reply-To: <50680fx0BB6aMcx.RZmta@mo4-p00-ob.smtp.rzone.de>
References: <50680fx0BB6aMcx.RZmta@mo4-p00-ob.smtp.rzone.de>
Message-ID: <3c269847-4196-eebb-5a52-70985b91e2a6@oracle.com>

Hi Udo,

Thanks for your mail. I can't reproduce the bug in JDK16, we have been 
changing this area recently and the new code has been pushed to the 
JDK16 code base. Could you please double check if your code works in JDK16?

Thanks,
Vicente

[1] https://bugs.openjdk.java.net/browse/JDK-8258972

On 1/11/21 6:06 AM, Udo H?fel wrote:
> Dear all,
> I found some behavior of sealed generic interfaces with default methods that I find a bit unexpected. I put the examples from below also on GitHub ( https://github.com/uhoefel/java15_sealed_vs_default ).
> Example:
> Say we have an interface
>
> public sealed interface Interface<T> permits Impl_1 {}
>
> and, separately, the implementation
>
> public record Impl_1(Double value) implements Interface<Double> {}
>
> Running the following works just fine:
>
> public static void main(String[] args) {
>      Interface<Double> q = new Impl_1(3.0);
>      System.out.println(q instanceof Impl_1);
> }
>
> However, changing the interface to
>
> public sealed interface Interface<T> permits Impl_1 {
> 	default int foo() {
> 		return 1;
> 	}
> }
>
> That is, adding just a simple default method to the interface produces the following compile error:
>
> Exception in thread "main" java.lang.Error: Unresolved compilation problem:
> 	Permitted type Impl_1 does not declare eu.hoefel.java15_sealed_vs_default.using_both.Interface<T> as direct super interface
>
> 	at eu.hoefel.java15_sealed_vs_default.using_both.Interface.<clinit>(Interface.java:3)
> 	at eu.hoefel.java15_sealed_vs_default.using_both.Play.main(Play.java:5)
>
> Putting the record inside the interface and removing the permits clause makes it work again, though:
>
> public sealed interface Interface<T> {
>
> 	default int foo() {
> 		return 1;
> 	}
>
> 	public record Impl_1(Double value) implements Interface<Double> {}
> }
>
> I am on Windows 10 using
> openjdk version "15" 2020-09-15
> OpenJDK Runtime Environment (build 15+36-1562)
> OpenJDK 64-Bit Server VM (build 15+36-1562, mixed mode, sharing)
>   
> Also tested by a colleague with
> openjdk version "15.0.1" 2020-10-20
> OpenJDK Runtime Environment (build 15.0.1+9)
> OpenJDK 64-Bit Server VM (build 15.0.1+9, mixed mode)
>
> (Sorry if this doesn?t belong to this list)
>
> Best regards & stay healthy,
> Udo
>


From duke at openjdk.java.net  Wed Jan 13 15:19:31 2021
From: duke at openjdk.java.net (duke)
Date: Wed, 13 Jan 2021 15:19:31 GMT
Subject: git: openjdk/amber-docs: Fix a typo in constant pattern example (#6)
Message-ID: <e07c9c93-7007-4241-8f53-9ac96267dabb@openjdk.java.net>

Changeset: 1f879cf4
Author:    Lalith Suresh <suresh.lalith at gmail.com>
Committer: GitHub <noreply at github.com>
Date:      2021-01-13 07:18:46 +0000
URL:       https://git.openjdk.java.net/amber-docs/commit/1f879cf4

Fix a typo in constant pattern example (#6)


! site/design-notes/pattern-match-object-model.md


From brian.goetz at oracle.com  Wed Jan 13 15:55:31 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 13 Jan 2021 10:55:31 -0500
Subject: Fwd: Wrappers feature proposal
In-Reply-To: <CAMg+uVQbbQBB4woqUBvgHFzLP-ZYQeCfjbLM777h3MpY+jvRFg@mail.gmail.com>
References: <CAMg+uVQbbQBB4woqUBvgHFzLP-ZYQeCfjbLM777h3MpY+jvRFg@mail.gmail.com>
Message-ID: <be5eceef-fe5c-ad87-0a60-d4d13cb7d36c@oracle.com>

The follows language feature proposal was received on the 
amber-spec-experts list.

Comments from the Legislative Analyst:

As always, language features should be evaluated through the lens of 
"why" (what problem do they solve) before dwelling on the pros and cons 
of a specific solution.

The underlying problem that this proposal attempts to solve is that 
writing a class C that implements interface I, delegating most methods 
of I to an instance of I, and overriding only a few (or none), requires 
a lot of low-value boilerplate to implement.? But the proposal seems to 
conflate the boilerplate reduction of this kind of inheritance, with a 
new semantics for lightweight wrappers, which I think would be better 
off separated.

The boilerplate problem illustrated here has been well known in Java for 
a long time; RFEs along these lines were circulated as early as 1998 
(e.g., https://bugs.openjdk.java.net/browse/JDK-4104202), if not 
earlier.? These go under the general category of "inheritance by 
delegation".? (Kotlin has more recently offered up its answer for this 
long-standing Java RFE:

 ??? class Derived(b: Base) : Base by b { ... }

which says that methods of `Base` not overriden by `Derived` are 
delegated to `b`.)

The specific solution proposed here doesn't really add to our 
understanding of the problem; the problem is a fairly well-understood 
one, and is ultimately "syntactic" at heart -- the language already 
provides us with a way to say what we want, it is just that the code for 
doing so is overly verbose, duplicative, and error-prone.? (The number 
of "no" answers in the Q&A belies the fact that it is an attempt to 
solve a very specific syntactic problem, which is often a clue that the 
problem is being solved at the wrong level.)

 From my perspective, were we to prioritize such a feature (which I 
don't think merits moving up on the priority list, even though it is a 
nice-to-have), I would prefer to see it as a pure implementation detail 
rather than a new kind of entity (as Wrappers suggests) or a new kind of 
delegation (as Kotlin's approach suggests.)? If C implements Foo, from 
the outside, we shouldn't care how it implements Foo, or constraint it 
to do so in a specific way.? Something like

 ??? class C implements I {
 ??????? private final I underlying;

 ??????? implements I via underlying;

 ??????? ... more methods
 ??? }

gets the job done without exposing this information where it doesn't 
belong.

A secondary problem with all the solutions I've seen for this problem is 
that they rely on some sort of build-time expansion of the interface, 
which means that default methods that are known at runtime but not at 
build time will not be delegated, even when they are in fact implemented 
by the class of the underlying delegee.? (This is a limitation of the 
JVM; there's no "method missing" suppport, so someone somewhere has to 
do the expansion of the interface.)? While this is not a fatal flaw, it 
is unfortunate.


-------- Forwarded Message --------
Subject: 	Wrappers feature proposal
Date: 	Wed, 13 Jan 2021 15:22:08 +0200
From: 	Dimitris Paltatzidis <dcrystalmails at gmail.com>
To: 	amber-spec-comments at openjdk.java.net



We use wrappers to override 1 or more instance methods of an instance.
*The wrappers that you and I have in our mind might not be the same. Bear
with me, for the concept.

Suppose we have an instance of class A and we want to override 1 of its
methods.
Currently, to achieve that we have to write:

class Wrapper extends A {//here A could be an interface (implements), but
we'll touch that later
private final A a;

Wrapper(A a) {
//We hope that A has a no args constructor
if (a == null) throw new NullPointerException();
this.a = a;
}

@Override public void method1() {this.a.method1();}
@Override public int method2() {return this.a.method2();}
.
.
.
@Override public void methodN() {this.a.methodN();}

@Override public void methodToOverride() {/*We override this method*/}
}

A few problems with the above implementation are:

1. Most of the time we want to override 1 or a small portion of all the
methods of A,
but we have to override all of them (all they way up the inheritance
hierarchy),
delegating to the originals of our A instance, just to reach the few we
actually
need to override. That is, we have to write a lot of boilerplate.
2. The class Wrapper is a child of A, so it possibly has instance fields
(hidden in A
and above in the inheritance hierarchy) that adds up to the memory
footprint of Wrapper,
even though there is no need for a Wrapper instance to have its own
state. Its state
is the state of its underlying A instance. It's only purpose is to
override or delegate.
3. There is no guarantee that there is an appropriate constructor in A to
call with super()
in the Wrapper constructor. So either you add one in A (if you have
access to it) that
initializes it in a "default for wrappers" state or you call one with
garbage values,
to hopefully pass any guards there might be. Either case, you end up
with a state that
could be illegal (or meaningless), just to pass through the Wrapper
constructor. All
that with additional work, and again to create a state that shouldn't be
there as it
eats memory and could be illegal and prone to bugs. Yes, interfaces
won't have the
constructor and state problems.

Ok, so how do these wrappers look like then?

wrapper Wrapper extends A {
@Override public void methodToOverride() {/*We override this method*/}
}

That's it. It is equivalent to the above verbose one.
Every single method that is not overridden will be delegated.
And to create it:

A a = new A(..);
Wrapper w = new Wrapper(a);

We can also have anonymous wrappers:

public static A unmodifiable(A a) {
return new wrapper A(a) {/*Override only the necessary methods*/};
}

But why? How can we benefit from wrappers?
- Unmodifiable collections is a good candidate in the JDK. They are the
so-called lightweight
wrappers that throw UnsupportedOperationException in any attempt to
change the underlying
collection through them.
- Spy wrappers. Suppose you have a window, and you want to get notified
every time its size
changes. You can just wrap it and override its getWidth() and getHeight()
methods, giving
the observer pattern another look.
- Possibly more..

What about interfaces?
- Sure, wrappers can work with them too, no matter how many you implement.
All non overridden
methods will be delegated to the underlying instance. Of course you must
supply the wrapper
construction with an instance that implements all of them.

What about anonymous wrappers and multiple interfaces?
- Well, it's a No here, to stay consistent with anonymous classes.

Should you be able to access the wrapped instance from a wrapper? And if
so, how?
- Yes. I'm not sure if the keyword is "super" or something else here
though..

Are wrappers just like classes?
- I like to think of wrappers as enhanced object references. They really do
reference you
to their underlying wrapped instance and sometimes you take a side trip
when methods are
overridden.

Can I add instance fields in wrappers?
- That defeats one of their purposes, No. Wrappers should be treated as if
they are their
underlying instance, not on their own. I'm not sure about static finals
though.

Can I add methods in wrappers?
- Just like the previous answer, wrappers shouldn't be viewed as
independent entities, so
it probably doesn't make sense to add methods. I'm not sure about statics
though.

Can I extend wrappers?
- No. They are implicitly final.

Are wrappers just a child class of the class they extend?
- So, I want the answer to be mostly No, because the semantics of wrappers
is to actually
"mutate" methods of a given instance of the class they extend (yes, that
is a subset
attribute of child classes too). They actually Are the class they extend
and not a child.
But, without breaking major rules here and to honor a lot of the Java
terms, they
technically are a child class.

Can I wrap a wrapper with another wrapper?
- No. One layer is sufficient. That is tricky to implement though, without
letting technical
dept into the game.

Can wrappers wrap a class that may have final methods?
- Sure, you just won't be able to override those final methods. Now, if the
class is not
final, but for some reason all of its methods are, then you would end up
with a wrapper
that basically just delegates. There is nothing illegal here, just
pointless.

Can wrappers wrap final classes?
- No.

Should wrappers be referenced by their type or by the type they wrap?
- I'm not sure if wrappers should be used as public API. I think they can
thrive as hidden
implementations making the API flatter, e.g.
Collections.unmodifiableCollection() returns
a Collection, even though the actual implementation is
UnmodifiableCollection, which is
a private static nested class. But, no one expects UnmodifiableCollection
as the returned
type. The same goes for wrappers too. Wrappers will mostly be returned by
methods as the
type they wrap, and if used in statements, it's better to have A w = new
Wrapper(a); as
opposed to Wrapper w = new Wrapper(a); If wrappers can't have methods of
their own, what's
the point of the latter statement? Also, the latter hides the actual type
of a (yes, good
naming conventions could help).

Can sealed classes and interfaces permit wrappers?
- Sure. Anonymous wrappers are the exception here just like anonymous
classes.

Can wrappers wrap sealed classes that don't permit them?
- No.

What about Serialization?
- Well, wrappers don't have a state of their own, so that's a good thing.
But, I can't tell
if it'll be a nightmare to get them to play together with it or not.

Ok, so .equals() is delegated, but what about == ?
- Normally you would expect wrappers to be instances of their own, having
an identity, but
I'm not sure what that identity is (or maybe they don't need identity
*caught* future
inline from project Valhalla). Are 2 wrappers that wrap the same instance
and come from
the same wrapper "class" different as per == or equal?

So, wrappers are just syntactic sugar.?
- No, but at their most degraded version yes. They can be so much more than
that, and here's how:

1. You can remove their state completely, making them truly lightweight.
Their state is the
state of their underlying instance. The class they wrap doesn't need
to have an appropriate
constructor, as they don't have a state of their own to initialize.
2. Now, to push things a little bit more, wrappers could wrap classes
that have package-private
abstract methods (outside the package). You would be able to override
only the protected/public
methods. Wrappers do not provide implementations, they just override
the already implemented
methods of their underlying instance, so there is a guarantee that the
wrapped instance will
have that package-private method overridden.

The meaning of wrappers is that: Any method that needs to be overridden
(and can be), should be
without any hassle and per instance. e.g. I have this instance and I want
to override 2 of its
methods and only for that instance.

Wrappers should be as close to their underlying wrapped instance as
possible. It's like having a
reference to that instance that magically has that method you want to
override, overridden.
Wrappers and their underlying instances shouldn't be visualized as
different objects.

Who can benefit from wrappers?
- Application authors: Yes, especially using them as spy wrappers, for
events.
- Library authors: Yes. Immutability will be easier to achieve and more
accessible.
- Compiler authors: Maybe?

What about other languages, do they have wrappers?
- Yes, Kotlin has them, under the term Delegation. Although, they are not
quite the same as here,
as they can have a state of their own.

From vicente.romero at oracle.com  Thu Jan 14 21:37:36 2021
From: vicente.romero at oracle.com (Vicente Romero)
Date: Thu, 14 Jan 2021 16:37:36 -0500
Subject: Records, Intersection type and lambda
In-Reply-To: <CAEgw74B_Dk_YYu_rc0POD2GdnA-0erqd2u-zK2oukg+Pgjd2uA@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>
 <df32ce1d-af2f-0a20-c3af-f56c17c2d203@oracle.com>
 <CAEgw74D3xVQmgOdfe4ByBgZNW9TKOGLJ84CY0QgXXuE3=xGbNg@mail.gmail.com>
 <CAEgw74B_Dk_YYu_rc0POD2GdnA-0erqd2u-zK2oukg+Pgjd2uA@mail.gmail.com>
Message-ID: <83250674-fa48-27c0-446e-d484bee83d89@oracle.com>

Hi Bernard,

On 1/6/21 8:02 AM, B. Blaser wrote:
> Hi Vicente,
>
> I saw you've integrated the initial fix with no additional change
> which seems reasonable.
>
> However, did you also try the example I provided below

no I didn't sorry, I think that we will have to file a follow-up issue
>   as I'm not
> absolutely sure this works?
> Otherwise, you may look at the experimental fix I suggested.
>
> Thanks,
> Bernard

Thanks,
Vicente

>
> On Sun, 27 Dec 2020 at 22:31, B. Blaser <bsrbnd at gmail.com> wrote:
>> 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 duke at openjdk.java.net  Thu Jan 14 22:05:36 2021
From: duke at openjdk.java.net (J.Duke)
Date: Thu, 14 Jan 2021 22:05:36 GMT
Subject: [concise-method-declarations] RFR: Merge master
Message-ID: <Tr8-9gb3wLzjGwdhVNQiTObV4DOO3SlRzQw4pCsEr_E=.f40d664f-de39-41ff-bd44-de7e1283ef51@github.com>

Hi all,

this is an _automatically_ generated pull request to notify you that there are 133 commits from the branch `master`that can **not** be merged into the branch `concise-method-declarations`:

The following file contains merge conflicts:

- src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties

All Committers in this [project](https://openjdk.java.net/census#amber) have access to my [personal fork](https://github.com/openjdk-bot/amber) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this).
The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request.
The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/amber](https://github.com/openjdk/amber) repository.

# Ensure target branch is up to date
$ git checkout concise-method-declarations
$ git pull https://github.com/openjdk/amber.git concise-method-declarations

# Fetch and checkout the branch for this pull request
$ git fetch https://github.com/openjdk-bot/amber.git +78:openjdk-bot-78
$ git checkout openjdk-bot-78

# Merge the target branch
$ git merge concise-method-declarations

When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit:

$ git add paths/to/files/with/conflicts
$ git commit -m 'Merge master'


When you have created the merge commit, run the following command to push the merge commit to this pull request:

$ git push https://github.com/openjdk-bot/amber.git openjdk-bot-78:78

_Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly.

Thanks,
J. Duke

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

Commit messages:
 - 8259350: Add some internal debugging APIs to the debug agent
 - 8259278: Optimize Vector API slice and unslice operations
 - 8255019: Shenandoah: Split STW and concurrent mark into separate classes
 - 8258956: Memory Leak in StringCoding on ThreadLocal resultCached StringCoding.Result
 - 8253866: Security Libs Terminology Refresh
 - 8259727: Remove redundant "target" arguments to methods in Links
 - 8259723: Move Table class to formats.html package
 - 8258912: Remove JVM options CountJNICalls and CountJVMCalls
 - 8226416: MonitorUsedDeflationThreshold can cause repeated async deflation requests
 - 8259699: Reduce char[] copying in URLEncoder.encode(String, Charset)
 - ... and 123 more: https://git.openjdk.java.net/amber/compare/555641ed...d18d26e8

The webrev contains the conflicts with concise-method-declarations:
 - merge conflicts: https://webrevs.openjdk.java.net/?repo=amber&pr=76&range=00.conflicts

Changes: https://git.openjdk.java.net/amber/pull/76/files
  Stats: 25230 lines in 738 files changed: 13772 ins; 7357 del; 4101 mod
  Patch: https://git.openjdk.java.net/amber/pull/76.diff
  Fetch: git fetch https://git.openjdk.java.net/amber pull/76/head:pull/76

PR: https://git.openjdk.java.net/amber/pull/76

From duke at openjdk.java.net  Thu Jan 14 22:09:43 2021
From: duke at openjdk.java.net (duke)
Date: Thu, 14 Jan 2021 22:09:43 GMT
Subject: git: openjdk/amber: stats-before-this-super: 134 new changesets
Message-ID: <b77994f0-ffc3-4906-b27c-bc7125698b42@openjdk.org>

Changeset: b996cccf
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2021-01-07 23:04:11 +0000
URL:       https://git.openjdk.java.net/amber/commit/b996cccf

8259373: c1 and jvmci runtime code use ResetNoHandleMark incorrectly

Reviewed-by: kvn

! src/hotspot/share/c1/c1_Runtime1.cpp
! src/hotspot/share/code/compiledMethod.cpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp

Changeset: 4a478b8a
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2021-01-07 12:21:59 +0000
URL:       https://git.openjdk.java.net/amber/commit/4a478b8a

8250903: jdk/jfr/javaagent/TestLoadedAgent.java fails with Mismatch in TestEvent count

Reviewed-by: mgronlun

! test/jdk/jdk/jfr/javaagent/EventEmitterAgent.java

Changeset: 484e23b9
Author:    Erik Joelsson <erikj at openjdk.org>
Date:      2021-01-07 14:57:30 +0000
URL:       https://git.openjdk.java.net/amber/commit/484e23b9

8258657: Doc build is broken by use of new language features

Reviewed-by: tbell, iris

! make/Docs.gmk
! make/autoconf/boot-jdk.m4
! make/autoconf/configure.ac
! make/autoconf/spec.gmk.in
! make/conf/jib-profiles.js

Changeset: c1fb5216
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2021-01-07 15:02:45 +0000
URL:       https://git.openjdk.java.net/amber/commit/c1fb5216

8259227: C2 crashes with SIGFPE due to a division that floats above its zero check

Reviewed-by: kvn, thartmann

! src/hotspot/share/opto/ifnode.cpp
! src/hotspot/share/opto/loopnode.hpp
! src/hotspot/share/opto/loopopts.cpp
! src/hotspot/share/opto/phaseX.cpp
! src/hotspot/share/opto/phaseX.hpp
+ test/hotspot/jtreg/compiler/loopopts/TestDivZeroDominatedBy.java
! test/hotspot/jtreg/compiler/loopopts/TestDivZeroWithSplitIf.java

Changeset: acdd90b6
Author:    Vicente Romero <vromero at openjdk.org>
Date:      2021-01-07 16:38:53 +0000
URL:       https://git.openjdk.java.net/amber/commit/acdd90b6

8258972: unexpected compilation error with generic sealed interface

Reviewed-by: jlahoda

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
! test/langtools/tools/javac/sealed/SealedCompilationTests.java

Changeset: 1973fbee
Author:    Rajan Halade <rhalade at openjdk.org>
Date:      2021-01-07 19:21:41 +0000
URL:       https://git.openjdk.java.net/amber/commit/1973fbee

8039278: console.sh failed Automatically with exit code 1

Backport-of: 4ce83f2a3a6c5fe11c298bed557c341e286e068a

! test/jdk/TEST.groups
- test/jdk/sun/security/tools/keytool/console.sh

Changeset: 677802d2
Author:    Christoph Langer <clanger at openjdk.org>
Date:      2021-01-07 22:51:49 +0000
URL:       https://git.openjdk.java.net/amber/commit/677802d2

8258484: AIX build fails in Harfbuzz with XLC 16.01.0000.0006

Backport-of: 3f9f86f0d3f918b9955ba6ba73c9c58ae8fcf7cb

! make/modules/java.desktop/lib/Awt2dLibraries.gmk

Changeset: 56a354eb
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
Date:      2021-01-07 23:51:21 +0000
URL:       https://git.openjdk.java.net/amber/commit/56a354eb

Merge

! make/Docs.gmk
! src/hotspot/share/opto/ifnode.cpp
! src/hotspot/share/opto/phaseX.cpp
! make/Docs.gmk
! src/hotspot/share/opto/ifnode.cpp
! src/hotspot/share/opto/phaseX.cpp

Changeset: 712014c5
Author:    David Holmes <dholmes at openjdk.org>
Date:      2021-01-08 04:11:22 +0000
URL:       https://git.openjdk.java.net/amber/commit/712014c5

8258077: Using -Xcheck:jni can lead to a double-free after JDK-8193234

Reviewed-by: dcubed, hseigel

! src/hotspot/share/prims/jniCheck.cpp
+ test/hotspot/jtreg/runtime/jni/checked/TestCheckedReleaseArrayElements.java
+ test/hotspot/jtreg/runtime/jni/checked/TestCheckedReleaseCriticalArray.java
+ test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseArrayElements.c
+ test/hotspot/jtreg/runtime/jni/checked/libTestCheckedReleaseCriticalArray.c

Changeset: fc1d2a1e
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2021-01-08 09:20:42 +0000
URL:       https://git.openjdk.java.net/amber/commit/fc1d2a1e

8259065: Optimize MessageDigest.getInstance

Reviewed-by: valeriep

! src/java.base/share/classes/java/security/MessageDigest.java
! src/java.base/share/classes/java/security/Provider.java
! src/java.base/share/classes/sun/security/jca/ProviderConfig.java
+ test/micro/org/openjdk/bench/java/security/GetMessageDigest.java

Changeset: b549cbd3
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2021-01-08 10:52:08 +0000
URL:       https://git.openjdk.java.net/amber/commit/b549cbd3

8258481: gc.g1.plab.TestPLABPromotion fails on Linux x86

Reviewed-by: sjohanss, kbarrett

! test/hotspot/jtreg/gc/g1/plab/TestPLABPromotion.java

Changeset: 697bf7ab
Author:    Guoxiong Li <lgxbslgx at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
Date:      2021-01-08 13:56:07 +0000
URL:       https://git.openjdk.java.net/amber/commit/697bf7ab

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

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/LambdaToMethod.java
+ test/langtools/tools/javac/T8257740/T8257740_1.java
+ test/langtools/tools/javac/T8257740/T8257740_2.java

Changeset: 6f7723b4
Author:    Eric Caspole <ecaspole at openjdk.org>
Date:      2021-01-08 14:18:21 +0000
URL:       https://git.openjdk.java.net/amber/commit/6f7723b4

8258792: LogCompilation: remove redundant check fixed by 8257518

Reviewed-by: kvn, redestad

! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/LogCompilation.java

Changeset: 10a6b0d9
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2021-01-08 14:25:12 +0000
URL:       https://git.openjdk.java.net/amber/commit/10a6b0d9

8234773: Fix ThreadsSMRSupport::_bootstrap_list

Make ThreadsList noncopyable, direct initializing _bootstrap_list. Avoid C-heap allocation for _bootstrap_list.

Reviewed-by: dholmes, dcubed

! src/hotspot/share/runtime/threadSMR.cpp
! src/hotspot/share/runtime/threadSMR.hpp

Changeset: 090bd3af
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2021-01-08 15:30:33 +0000
URL:       https://git.openjdk.java.net/amber/commit/090bd3af

8259397: ThreadsSMRSupport::print_info_on() should use try_lock_without_rank_check()

Reviewed-by: coleenp, dholmes

! src/hotspot/share/runtime/threadSMR.cpp

Changeset: 876c7fb5
Author:    Roger Riggs <rriggs at openjdk.org>
Date:      2021-01-08 21:31:37 +0000
URL:       https://git.openjdk.java.net/amber/commit/876c7fb5

8259493: [test] Use HexFormat instead of adhoc hex utilities in network code and locale SoftKeys

Reviewed-by: lancea, naoto

! test/jdk/java/net/Authenticator/B6870935.java
! test/jdk/java/net/HttpURLConnection/SetAuthenticator/HTTPTestServer.java
! test/jdk/java/net/httpclient/DigestEchoServer.java
! test/jdk/java/util/Locale/SoftKeys.java
! test/jdk/sun/net/www/protocol/http/DigestTest.java

Changeset: 628c546b
Author:    Roger Riggs <rriggs at openjdk.org>
Date:      2021-01-08 21:32:54 +0000
URL:       https://git.openjdk.java.net/amber/commit/628c546b

8258796: [test] Apply HexFormat to tests for java.security

Reviewed-by: xuelei

! test/jdk/com/sun/crypto/provider/Cipher/AEAD/SameBuffer.java
! test/jdk/com/sun/crypto/provider/Cipher/Blowfish/BlowfishTestVector.java
! test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/ChaCha20KAT.java
! test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/ChaCha20KeyGeneratorTest.java
! test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/ChaCha20NoReuse.java
! test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/ChaCha20Poly1305ParamTest.java
! test/jdk/com/sun/crypto/provider/Cipher/ChaCha20/unittest/ChaCha20CipherUnitTest.java
! test/jdk/com/sun/crypto/provider/KeyAgreement/DHKeyAgreement2.java
! test/jdk/com/sun/crypto/provider/KeyAgreement/DHKeyAgreement3.java
! test/jdk/com/sun/crypto/provider/KeyFactory/PBKDF2HmacSHA1FactoryTest.java
! test/jdk/com/sun/crypto/provider/TLS/TestLeadingZeroes.java
! test/jdk/java/security/KeyAgreement/KeySizeTest.java
! test/jdk/java/security/KeyAgreement/NegativeTest.java
! test/jdk/javax/crypto/SecretKeyFactory/SecKeyFacSunJCEPrf.java
! test/jdk/sun/security/ec/SignatureDigestTruncate.java
! test/jdk/sun/security/ec/SignatureKAT.java
! test/jdk/sun/security/ec/ed/EdDSAKeySize.java
! test/jdk/sun/security/ec/ed/EdDSANegativeTest.java
! test/jdk/sun/security/ec/ed/EdDSAParamSpec.java
! test/jdk/sun/security/ec/ed/EdDSATest.java
! test/jdk/sun/security/ec/ed/EdECKeyFormat.java
! test/jdk/sun/security/ec/ed/TestEdDSA.java
! test/jdk/sun/security/ec/ed/TestEdOps.java
! test/jdk/sun/security/ec/xec/TestXDH.java
! test/jdk/sun/security/ec/xec/TestXECOps.java
! test/jdk/sun/security/ec/xec/XECIterative.java
! test/jdk/sun/security/ec/xec/XECKeyFormat.java
! test/jdk/sun/security/krb5/RFC396xTest.java
! test/jdk/sun/security/krb5/auto/ReplayCacheTestProc.java
! test/jdk/sun/security/krb5/etype/KerberosAesSha2.java
! test/jdk/sun/security/lib/cacerts/VerifyCACerts.java
! test/jdk/sun/security/pkcs/pkcs8/PKCS8Test.java
! test/jdk/sun/security/pkcs11/tls/TestLeadingZeroesP11.java
! test/jdk/sun/security/provider/DSA/TestDSA.java
! test/jdk/sun/security/provider/MessageDigest/DigestKAT.java
! test/jdk/sun/security/rsa/SigRecord.java
! test/jdk/sun/security/rsa/TestSigGen15.java
! test/jdk/sun/security/rsa/pss/SigRecord.java
! test/jdk/sun/security/rsa/pss/TestSigGenPSS.java
! test/jdk/sun/security/util/math/TestIntegerModuloP.java
! test/jdk/sun/security/x509/X500Name/DerValueConstructor.java
! test/lib/jdk/test/lib/Convert.java
! test/lib/jdk/test/lib/Utils.java

Changeset: 7e6677b5
Author:    David Holmes <dholmes at openjdk.org>
Date:      2021-01-08 22:25:21 +0000
URL:       https://git.openjdk.java.net/amber/commit/7e6677b5

8259446: runtime/jni/checked/TestCheckedReleaseArrayElements.java fails with stderr not empty

Reviewed-by: dcubed

! test/hotspot/jtreg/runtime/jni/checked/TestCheckedReleaseArrayElements.java

Changeset: a6539282
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2021-01-09 00:03:32 +0000
URL:       https://git.openjdk.java.net/amber/commit/a6539282

8259512: Update --release 16 symbol information for JDK 16 build 31

Reviewed-by: jjg

! make/data/symbols/jdk.incubator.vector-G.sym.txt

Changeset: 6472104e
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2021-01-09 07:22:20 +0000
URL:       https://git.openjdk.java.net/amber/commit/6472104e

6278172: TextComponent.getSelectedText() throws StringIndexOutOfBoundsException

Reviewed-by: aivanov

! src/java.desktop/share/classes/java/awt/TextComponent.java
+ test/jdk/java/awt/TextComponent/SetTextSelection.java

Changeset: 5cfa8c94
Author:    Martin Buchholz <martin at openjdk.org>
Date:      2021-01-09 20:57:52 +0000
URL:       https://git.openjdk.java.net/amber/commit/5cfa8c94

8246585: ForkJoin updates
8229253: forkjoin/FJExceptionTableLeak.java fails "AssertionError: failed to satisfy condition"

Reviewed-by: dl

! src/java.base/share/classes/java/util/concurrent/CountedCompleter.java
! src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java
! src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java
! src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java
+ test/jdk/java/util/concurrent/forkjoin/AsyncShutdownNow.java
+ test/jdk/java/util/concurrent/forkjoin/AsyncShutdownNowInvokeAny.java
+ test/jdk/java/util/concurrent/forkjoin/AsyncShutdownNowInvokeAnyRace.java
- test/jdk/java/util/concurrent/forkjoin/FJExceptionTableLeak.java
! test/jdk/java/util/concurrent/tck/ForkJoinTaskTest.java

Changeset: 63e3bd76
Author:    Martin Buchholz <martin at openjdk.org>
Date:      2021-01-09 21:08:32 +0000
URL:       https://git.openjdk.java.net/amber/commit/63e3bd76

8246677: LinkedTransferQueue and SynchronousQueue synchronization updates

Reviewed-by: alanb, dl

! src/java.base/share/classes/java/util/concurrent/LinkedTransferQueue.java
! src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java
! test/jdk/java/util/concurrent/LinkedTransferQueue/WhiteBox.java

Changeset: 270014ab
Author:    Martin Buchholz <martin at openjdk.org>
Date:      2021-01-09 21:59:27 +0000
URL:       https://git.openjdk.java.net/amber/commit/270014ab

8234131: Miscellaneous changes imported from jsr166 CVS 2021-01
8257671: ThreadPoolExecutor.Discard*Policy: rejected tasks are not cancelled

Reviewed-by: alanb, prappo, dl

! src/java.base/share/classes/java/util/concurrent/AbstractExecutorService.java
! src/java.base/share/classes/java/util/concurrent/CopyOnWriteArraySet.java
! src/java.base/share/classes/java/util/concurrent/CountDownLatch.java
! src/java.base/share/classes/java/util/concurrent/CyclicBarrier.java
! src/java.base/share/classes/java/util/concurrent/Exchanger.java
! src/java.base/share/classes/java/util/concurrent/ExecutorService.java
! src/java.base/share/classes/java/util/concurrent/Future.java
! src/java.base/share/classes/java/util/concurrent/Phaser.java
! src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java
! src/java.base/share/classes/java/util/concurrent/Semaphore.java
! src/java.base/share/classes/java/util/concurrent/SubmissionPublisher.java
! src/java.base/share/classes/java/util/concurrent/ThreadPoolExecutor.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicBoolean.java
! src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceFieldUpdater.java
! src/java.base/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java
! src/java.base/share/classes/java/util/concurrent/atomic/DoubleAdder.java
! src/java.base/share/classes/java/util/concurrent/atomic/LongAccumulator.java
! src/java.base/share/classes/java/util/concurrent/atomic/LongAdder.java
! src/java.base/share/classes/java/util/concurrent/atomic/Striped64.java
! src/java.base/share/classes/java/util/concurrent/atomic/package-info.java
! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java
! src/java.base/share/classes/java/util/concurrent/locks/ReentrantLock.java
! src/java.base/share/classes/java/util/concurrent/locks/ReentrantReadWriteLock.java
! src/java.base/share/classes/java/util/concurrent/locks/StampedLock.java
! test/jdk/java/util/Collection/IteratorMicroBenchmark.java
! test/jdk/java/util/concurrent/ExecutorService/Invoke.java
! test/jdk/java/util/concurrent/tck/ArrayBlockingQueueTest.java
! test/jdk/java/util/concurrent/tck/ArrayDequeTest.java
! test/jdk/java/util/concurrent/tck/ArrayListTest.java
! test/jdk/java/util/concurrent/tck/Collection8Test.java
! test/jdk/java/util/concurrent/tck/CompletableFutureTest.java
! test/jdk/java/util/concurrent/tck/ConcurrentLinkedDequeTest.java
! test/jdk/java/util/concurrent/tck/ExecutorsTest.java
! test/jdk/java/util/concurrent/tck/ForkJoinPoolTest.java
! test/jdk/java/util/concurrent/tck/JSR166TestCase.java
! test/jdk/java/util/concurrent/tck/RecursiveTaskTest.java
! test/jdk/java/util/concurrent/tck/SplittableRandomTest.java
! test/jdk/java/util/concurrent/tck/StampedLockTest.java
! test/jdk/java/util/concurrent/tck/SubmissionPublisherTest.java
! test/jdk/java/util/concurrent/tck/SynchronousQueueTest.java
! test/jdk/java/util/concurrent/tck/ThreadLocalRandomTest.java

Changeset: 81db63e8
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
Date:      2021-01-10 04:36:12 +0000
URL:       https://git.openjdk.java.net/amber/commit/81db63e8

8259517: Incorrect test path in test cases

Reviewed-by: weijun

! test/jdk/javax/net/ssl/SSLEngine/ArgCheck.java
! test/jdk/javax/net/ssl/SSLEngine/Basics.java
! test/jdk/javax/net/ssl/templates/SSLSocketTemplate.java

Changeset: 65ca5c66
Author:    Tejpal Rebari <trebari at openjdk.org>
Date:      2021-01-10 12:38:10 +0000
URL:       https://git.openjdk.java.net/amber/commit/65ca5c66

8048109: JToggleButton does not fire actionPerformed under certain conditions

Reviewed-by: serb, psadhukhan, vdyakov

! src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java
! src/java.desktop/share/classes/com/sun/java/swing/plaf/motif/MotifLookAndFeel.java
! src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java
+ test/jdk/javax/swing/JPopupMenu/SetInvokerJPopupMenuTest.java

Changeset: 11d5b047
Author:    Martin Buchholz <martin at openjdk.org>
Date:      2021-01-10 18:20:16 +0000
URL:       https://git.openjdk.java.net/amber/commit/11d5b047

8258217: PriorityBlockingQueue constructor spec and behavior mismatch

Reviewed-by: dl

! src/java.base/share/classes/java/util/concurrent/PriorityBlockingQueue.java

Changeset: e7c17408
Author:    Martin Buchholz <martin at openjdk.org>
Date:      2021-01-10 18:38:00 +0000
URL:       https://git.openjdk.java.net/amber/commit/e7c17408

8258187: IllegalMonitorStateException in ArrayBlockingQueue

Reviewed-by: dl

! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java
! src/java.base/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java

Changeset: 9154f643
Author:    Martin Buchholz <martin at openjdk.org>
Date:      2021-01-10 23:47:04 +0000
URL:       https://git.openjdk.java.net/amber/commit/9154f643

8254973: CompletableFuture.ThreadPerTaskExecutor does not throw NPE in #execute

Reviewed-by: dl

! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java

Changeset: b72de3c5
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
Date:      2021-01-11 00:33:22 +0000
URL:       https://git.openjdk.java.net/amber/commit/b72de3c5

8259385: Cleanup unused assignment

Reviewed-by: attila

! src/java.base/share/classes/sun/security/ssl/CertStatusExtension.java
! src/java.base/share/classes/sun/security/ssl/CertificateStatus.java
! src/java.base/share/classes/sun/security/ssl/CertificateVerify.java
! src/java.base/share/classes/sun/security/ssl/DHServerKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/DTLSInputRecord.java
! src/java.base/share/classes/sun/security/ssl/ECDHClientKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/ECDHServerKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/Finished.java
! src/java.base/share/classes/sun/security/ssl/OutputRecord.java
! src/java.base/share/classes/sun/security/ssl/RSAKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/RSAServerKeyExchange.java
! src/java.base/share/classes/sun/security/ssl/SSLCipher.java
! src/java.base/share/classes/sun/security/ssl/SSLContextImpl.java
! src/java.base/share/classes/sun/security/ssl/SSLEngineInputRecord.java
! src/java.base/share/classes/sun/security/ssl/SSLSessionImpl.java
! src/java.base/share/classes/sun/security/ssl/SSLSocketInputRecord.java
! src/java.base/share/classes/sun/security/ssl/SSLTransport.java
! src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java

Changeset: 2806bf2e
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-11 07:32:27 +0000
URL:       https://git.openjdk.java.net/amber/commit/2806bf2e

8259475: Fix bad merge in compilerOracle

Reviewed-by: redestad, thartmann

! src/hotspot/share/compiler/compilerOracle.cpp
! src/hotspot/share/compiler/compilerOracle.hpp

Changeset: bb247b02
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-11 07:32:57 +0000
URL:       https://git.openjdk.java.net/amber/commit/bb247b02

8259392: Zero error reporting is broken after JDK-8255711

Reviewed-by: dholmes

! src/hotspot/os/posix/signals_posix.cpp

Changeset: 3974fd4f
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-11 07:33:33 +0000
URL:       https://git.openjdk.java.net/amber/commit/3974fd4f

8259451: Zero: skip serviceability/sa tests, set vm.hasSA to false

Reviewed-by: sgehwolf, cjplummer

! test/lib/jdk/test/lib/Platform.java

Changeset: d21a0ea1
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2021-01-11 07:37:37 +0000
URL:       https://git.openjdk.java.net/amber/commit/d21a0ea1

8258449: Move make/hotspot/symbols to make/data

Reviewed-by: erikj

= make/data/hotspot-symbols/symbols-aix
= make/data/hotspot-symbols/symbols-aix-debug
= make/data/hotspot-symbols/symbols-linux
= make/data/hotspot-symbols/symbols-macosx
= make/data/hotspot-symbols/symbols-shared
= make/data/hotspot-symbols/symbols-unix
! make/hotspot/lib/JvmMapfile.gmk

Changeset: bd344184
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2021-01-11 07:42:10 +0000
URL:       https://git.openjdk.java.net/amber/commit/bd344184

8258445: Move make/templates to make/data

Reviewed-by: erikj

= make/data/license-templates/bsd-header
= make/data/license-templates/gpl-cp-header
= make/data/license-templates/gpl-header
! make/scripts/lic_check.sh

Changeset: e0d748d5
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2021-01-11 09:06:40 +0000
URL:       https://git.openjdk.java.net/amber/commit/e0d748d5

8258606: os::print_signal_handlers() should resolve the function name of the handlers

Reviewed-by: dholmes, coleenp, gziemski

! src/hotspot/os/posix/signals_posix.cpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/os.hpp
! test/hotspot/gtest/runtime/test_os.cpp

Changeset: a03e22bb
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-11 09:42:48 +0000
URL:       https://git.openjdk.java.net/amber/commit/a03e22bb

8253910: UseCompressedClassPointers depends on UseCompressedOops in vmError.cpp

Reviewed-by: rrich, dholmes

! src/hotspot/share/utilities/vmError.cpp

Changeset: 18a37f94
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-11 09:43:18 +0000
URL:       https://git.openjdk.java.net/amber/commit/18a37f94

8259368: Zero: UseCompressedClassPointers does not depend on UseCompressedOops

Reviewed-by: aph, zgu

! src/hotspot/cpu/zero/globalDefinitions_zero.hpp

Changeset: 23548821
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2021-01-11 10:10:47 +0000
URL:       https://git.openjdk.java.net/amber/commit/23548821

8250768: javac should be adapted to changes in JEP 12

Reviewed-by: mcimadamore, erikj, jjg, ihse

! make/CompileInterimLangtools.gmk
! make/Docs.gmk
! make/autoconf/spec.gmk.in
- make/jdk/src/classes/build/tools/taglet/Preview.java
! make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java
! make/modules/jdk.compiler/Gendata.gmk
! make/modules/jdk.javadoc/Gendata.gmk
! src/java.base/share/classes/java/lang/Class.java
= src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
! src/java.base/share/classes/module-info.java
! src/java.compiler/share/classes/javax/lang/model/element/Modifier.java
! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java
! src/jdk.compiler/share/classes/com/sun/source/tree/ClassTree.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskPool.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symtab.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Annotate.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Modules.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TypeEnter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassWriter.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/MandatoryWarningHandler.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/Names.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/EnumConstantWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkFactoryImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkInfoImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NestedClassWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PreviewListWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SubWriterHolderWriter.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/TagName.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AnnotationTypeRequiredMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/ConstructorWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/EnumConstantWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/FieldWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/MethodWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/PropertyWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/WorkArounds.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ConstructorBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/EnumConstantBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/FieldBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/MethodBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/PropertyBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/stylesheet.css
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Comparators.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DeprecatedAPIListBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocLink.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/SummaryAPIListBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/links/LinkFactory.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/links/LinkInfo.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java
! src/jdk.jshell/share/classes/jdk/jshell/Snippet.java
! test/jdk/java/lang/invoke/defineHiddenClass/PreviewHiddenClass.java
! test/jdk/java/lang/ref/CleanerTest.java
! test/jdk/java/util/Arrays/TimSortStackSize2.java
! test/jdk/jdk/modules/etc/JdkQualifiedExportTest.java
! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java
! test/langtools/jdk/javadoc/doclet/testHtmlTableTags/TestHtmlTableTags.java
! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java
+ test/langtools/jdk/javadoc/doclet/testPreview/TestPreview.java
+ test/langtools/jdk/javadoc/doclet/testPreview/api/preview/Core.java
+ test/langtools/jdk/javadoc/doclet/testPreview/api/preview/CoreRecord.java
+ test/langtools/jdk/javadoc/doclet/testPreview/api/preview/CoreRecordComponent.java
+ test/langtools/jdk/javadoc/doclet/testPreview/api/preview/Reflective.java
+ test/langtools/jdk/javadoc/doclet/testPreview/doc/element-list
= test/langtools/jdk/javadoc/doclet/testPreview/doc/java.base/preview/Core.html
= test/langtools/jdk/javadoc/doclet/testPreview/doc/java.base/preview/Reflective.html
+ test/langtools/jdk/javadoc/doclet/testPreview/m/module-info.java
+ test/langtools/jdk/javadoc/doclet/testPreview/m/pkg/DocAnnotation.java
+ test/langtools/jdk/javadoc/doclet/testPreview/m/pkg/DocAnnotationUse1.java
+ test/langtools/jdk/javadoc/doclet/testPreview/m/pkg/DocAnnotationUse2.java
+ test/langtools/jdk/javadoc/doclet/testPreview/m/pkg/TestPreviewAPIUse.java
+ test/langtools/jdk/javadoc/doclet/testPreview/m/pkg/TestPreviewDeclaration.java
+ test/langtools/jdk/javadoc/doclet/testPreview/m/pkg/TestPreviewDeclarationUse.java
! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java
! test/langtools/jdk/javadoc/doclet/testSealedTypes/TestSealedTypes.java
! test/langtools/jdk/javadoc/doclet/testStylesheet/TestStylesheet.java
! test/langtools/jdk/javadoc/tool/CheckResourceKeys.java
! test/langtools/tools/javac/diags/examples.not-yet.txt
! test/langtools/tools/javac/diags/examples/CantExtendSealedInAnotherModule/CantExtendSealedInAnotherModule.java
! test/langtools/tools/javac/diags/examples/CantExtendSealedInAnotherPkg/CantExtendSealedInAnotherPkg.java
! test/langtools/tools/javac/diags/examples/SealedTypes.java
+ test/langtools/tools/javac/enum/FauxEnum3-preview.out
! test/langtools/tools/javac/lib/combo/ComboTask.java
! test/langtools/tools/javac/options/BCPOrSystemNotSpecified.java
! test/langtools/tools/javac/patterns/BreakAndLoops.java
! test/langtools/tools/javac/patterns/ConditionalTest.java
! test/langtools/tools/javac/patterns/PatternMatchPosTest.out
! test/langtools/tools/javac/platform/PreviewAPIsWithRelease.out
+ test/langtools/tools/javac/preview/DeclaredUsingPreview-class.out
+ test/langtools/tools/javac/preview/DeclaredUsingPreview-source.out
+ test/langtools/tools/javac/preview/DeclaredUsingPreview.java
+ test/langtools/tools/javac/preview/DeclaredUsingPreviewDeclarations.java
+ test/langtools/tools/javac/preview/PreviewAutoSuppress.java
! test/langtools/tools/javac/preview/PreviewErrors.java
! test/langtools/tools/javac/processing/model/element/TestSealed.java
! test/langtools/tools/javac/sealed/SealedDiffConfigurationsTest.java
! test/langtools/tools/jdeps/listdeps/ListModuleDeps.java

Changeset: 1bd015fb
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2021-01-11 11:28:29 +0000
URL:       https://git.openjdk.java.net/amber/commit/1bd015fb

8258407: Split up CompileJavaModules.gmk into make/modules/$M/Java.gmk

Reviewed-by: erikj

! make/CompileJavaModules.gmk
+ make/modules/java.base/Java.gmk
+ make/modules/java.compiler/Java.gmk
+ make/modules/java.datatransfer/Java.gmk
+ make/modules/java.desktop/Java.gmk
+ make/modules/java.instrument/Java.gmk
+ make/modules/java.logging/Java.gmk
+ make/modules/java.management.rmi/Java.gmk
+ make/modules/java.management/Java.gmk
+ make/modules/java.naming/Java.gmk
+ make/modules/java.prefs/Java.gmk
+ make/modules/java.rmi/Java.gmk
+ make/modules/java.scripting/Java.gmk
+ make/modules/java.security.jgss/Java.gmk
+ make/modules/java.smartcardio/Java.gmk
+ make/modules/java.sql.rowset/Java.gmk
+ make/modules/java.sql/Java.gmk
+ make/modules/java.transaction.xa/Java.gmk
+ make/modules/java.xml.crypto/Java.gmk
+ make/modules/java.xml/Java.gmk
+ make/modules/jdk.aot/Java.gmk
+ make/modules/jdk.charsets/Java.gmk
+ make/modules/jdk.compiler/Java.gmk
+ make/modules/jdk.dev/Java.gmk
+ make/modules/jdk.dynalink/Java.gmk
+ make/modules/jdk.editpad/Java.gmk
+ make/modules/jdk.hotspot.agent/Java.gmk
+ make/modules/jdk.httpserver/Java.gmk
+ make/modules/jdk.incubator.vector/Java.gmk
+ make/modules/jdk.internal.jvmstat/Java.gmk
+ make/modules/jdk.internal.le/Java.gmk
+ make/modules/jdk.internal.opt/Java.gmk
+ make/modules/jdk.internal.vm.ci/Java.gmk
+ make/modules/jdk.internal.vm.compiler/Java.gmk
+ make/modules/jdk.jartool/Java.gmk
+ make/modules/jdk.javadoc/Java.gmk
+ make/modules/jdk.jcmd/Java.gmk
+ make/modules/jdk.jconsole/Java.gmk
+ make/modules/jdk.jdeps/Java.gmk
+ make/modules/jdk.jdi/Java.gmk
+ make/modules/jdk.jfr/Java.gmk
+ make/modules/jdk.jpackage/Java.gmk
+ make/modules/jdk.jshell/Java.gmk
+ make/modules/jdk.localedata/Java.gmk
+ make/modules/jdk.sctp/Java.gmk
+ make/modules/jdk.unsupported.desktop/Java.gmk
+ make/modules/sun.charsets/Java.gmk

Changeset: 01b2804e
Author:    Clive Verghese <cverghese at openjdk.org>
Committer: Volker Simonis <simonis at openjdk.org>
Date:      2021-01-11 12:02:09 +0000
URL:       https://git.openjdk.java.net/amber/commit/01b2804e

8237578: JDK-8214339 (SSLSocketImpl wraps SocketException) appears to not be fully fixed

Reviewed-by: xuelei, simonis

! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java
! src/java.base/share/classes/sun/security/ssl/SSLTransport.java
! test/jdk/sun/security/ssl/SSLContextImpl/TrustTrustedCert.java
+ test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketShouldThrowSocketException.java
= test/jdk/sun/security/ssl/SSLSocketImpl/SocketExceptionForSocketIssues.java

Changeset: 23801da9
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2021-01-11 12:27:30 +0000
URL:       https://git.openjdk.java.net/amber/commit/23801da9

8259482: jni_Set/GetField_probe are the same as their _nh versions

Reviewed-by: hseigel, sspitsyn, dholmes

! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvmtiExport.cpp
! src/hotspot/share/prims/jvmtiExport.hpp

Changeset: 33fbc10c
Author:    Guoxiong Li <lgxbslgx at gmail.com>
Committer: Attila Szegedi <attila at openjdk.org>
Date:      2021-01-11 13:50:53 +0000
URL:       https://git.openjdk.java.net/amber/commit/33fbc10c

8259025: Record compact constructor using Objects.requireNonNull

Reviewed-by: attila

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! test/langtools/tools/javac/records/RecordCompilationTests.java

Changeset: cf3e4bfd
Author:    Harold Seigel <hseigel at openjdk.org>
Date:      2021-01-11 18:18:13 +0000
URL:       https://git.openjdk.java.net/amber/commit/cf3e4bfd

8258838: Remove JVM option UseStackBanging

Reviewed-by: dholmes, coleenp, kvn

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp
! src/hotspot/cpu/arm/macroAssembler_arm.cpp
! src/hotspot/cpu/arm/sharedRuntime_arm.cpp
! src/hotspot/cpu/ppc/ppc.ad
! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
! src/hotspot/cpu/s390/s390.ad
! src/hotspot/cpu/s390/templateInterpreterGenerator_s390.cpp
! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
! src/hotspot/share/asm/assembler.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
! src/hotspot/share/opto/output.cpp
! src/hotspot/share/runtime/globals.hpp
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/GraalHotSpotVMConfig.java

Changeset: dab17875
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2021-01-11 18:18:46 +0000
URL:       https://git.openjdk.java.net/amber/commit/dab17875

8259559: COMPARE_BUILD can't compare patch files

Reviewed-by: erikj

! make/Init.gmk

Changeset: 38619602
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2021-01-11 18:22:58 +0000
URL:       https://git.openjdk.java.net/amber/commit/38619602

8258426: Split up autoconf/version-numbers and move it to conf dir

Reviewed-by: erikj

! .github/workflows/submit.yml
! make/autoconf/jdk-options.m4
! make/autoconf/jdk-version.m4
! make/autoconf/spec.gmk.in
- make/autoconf/version-numbers
+ make/conf/branding.conf
! make/conf/jib-profiles.js
+ make/conf/version-numbers.conf

Changeset: c956e7a6
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2021-01-11 18:46:52 +0000
URL:       https://git.openjdk.java.net/amber/commit/c956e7a6

8258659: Eliminate whitespace comments from generated pages

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java
! test/langtools/jdk/javadoc/doclet/AccessSkipNav/AccessSkipNav.java
! test/langtools/jdk/javadoc/doclet/testAnnotationTypes/TestAnnotationTypes.java
! test/langtools/jdk/javadoc/doclet/testNavigation/TestNavigation.java

Changeset: d9f21346
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2021-01-11 18:49:50 +0000
URL:       https://git.openjdk.java.net/amber/commit/d9f21346

8258655: remove <-- NewPage --> comment from generated pages

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexRedirectWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlDocument.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties

Changeset: 8dfc77bf
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2021-01-11 19:44:26 +0000
URL:       https://git.openjdk.java.net/amber/commit/8dfc77bf

8259586: ProblemList dll_address_to_function_and_library_name

Reviewed-by: hseigel

! test/hotspot/gtest/runtime/test_os.cpp

Changeset: e9929e2b
Author:    Volker Simonis <simonis at openjdk.org>
Date:      2021-01-11 21:36:16 +0000
URL:       https://git.openjdk.java.net/amber/commit/e9929e2b

8259582: Backout JDK-8237578 until all affected tests have been fixed

Reviewed-by: xuelei

! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java
! src/java.base/share/classes/sun/security/ssl/SSLTransport.java
! test/jdk/sun/security/ssl/SSLContextImpl/TrustTrustedCert.java
= test/jdk/sun/security/ssl/SSLSocketImpl/SSLExceptionForIOIssue.java
- test/jdk/sun/security/ssl/SSLSocketImpl/SSLSocketShouldThrowSocketException.java

Changeset: cd73939b
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2021-01-11 22:02:46 +0000
URL:       https://git.openjdk.java.net/amber/commit/cd73939b

8259528: Broken Link for [java.text.Normalizer.Form]

Reviewed-by: lancea, joehw, iris

! src/java.base/share/classes/java/text/Normalizer.java

Changeset: 712ea250
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2021-01-11 23:13:52 +0000
URL:       https://git.openjdk.java.net/amber/commit/712ea250

8258925: configure script failed on WSL

Reviewed-by: dholmes, erikj

! make/scripts/fixpath.sh

Changeset: ff54b77b
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2021-01-11 23:14:56 +0000
URL:       https://git.openjdk.java.net/amber/commit/ff54b77b

8259439: Apply java.io.Serial annotations in java.datatransfer

Reviewed-by: aivanov, pbansal, trebari, darcy

! src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java
! src/java.datatransfer/share/classes/java/awt/datatransfer/FlavorEvent.java
! src/java.datatransfer/share/classes/java/awt/datatransfer/MimeType.java
! src/java.datatransfer/share/classes/java/awt/datatransfer/MimeTypeParseException.java
! src/java.datatransfer/share/classes/java/awt/datatransfer/UnsupportedFlavorException.java

Changeset: 022bc9f0
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Aleksei Efimov <aefimov at openjdk.org>
Date:      2021-01-11 23:30:44 +0000
URL:       https://git.openjdk.java.net/amber/commit/022bc9f0

8258422: Cleanup unnecessary null comparison before instanceof check in java.base

Reviewed-by: chegar, aefimov

! src/java.base/share/classes/java/io/File.java
! src/java.base/share/classes/java/lang/reflect/Constructor.java
! src/java.base/share/classes/java/lang/reflect/Field.java
! src/java.base/share/classes/java/lang/reflect/Method.java
! src/java.base/share/classes/java/net/AbstractPlainDatagramSocketImpl.java
! src/java.base/share/classes/java/net/AbstractPlainSocketImpl.java
! src/java.base/share/classes/java/net/DatagramPacket.java
! src/java.base/share/classes/java/net/HttpConnectSocketImpl.java
! src/java.base/share/classes/java/net/Inet4Address.java
! src/java.base/share/classes/java/net/Inet6Address.java
! src/java.base/share/classes/java/net/InetSocketAddress.java
! src/java.base/share/classes/java/net/NetMulticastSocket.java
! src/java.base/share/classes/java/net/Proxy.java
! src/java.base/share/classes/java/net/SocksSocketImpl.java
! src/java.base/share/classes/java/nio/file/attribute/AclEntry.java
! src/java.base/share/classes/jdk/internal/misc/Signal.java
! src/java.base/share/classes/sun/net/www/protocol/http/Negotiator.java
! src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java
! src/java.base/share/classes/sun/nio/ch/DatagramSocketAdaptor.java
! src/java.base/share/classes/sun/nio/fs/PollingWatchService.java
! src/java.base/unix/classes/sun/nio/fs/UnixPath.java
! src/java.base/windows/classes/sun/nio/fs/WindowsPath.java

Changeset: b6d51e15
Author:    Alexander Zuev <kizune at openjdk.org>
Date:      2021-01-12 00:28:22 +0000
URL:       https://git.openjdk.java.net/amber/commit/b6d51e15

8259585: Accessible actions do not work on mac os x

Reviewed-by: serb

! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaAccessibilityAction.m

Changeset: fb68395d
Author:    Michael McMahon <michaelm at openjdk.org>
Date:      2021-01-08 15:59:45 +0000
URL:       https://git.openjdk.java.net/amber/commit/fb68395d

8259014: (so) ServerSocketChannel.bind(UnixDomainSocketAddress)/SocketChannel.bind(UnixDomainSocketAddress) will have unknown user and group owner (win)

Reviewed-by: alanb

! src/java.base/windows/native/libnio/ch/UnixDomainSockets.c

Changeset: 020ec848
Author:    Erik Joelsson <erikj at openjdk.org>
Date:      2021-01-08 18:30:38 +0000
URL:       https://git.openjdk.java.net/amber/commit/020ec848

8259429: Update reference to README.md

Reviewed-by: iris

! make/conf/jib-profiles.js

Changeset: e05f36f4
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-11 13:45:35 +0000
URL:       https://git.openjdk.java.net/amber/commit/e05f36f4

8259043: More Zero architectures need linkage with libatomic

Co-authored-by: Matthias Klose <doko at openjdk.org>
Reviewed-by: erikj

! make/autoconf/libraries.m4

Changeset: d60a937e
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2021-01-11 16:14:56 +0000
URL:       https://git.openjdk.java.net/amber/commit/d60a937e

8259028: ClassCastException when using custom filesystem with wrapper FileChannel impl

Reviewed-by: chegar, alanb, uschindler

! src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemorySegment.java
! src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/MappedMemorySegmentImpl.java
! test/jdk/java/foreign/TestByteBuffer.java

Changeset: 2cb271e6
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2021-01-11 17:35:50 +0000
URL:       https://git.openjdk.java.net/amber/commit/2cb271e6

8253996: Javac error on jdk16 build 18: invalid flag: -Xdoclint:-missing

Reviewed-by: hannesw

! src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/api/BasicJavacTask.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlOptions.java
! test/langtools/tools/javac/diags/examples.not-yet.txt
+ test/langtools/tools/javac/doclint/LimitedImage.java

Changeset: b378f54d
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
Date:      2021-01-12 01:08:14 +0000
URL:       https://git.openjdk.java.net/amber/commit/b378f54d

Merge

! make/conf/jib-profiles.js
! src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/langtools/tools/javac/diags/examples.not-yet.txt
! make/conf/jib-profiles.js
! src/jdk.compiler/share/classes/com/sun/tools/doclint/DocLint.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/langtools/tools/javac/diags/examples.not-yet.txt

Changeset: ae0532ed
Author:    Wang Huang <whuang at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2021-01-12 01:40:08 +0000
URL:       https://git.openjdk.java.net/amber/commit/ae0532ed

8259044: JVM lacks data type qualifier when using -XX:+PrintAssembly with AArch64-Neon backend

Co-authored-by: He Xuejin <hexuejin2 at huawei.com>
Reviewed-by: njian, aph

! src/hotspot/cpu/aarch64/aarch64_neon.ad
! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4

Changeset: 2255ab76
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2021-01-12 03:38:54 +0000
URL:       https://git.openjdk.java.net/amber/commit/2255ab76

8258810: Improve enum traits

Reviewed-by: ayang, iklam, lfoltan

! src/hotspot/share/utilities/enumIterator.hpp
! test/hotspot/gtest/utilities/test_enumIterator.cpp

Changeset: 77f62909
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2021-01-12 04:12:31 +0000
URL:       https://git.openjdk.java.net/amber/commit/77f62909

8258254: Move PtrQueue flush to PtrQueueSet subclasses

Reviewed-by: tschatzl, shade

! src/hotspot/share/gc/g1/g1BarrierSet.cpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp
! src/hotspot/share/gc/g1/g1EvacFailure.cpp
! src/hotspot/share/gc/g1/g1ParScanThreadState.cpp
! src/hotspot/share/gc/g1/g1RedirtyCardsQueue.cpp
! src/hotspot/share/gc/g1/g1RedirtyCardsQueue.hpp
! src/hotspot/share/gc/shared/ptrQueue.cpp
! src/hotspot/share/gc/shared/ptrQueue.hpp
! src/hotspot/share/gc/shared/satbMarkQueue.cpp
! src/hotspot/share/gc/shared/satbMarkQueue.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp

Changeset: 61c5b95b
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2021-01-12 06:53:17 +0000
URL:       https://git.openjdk.java.net/amber/commit/61c5b95b

7194219: java/awt/Component/UpdatingBootTime/UpdatingBootTime.html fails on Linux

Reviewed-by: aivanov

! src/java.desktop/unix/classes/sun/awt/X11/XToolkit.java
! src/java.desktop/unix/classes/sun/awt/X11/XWindow.java
! test/jdk/ProblemList.txt
! test/jdk/java/awt/Component/UpdatingBootTime/UpdatingBootTime.html
! test/jdk/java/awt/Component/UpdatingBootTime/UpdatingBootTime.java

Changeset: 98ccfbf4
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2021-01-12 06:56:49 +0000
URL:       https://git.openjdk.java.net/amber/commit/98ccfbf4

8255710: Opensource unit/regression tests for CMM

Reviewed-by: pbansal, prr

+ test/jdk/java/awt/color/GetInstanceNullData.java
+ test/jdk/java/awt/color/GetNameExceptionTest.java
+ test/jdk/java/awt/color/GetNameTest.java
+ test/jdk/java/awt/color/ICC_ProfileSetNullDataTest.java
+ test/jdk/java/awt/color/MultiThreadCMMTest.java
+ test/jdk/java/awt/color/StandardProfileTest.java
+ test/jdk/java/awt/color/StandardProfileTest.policy
+ test/jdk/java/awt/color/XYZTest.java

Changeset: 9d4e84fd
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-12 07:49:21 +0000
URL:       https://git.openjdk.java.net/amber/commit/9d4e84fd

8259565: Zero: compiler/runtime/criticalnatives fails because CriticalJNINatives is not supported

Reviewed-by: coleenp, zgu

! src/hotspot/cpu/zero/vm_version_zero.cpp
! test/hotspot/jtreg/compiler/runtime/criticalnatives/argumentcorruption/CheckLongArgs.java
! test/hotspot/jtreg/compiler/runtime/criticalnatives/lookup/LookUp.java

Changeset: 46637047
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-12 07:58:12 +0000
URL:       https://git.openjdk.java.net/amber/commit/46637047

8259583: Remove unused decode_env::_codeBuffer

Reviewed-by: thartmann

! src/hotspot/share/compiler/disassembler.cpp

Changeset: a3561ae8
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2021-01-12 08:18:45 +0000
URL:       https://git.openjdk.java.net/amber/commit/a3561ae8

8258243: C2: assert failed ("Bad derived pointer") with -XX:+VerifyRegisterAllocator

Reviewed-by: kvn, thartmann

! src/hotspot/share/opto/chaitin.cpp
+ test/hotspot/jtreg/compiler/regalloc/TestVerifyRegisterAllocator.java

Changeset: a6ab9e47
Author:    Richard Reingruber <rrich at openjdk.org>
Date:      2021-01-12 08:35:12 +0000
URL:       https://git.openjdk.java.net/amber/commit/a6ab9e47

8258576: Try to get zerobased CCS if heap is above 32 and CDS is disabled

Reviewed-by: mdoerr, stuefe

! src/hotspot/share/memory/metaspace.cpp
! test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointers.java

Changeset: 4697cfa4
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-12 10:52:36 +0000
URL:       https://git.openjdk.java.net/amber/commit/4697cfa4

8259576: Misplaced curly brace in Matcher::find_shared_post_visit

Reviewed-by: lucy, thartmann

! src/hotspot/share/opto/matcher.cpp

Changeset: ac2dee56
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2021-01-12 11:41:29 +0000
URL:       https://git.openjdk.java.net/amber/commit/ac2dee56

8259539: JDK-8255711 broke trap messages

Reviewed-by: lfoltan, dholmes

! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp
! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp
! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp

Changeset: 400dc76f
Author:    Peter Zhelezniakov <peterz at openjdk.org>
Committer: Alexander Scherbatiy <alexsch at openjdk.org>
Date:      2021-01-12 11:50:19 +0000
URL:       https://git.openjdk.java.net/amber/commit/400dc76f

8252015: [macos11] java.awt.TrayIcon requires updates for template images

Co-authored-by: Tres Finocchiaro <tres.finocchiaro at gmail.com>
Co-authored-by: Peter Zhelezniakov <peterz at openjdk.org>
Reviewed-by: serb

! src/java.desktop/macosx/classes/sun/lwawt/macosx/CTrayIcon.java
! src/java.desktop/macosx/native/libawt_lwawt/awt/CTrayIcon.h
! src/java.desktop/macosx/native/libawt_lwawt/awt/CTrayIcon.m
! src/java.desktop/share/classes/java/awt/TrayIcon.java

Changeset: 563b268c
Author:    Sergey Platonov <sergey.platonov at gapfruit.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-12 11:57:34 +0000
URL:       https://git.openjdk.java.net/amber/commit/563b268c

8257709: C1: Double assignment in InstructionPrinter::print_stack

Reviewed-by: shade, chagedorn

! src/hotspot/share/c1/c1_InstructionPrinter.cpp

Changeset: 4c75d14a
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2021-01-12 13:07:21 +0000
URL:       https://git.openjdk.java.net/amber/commit/4c75d14a

8259374: Make ThreadInVMfromNative have ResetNoHandleMark

Reviewed-by: dcubed, pchilanomate

! src/hotspot/share/ci/ciUtilities.inline.hpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/jfr/recorder/checkpoint/jfrCheckpointManager.cpp
! src/hotspot/share/jfr/recorder/repository/jfrChunkRotation.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/runtime/handles.hpp
! src/hotspot/share/runtime/interfaceSupport.inline.hpp

Changeset: ccac7aae
Author:    Dong Bo <dongbo at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2021-01-12 13:27:47 +0000
URL:       https://git.openjdk.java.net/amber/commit/ccac7aae

8258932: AArch64: Enhance floating-point Min/MaxReductionV with fminp/fmaxp

Reviewed-by: aph

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/aarch64_neon.ad
! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4
! src/hotspot/cpu/aarch64/assembler_aarch64.hpp
! test/hotspot/gtest/aarch64/aarch64-asmtest.py
! test/hotspot/gtest/aarch64/asmtest.out.h
+ test/micro/org/openjdk/bench/vm/compiler/VectorReductionFloatingMinMax.java

Changeset: c338f116
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2021-01-12 14:39:58 +0000
URL:       https://git.openjdk.java.net/amber/commit/c338f116

8259349: -XX:AvgMonitorsPerThreadEstimate=1 does not work right

Reviewed-by: coleenp, dholmes

! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/synchronizer.cpp
! src/hotspot/share/runtime/synchronizer.hpp

Changeset: d6a2105b
Author:    Phil Race <prr at openjdk.org>
Date:      2021-01-12 20:19:44 +0000
URL:       https://git.openjdk.java.net/amber/commit/d6a2105b

8259343: [macOS] Update JNI error handling in Cocoa code.

Reviewed-by: erikj, serb

! make/modules/java.desktop/Lib.gmk
! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/GeomUtilities.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaTextAccessibility.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m
! src/java.desktop/macosx/native/libosxapp/JNIUtilities.h

Changeset: 5f7ccce0
Author:    Evan Whelan <ewhelan at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
Date:      2021-01-12 20:41:04 +0000
URL:       https://git.openjdk.java.net/amber/commit/5f7ccce0

8226810: Failed to launch JVM because of NullPointerException occured on System.props

Reviewed-by: alanb, naoto

! make/data/charsetmapping/stdcs-windows

Changeset: e4df2098
Author:    Laurent Bourg?s <lbourges at openjdk.org>
Date:      2021-01-12 20:51:54 +0000
URL:       https://git.openjdk.java.net/amber/commit/e4df2098

7018932: Drawing very large coordinates with a dashed Stroke can cause Java to hang

Reviewed-by: serb, prr

! src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java
! src/java.desktop/share/classes/sun/java2d/marlin/MarlinRenderingEngine.java
! src/java.desktop/share/classes/sun/java2d/marlin/TransformingPathConsumer2D.java
! src/java.desktop/share/classes/sun/java2d/pipe/LoopPipe.java
! src/java.desktop/share/classes/sun/java2d/pipe/RenderingEngine.java
! src/java.desktop/share/classes/sun/java2d/pipe/SpanShapeRenderer.java
+ test/jdk/sun/java2d/marlin/StrokedLinePerf.java

Changeset: 4be21734
Author:    Martin Balao <mbalao at openjdk.org>
Date:      2021-01-12 23:44:19 +0000
URL:       https://git.openjdk.java.net/amber/commit/4be21734

8259319: Illegal package access when SunPKCS11 requires SunJCE's classes

Reviewed-by: valeriep, mullan

! src/java.base/share/classes/module-info.java
! src/java.base/share/lib/security/default.policy
! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Util.java
+ test/jdk/sun/security/pkcs11/KeyAgreement/IllegalPackageAccess.java

Changeset: c6d798c2
Author:    Dong Bo <dongbo at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
Date:      2021-01-13 00:30:58 +0000
URL:       https://git.openjdk.java.net/amber/commit/c6d798c2

8259629: aarch64 builds fail after JDK-8258932

Reviewed-by: kvn

! test/hotspot/gtest/aarch64/aarch64-asmtest.py
! test/hotspot/gtest/aarch64/asmtest.out.h

Changeset: 65bed647
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
Date:      2021-01-13 01:10:29 +0000
URL:       https://git.openjdk.java.net/amber/commit/65bed647

8253635: Implement toString() for SSLEngineImpl

Reviewed-by: coffeys, wetmore

! src/java.base/share/classes/sun/security/ssl/SSLEngineImpl.java
! src/java.base/share/classes/sun/security/ssl/SSLSocketImpl.java

Changeset: 0957d9eb
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2021-01-13 02:30:33 +0000
URL:       https://git.openjdk.java.net/amber/commit/0957d9eb

8259519: The java.awt.datatransfer.DataFlavor#ioInputStreamClass field is redundant

Reviewed-by: aivanov

! src/java.datatransfer/share/classes/java/awt/datatransfer/DataFlavor.java
+ test/jdk/java/awt/datatransfer/DataFlavor/DefaultRepresentation.java

Changeset: 44c83794
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2021-01-13 06:57:52 +0000
URL:       https://git.openjdk.java.net/amber/commit/44c83794

8256019: JLabel HTML text does not support translucent text colors

Reviewed-by: serb

! src/java.desktop/share/classes/javax/swing/text/html/CSS.java
+ test/jdk/javax/swing/JLabel/TestTranslucentLabelText.java

Changeset: a483869a
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2021-01-13 07:00:37 +0000
URL:       https://git.openjdk.java.net/amber/commit/a483869a

8225045: javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java fails on linux-x64

Reviewed-by: serb, pbansal, trebari

! test/jdk/ProblemList.txt
! test/jdk/javax/swing/JInternalFrame/8146321/JInternalFrameIconTest.java

Changeset: 139b6dae
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2021-01-13 07:53:39 +0000
URL:       https://git.openjdk.java.net/amber/commit/139b6dae

8259372: remove AIX related USE_LIBRARY_BASED_TLS_ONLY and THREAD_LOCAL special handling

Reviewed-by: dholmes, stuefe

! src/hotspot/share/utilities/globalDefinitions_xlc.hpp

Changeset: 2243a170
Author:    liach <liach at users.noreply.github.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-13 08:02:33 +0000
URL:       https://git.openjdk.java.net/amber/commit/2243a170

8259485: Document need for short paths when building on Windows

Reviewed-by: erikj, shade

! doc/building.html
! doc/building.md

Changeset: 77ca1031
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2021-01-13 11:27:52 +0000
URL:       https://git.openjdk.java.net/amber/commit/77ca1031

8257236: can't use var with a class named Z

Reviewed-by: sundar

! src/jdk.jshell/share/classes/jdk/jshell/Wrap.java
! test/langtools/jdk/jshell/VariablesTest.java

Changeset: 2e124544
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-13 11:55:45 +0000
URL:       https://git.openjdk.java.net/amber/commit/2e124544

8259580: Shenandoah: uninitialized label in VerifyThreadGCState

Reviewed-by: zgu, rkennke

! src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp

Changeset: ce945120
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-13 12:30:28 +0000
URL:       https://git.openjdk.java.net/amber/commit/ce945120

8259619: C1: 3-arg StubAssembler::call_RT stack-use condition is incorrect

Reviewed-by: chagedorn, kvn

! src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp
! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp

Changeset: 535f2da5
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2021-01-13 14:32:52 +0000
URL:       https://git.openjdk.java.net/amber/commit/535f2da5

8259486: Replace PreserveExceptionMark with implementation for CautiouslyPreserveExceptionMark

Reviewed-by: dholmes, sspitsyn

! src/hotspot/cpu/arm/methodHandles_arm.cpp
! src/hotspot/cpu/ppc/methodHandles_ppc.cpp
! src/hotspot/cpu/s390/methodHandles_s390.cpp
! src/hotspot/cpu/x86/methodHandles_x86.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/jfr/recorder/service/jfrRecorderThread.cpp
! src/hotspot/share/prims/jvmtiEnter.xsl
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/handshake.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/utilities/exceptions.cpp
! src/hotspot/share/utilities/exceptions.hpp
! src/hotspot/share/utilities/preserveException.cpp
! src/hotspot/share/utilities/preserveException.hpp

Changeset: 5df2a949
Author:    Mahendra Chhipa <mahendra.chhipa at oracle.com>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
Date:      2021-01-13 15:53:05 +0000
URL:       https://git.openjdk.java.net/amber/commit/5df2a949

8212035: merge jdk.test.lib.util.SimpleHttpServer with jaxp.library.SimpleHttpServer

Reviewed-by: dfuchs

- test/jaxp/javax/xml/jaxp/libs/jaxp/library/SimpleHttpServer.java
! test/jaxp/javax/xml/jaxp/unittest/catalog/CatalogFileInputTest.java
! test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarAPI.java
! test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarHttpProperties.java
! test/jdk/java/util/jar/JarFile/mrjar/MultiReleaseJarProperties.java
! test/jdk/java/util/jar/JarFile/mrjar/TestVersionedStream.java
! test/jdk/lib/testlibrary/java/util/jar/CreateMultiReleaseTestJars.java
- test/jdk/lib/testlibrary/java/util/jar/SimpleHttpServer.java
! test/jdk/sun/net/www/protocol/jar/B4756443.java
! test/jdk/sun/net/www/protocol/jar/B5105410.java
! test/jdk/sun/net/www/protocol/jar/JarURLConnectionUseCaches.java
! test/jdk/sun/net/www/protocol/jar/MultiReleaseJarURLConnection.java
! test/jdk/sun/net/www/protocol/jar/jarbug/TestDriver.java
! test/jdk/sun/net/www/protocol/jar/jarbug/src/jar1/GetResource.java
! test/jdk/sun/net/www/protocol/jar/jarbug/src/jar1/LoadResourceBundle.java
! test/jdk/sun/net/www/protocol/jar/jarbug/src/test/JarTest.java
+ test/lib/jdk/test/lib/net/SimpleHttpServer.java

Changeset: 916ab4e7
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2021-01-13 17:01:39 +0000
URL:       https://git.openjdk.java.net/amber/commit/916ab4e7

8259283: use new HtmlId and HtmlIds classes

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/EnumConstantWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIds.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlIndexBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkFactoryImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NestedClassWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SectionName.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Signatures.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SourceToHTMLConverter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SubWriterHolderWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlId.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Links.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Table.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/SummaryAPIListBuilder.java

Changeset: ccdf171d
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2021-01-13 19:01:18 +0000
URL:       https://git.openjdk.java.net/amber/commit/ccdf171d

8259377: Shenandoah: Enhance weak reference processing time tracking

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp
! src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp
! src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.hpp

Changeset: c7e2174b
Author:    Hai-May Chao <hchao at openjdk.org>
Committer: Weijun Wang <weijun at openjdk.org>
Date:      2021-01-13 22:32:45 +0000
URL:       https://git.openjdk.java.net/amber/commit/c7e2174b

8259401: Add checking to jarsigner to warn weak algorithms used in signer?s cert chain

Reviewed-by: mullan, weijun, rhalade

! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Main.java
+ test/jdk/sun/security/tools/jarsigner/CheckSignerCertChain.java

Changeset: a7e5da22
Author:    Ningsheng Jian <njian at openjdk.org>
Date:      2021-01-12 01:31:58 +0000
URL:       https://git.openjdk.java.net/amber/commit/a7e5da22

8258384: AArch64: SVE verify_ptrue fails on some tests

Reviewed-by: adinn, ngasson

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp

Changeset: 28ff2de1
Author:    Pankaj Bansal <pbansal at openjdk.org>
Date:      2021-01-12 09:46:06 +0000
URL:       https://git.openjdk.java.net/amber/commit/28ff2de1

8259237: Demo selection changes with left/right arrow key. No need to press space for selection.

Reviewed-by: psadhukhan, kizune, serb

! src/java.desktop/share/classes/javax/swing/plaf/basic/BasicButtonUI.java
! test/jdk/javax/swing/ButtonGroup/TestButtonGroupFocusTraversal.java

Changeset: 67e1b639
Author:    Patrick Zhang <qpzhang at openjdk.org>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
Date:      2021-01-12 10:10:48 +0000
URL:       https://git.openjdk.java.net/amber/commit/67e1b639

8259380: Correct pretouch chunk size to cap with actual page size

Reviewed-by: tschatzl, sjohanss

! src/hotspot/share/gc/shared/pretouchTask.cpp

Changeset: 8a81cf15
Author:    Stuart Marks <smarks at openjdk.org>
Date:      2021-01-12 17:04:34 +0000
URL:       https://git.openjdk.java.net/amber/commit/8a81cf15

8259298: broken link in Stream::toList spec

Reviewed-by: bchristi, iris, lancea, naoto

! src/java.base/share/classes/java/util/stream/Stream.java

Changeset: b03880e3
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2021-01-12 17:09:05 +0000
URL:       https://git.openjdk.java.net/amber/commit/b03880e3

8259634: MemorySegment::asByteBuffer does not respect spatial bounds

Reviewed-by: alanb, chegar

! src/java.base/share/classes/java/nio/Buffer.java
! test/jdk/java/foreign/TestByteBuffer.java

Changeset: 5f9cd72c
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2021-01-12 19:57:08 +0000
URL:       https://git.openjdk.java.net/amber/commit/5f9cd72c

8259645: Revert JDK-8245956 JavaCompiler still uses File API instead of Path API in a specific case

Reviewed-by: chegar

! src/jdk.compiler/share/classes/com/sun/tools/javac/file/JavacFileManager.java
- test/langtools/tools/javac/T8245956/T8245956.java

Changeset: 17b4db31
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2021-01-12 21:06:03 +0000
URL:       https://git.openjdk.java.net/amber/commit/17b4db31

8259636: Check for buffer backed by shared segment kicks in in unexpected places

Reviewed-by: sundar, alanb, chegar

! src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template
! test/jdk/java/foreign/TestByteBuffer.java

Changeset: 1cf2378b
Author:    Xiaohong Gong <xgong at openjdk.org>
Committer: Ningsheng Jian <njian at openjdk.org>
Date:      2021-01-13 05:48:08 +0000
URL:       https://git.openjdk.java.net/amber/commit/1cf2378b

8259353: VectorReinterpretNode is incorrectly optimized out

Reviewed-by: vlivanov, njian

! src/hotspot/share/opto/vectornode.cpp

Changeset: 15dd8f3a
Author:    Calvin Cheung <ccheung at openjdk.org>
Date:      2021-01-13 05:51:52 +0000
URL:       https://git.openjdk.java.net/amber/commit/15dd8f3a

8259275: JRuby crashes while resolving invokedynamic instruction

Reviewed-by: iklam, minqi, lfoltan

! src/hotspot/share/classfile/classListParser.cpp
! src/hotspot/share/classfile/classListParser.hpp
! src/hotspot/share/oops/constantPool.cpp
! test/hotspot/jtreg/TEST.groups
! test/hotspot/jtreg/runtime/cds/appcds/BadBSM.java
+ test/hotspot/jtreg/runtime/cds/appcds/LambdaWithOldClass.java
+ test/hotspot/jtreg/runtime/cds/appcds/test-classes/LambdaWithOldClassApp.java
+ test/hotspot/jtreg/runtime/cds/appcds/test-classes/OldClass.jasm

Changeset: 793017d2
Author:    Xiaohong Gong <xgong at openjdk.org>
Committer: Ningsheng Jian <njian at openjdk.org>
Date:      2021-01-13 05:52:45 +0000
URL:       https://git.openjdk.java.net/amber/commit/793017d2

8259601: AArch64: Fix reinterpretX2D match rule issue

Reviewed-by: adinn, njian

! src/hotspot/cpu/aarch64/aarch64_neon.ad
! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4

Changeset: 417e1d1a
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
Date:      2021-01-13 07:22:30 +0000
URL:       https://git.openjdk.java.net/amber/commit/417e1d1a

8259061: C2: assert(found) failed: memory-writing node is not placed in its original loop or an ancestor of it

Remove assertion that is too general, that is, it can fail on compilations where
C2 generates correct code otherwise.

Reviewed-by: chagedorn, thartmann, kvn

! src/hotspot/share/opto/block.cpp

Changeset: efc36be5
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2021-01-13 08:22:40 +0000
URL:       https://git.openjdk.java.net/amber/commit/efc36be5

8258985: Parallel WeakProcessor may use too few threads

Use total workers rather than active.

Reviewed-by: tschatzl, ayang, sjohanss

! src/hotspot/share/gc/shared/weakProcessor.hpp
! src/hotspot/share/gc/shared/weakProcessor.inline.hpp

Changeset: a99df45b
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-13 08:49:12 +0000
URL:       https://git.openjdk.java.net/amber/commit/a99df45b

8259560: Zero m68k: "static assertion failed: align" after JDK-8252049

Reviewed-by: dholmes

! src/hotspot/share/ci/ciMethodData.cpp
! src/hotspot/share/oops/methodData.hpp

Changeset: 55675309
Author:    Nils Eliasson <neliasso at openjdk.org>
Date:      2021-01-13 09:16:08 +0000
URL:       https://git.openjdk.java.net/amber/commit/55675309

8258272: LoadVectorMaskedNode can't be replaced by zero con

Reviewed-by: chagedorn, vlivanov

! src/hotspot/share/opto/memnode.cpp
+ test/hotspot/jtreg/compiler/arraycopy/TestArrayCopyMaskedWithZeroSrc.java

Changeset: 6bb6093f
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2021-01-13 12:40:25 +0000
URL:       https://git.openjdk.java.net/amber/commit/6bb6093f

8259657: typo in generated HELP page prevents localization

Reviewed-by: vromero

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties

Changeset: 42d2d6dc
Author:    Erik ?sterlund <eosterlund at openjdk.org>
Date:      2021-01-13 16:48:17 +0000
URL:       https://git.openjdk.java.net/amber/commit/42d2d6dc

8259063: Possible deadlock with vtable/itable creation vs concurrent class unloading

Reviewed-by: pliden, neliasso

! src/hotspot/share/code/codeBlob.cpp
! src/hotspot/share/code/codeBlob.hpp
! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/codeCache.hpp

Changeset: ac4cd2e3
Author:    Vicente Romero <vromero at openjdk.org>
Date:      2021-01-13 17:27:32 +0000
URL:       https://git.openjdk.java.net/amber/commit/ac4cd2e3

8231461: static/instance overload leads to 'unexpected static method found in unbound lookup' when resolving method reference

Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
! test/langtools/lib/combo/tools/javac/combo/CompilationTestCase.java
! test/langtools/lib/combo/tools/javac/combo/Diagnostics.java
! test/langtools/lib/combo/tools/javac/combo/JavacTemplateTestBase.java
+ test/langtools/tools/javac/diags/examples/BoundUnboundMethRefSearch.java
+ test/langtools/tools/javac/diags/examples/BoundUnboundMethRefSearch2.java
+ test/langtools/tools/javac/lambda/methodReference/BoundUnboundSearchTest.java

Changeset: fb8ac247
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2021-01-13 18:23:12 +0000
URL:       https://git.openjdk.java.net/amber/commit/fb8ac247

8259722: ProblemList two jdk/jfr/startupargs tests on Windows

Reviewed-by: mgronlun

! test/jdk/ProblemList.txt

Changeset: 8abefdec
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2021-01-13 18:23:41 +0000
URL:       https://git.openjdk.java.net/amber/commit/8abefdec

8259720: ProblemList java/awt/Focus/AppletInitialFocusTest/AppletInitialFocusTest1.java on Windows

Reviewed-by: kizune, pbansal

! test/jdk/ProblemList.txt

Changeset: 5926d75f
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2021-01-13 19:52:04 +0000
URL:       https://git.openjdk.java.net/amber/commit/5926d75f

8259719: ProblemList runtime/cds/appcds/jigsaw/modulepath/ModulePathAndCP_JFR.java on Windows

Reviewed-by: pliden

! test/hotspot/jtreg/ProblemList.txt

Changeset: 51e14f2e
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
Date:      2021-01-14 01:29:47 +0000
URL:       https://git.openjdk.java.net/amber/commit/51e14f2e

Merge

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/aarch64_neon.ad
! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4
! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/share/ci/ciMethodData.cpp
! src/hotspot/share/code/codeBlob.cpp
! src/hotspot/share/gc/shared/pretouchTask.cpp
! src/hotspot/share/gc/shared/weakProcessor.inline.hpp
! src/hotspot/share/opto/memnode.cpp
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/TEST.groups
! test/jdk/ProblemList.txt
! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/aarch64_neon.ad
! src/hotspot/cpu/aarch64/aarch64_neon_ad.m4
! src/hotspot/cpu/aarch64/gc/z/zBarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp
! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/share/ci/ciMethodData.cpp
! src/hotspot/share/code/codeBlob.cpp
! src/hotspot/share/gc/shared/pretouchTask.cpp
! src/hotspot/share/gc/shared/weakProcessor.inline.hpp
! src/hotspot/share/opto/memnode.cpp
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/TEST.groups
! test/jdk/ProblemList.txt

Changeset: 5513f989
Author:    Hao Sun <hao.sun at arm.com>
Committer: Ningsheng Jian <njian at openjdk.org>
Date:      2021-01-14 04:11:20 +0000
URL:       https://git.openjdk.java.net/amber/commit/5513f989

8258010: Debug build failure with clang-10 due to -Wdeprecated-copy

Reviewed-by: xliu, kvn, kbarrett

! src/hotspot/share/opto/node.hpp

Changeset: ae9187d7
Author:    Alexander Zuev <kizune at openjdk.org>
Date:      2021-01-14 05:07:25 +0000
URL:       https://git.openjdk.java.net/amber/commit/ae9187d7

8256109: Create implementation for NSAccessibilityButton protocol

Reviewed-by: prr, serb

! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m
+ src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ButtonAccessibility.h
+ src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ButtonAccessibility.m
+ src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.h
+ src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m

Changeset: 8b8b1f9a
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2021-01-14 07:23:09 +0000
URL:       https://git.openjdk.java.net/amber/commit/8b8b1f9a

8259706: C2 compilation fails with assert(vtable_index == Method::invalid_vtable_index) failed: correct sentinel value

Reviewed-by: lucy, chagedorn

! src/hotspot/share/opto/library_call.cpp

Changeset: 3462f7a9
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2021-01-14 11:34:27 +0000
URL:       https://git.openjdk.java.net/amber/commit/3462f7a9

8256955: Move includes of events.hpp out of header files

Reviewed-by: kbarrett, coleenp

! src/hotspot/share/classfile/classLoaderDataGraph.cpp
! src/hotspot/share/gc/shared/collectedHeap.cpp
! src/hotspot/share/gc/shared/collectedHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/jvmci/jvmci.cpp
! src/hotspot/share/jvmci/jvmci.hpp
! src/hotspot/share/runtime/vmStructs.cpp

Changeset: b040a3d7
Author:    Aleksei Efimov <aefimov at openjdk.org>
Date:      2021-01-14 11:57:48 +0000
URL:       https://git.openjdk.java.net/amber/commit/b040a3d7

8259631: Reapply pattern match instanceof use in HttpClientImpl

Reviewed-by: dfuchs, chegar

! src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java

Changeset: b8ef2bad
Author:    Wang Xue <wangxue at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
Date:      2021-01-14 12:56:56 +0000
URL:       https://git.openjdk.java.net/amber/commit/b8ef2bad

8259563: The CPU model name is printed multiple times when using -Xlog:os+cpu

Reviewed-by: dholmes

! src/hotspot/os/linux/os_linux.cpp

Changeset: ff3e6e46
Author:    Jatin Bhateja <jbhateja at openjdk.org>
Date:      2021-01-14 13:20:06 +0000
URL:       https://git.openjdk.java.net/amber/commit/ff3e6e46

8259773: Incorrect encoding of AVX-512 kmovq instruction

Reviewed-by: vlivanov

! src/hotspot/cpu/x86/assembler_x86.cpp

Changeset: c822eda1
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Claes Redestad <redestad at openjdk.org>
Date:      2021-01-14 14:18:12 +0000
URL:       https://git.openjdk.java.net/amber/commit/c822eda1

8259699: Reduce char[] copying in URLEncoder.encode(String, Charset)

Reviewed-by: attila, redestad, chegar

! src/java.base/share/classes/java/net/URLEncoder.java

Changeset: be57cf14
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2021-01-14 14:23:27 +0000
URL:       https://git.openjdk.java.net/amber/commit/be57cf14

8226416: MonitorUsedDeflationThreshold can cause repeated async deflation requests

Reviewed-by: dholmes, coleenp

! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/synchronizer.cpp
+ test/hotspot/jtreg/runtime/Monitor/MonitorUsedDeflationThresholdTest.java

Changeset: 38a12017
Author:    Harold Seigel <hseigel at openjdk.org>
Date:      2021-01-14 15:04:31 +0000
URL:       https://git.openjdk.java.net/amber/commit/38a12017

8258912: Remove JVM options CountJNICalls and CountJVMCalls

Reviewed-by: coleenp, lfoltan, shade

! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/interfaceSupport.cpp
! src/hotspot/share/runtime/interfaceSupport.inline.hpp
! src/hotspot/share/runtime/java.cpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/sharedRuntime.hpp
- src/hotspot/share/utilities/histogram.cpp
- src/hotspot/share/utilities/histogram.hpp

Changeset: 1620664e
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2021-01-14 16:18:43 +0000
URL:       https://git.openjdk.java.net/amber/commit/1620664e

8259723: Move Table class to formats.html package

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllClassesIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AllPackagesIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstructorWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/EnumConstantWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/FieldWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/MethodWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/NestedClassWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageUseWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PackageWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PropertyWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SummaryListWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SystemPropertiesWriter.java
= src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Table.java
= src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TableHeader.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/package-info.java

Changeset: c2a3c7ef
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2021-01-14 16:20:45 +0000
URL:       https://git.openjdk.java.net/amber/commit/c2a3c7ef

8259727: Remove redundant "target" arguments to methods in Links

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDocletWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkFactoryImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkInfoImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/Links.java

Changeset: 8554fe6e
Author:    Jamil Nimeh <jnimeh at openjdk.org>
Date:      2021-01-14 16:36:51 +0000
URL:       https://git.openjdk.java.net/amber/commit/8554fe6e

8253866: Security Libs Terminology Refresh

Reviewed-by: erikj, weijun, mullan

! make/ToolsJdk.gmk
= make/data/blockedcertsconverter/blocked.certs.pem
= make/jdk/src/classes/build/tools/blockedcertsconverter/BlockedCertsConverter.java
! make/modules/java.base/Gendata.gmk
- make/modules/java.base/gendata/GendataBlacklistedCerts.gmk
+ make/modules/java.base/gendata/GendataBlockedCerts.gmk
! make/scripts/compare.sh
! src/java.base/share/classes/com/sun/crypto/provider/JceKeyStore.java
! src/java.base/share/classes/java/util/jar/JarVerifier.java
! src/java.base/share/classes/sun/security/provider/JavaKeyStore.java
! src/java.base/share/classes/sun/security/util/UntrustedCertificates.java
! src/java.base/share/conf/security/java.security
! src/java.security.jgss/share/classes/sun/security/krb5/Config.java
! src/java.security.jgss/share/classes/sun/security/krb5/KdcComm.java
! test/jdk/sun/security/krb5/auto/BogusKDC.java
- test/jdk/sun/security/lib/CheckBlacklistedCerts.java
+ test/jdk/sun/security/lib/CheckBlockedCerts.java

Changeset: aba3431c
Author:    Naoto Sato <naoto at openjdk.org>
Date:      2021-01-14 16:58:37 +0000
URL:       https://git.openjdk.java.net/amber/commit/aba3431c

8258956: Memory Leak in StringCoding on ThreadLocal resultCached StringCoding.Result

Reviewed-by: rriggs, alanb

! src/java.base/share/classes/java/lang/StringCoding.java

Changeset: da6bcf96
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2021-01-14 17:42:52 +0000
URL:       https://git.openjdk.java.net/amber/commit/da6bcf96

8255019: Shenandoah: Split STW and concurrent mark into separate classes

Reviewed-by: rkennke, shade

! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp
- src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
+ src/hotspot/share/gc/shenandoah/shenandoahMark.cpp
+ src/hotspot/share/gc/shenandoah/shenandoahMark.hpp
+ src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.cpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.hpp
! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp
! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp
! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp
! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp
+ src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp
+ src/hotspot/share/gc/shenandoah/shenandoahSTWMark.hpp

Changeset: a6b2162f
Author:    Sandhya Viswanathan <sviswanathan at openjdk.org>
Date:      2021-01-14 17:48:44 +0000
URL:       https://git.openjdk.java.net/amber/commit/a6b2162f

8259278: Optimize Vector API slice and unslice operations

Reviewed-by: psandoz, vlivanov

! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/cpu/x86/stubRoutines_x86.cpp
! src/hotspot/cpu/x86/stubRoutines_x86.hpp
! src/hotspot/cpu/x86/x86.ad
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template

Changeset: d18d26e8
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2021-01-14 21:01:42 +0000
URL:       https://git.openjdk.java.net/amber/commit/d18d26e8

8259350: Add some internal debugging APIs to the debug agent

Reviewed-by: sspitsyn, amenkov

! src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.c
! src/jdk.jdwp.agent/share/native/libjdwp/eventFilter.h
! src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.c
! src/jdk.jdwp.agent/share/native/libjdwp/eventHandler.h
! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.c
! src/jdk.jdwp.agent/share/native/libjdwp/threadControl.h
! src/jdk.jdwp.agent/share/native/libjdwp/util.c
! src/jdk.jdwp.agent/share/native/libjdwp/util.h

Changeset: 1ec86b93
Author:    duke <duke at openjdk.org>
Date:      2021-01-14 22:01:04 +0000
URL:       https://git.openjdk.java.net/amber/commit/1ec86b93

Automatic merge of master into stats-before-this-super

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties


From duke at openjdk.java.net  Thu Jan 14 22:05:23 2021
From: duke at openjdk.java.net (J.Duke)
Date: Thu, 14 Jan 2021 22:05:23 GMT
Subject: [lambda-leftovers] RFR: Merge master [v2]
In-Reply-To: <gM_-wML8b6Ci6cYWzSXsDw0eLL8ZU8iFWK36ncv4ryo=.228218dc-c9a6-410a-bba9-86aaac2de63a@github.com>
References: <gM_-wML8b6Ci6cYWzSXsDw0eLL8ZU8iFWK36ncv4ryo=.228218dc-c9a6-410a-bba9-86aaac2de63a@github.com>
Message-ID: <XVYAnWpqNgMflhK16Lk-rU9hyxbsKIf9PgixbMDUb7w=.d15e4647-1a4f-45e0-946a-0d735e53e273@github.com>

> Hi all,
> 
> this is an _automatically_ generated pull request to notify you that there are 10 commits from the branch `master`that can **not** be merged into the branch `lambda-leftovers`:
> 
> The following file contains merge conflicts:
> 
> - test/langtools/tools/javac/lambda/UnderscoreAsIdent.java
> 
> All Committers in this [project](https://openjdk.java.net/census#amber) have access to my [personal fork](https://github.com/openjdk-bot/amber) and can therefore help resolve these merge conflicts (you may want to coordinate who should do this).
> The following paragraphs will give an example on how to solve these merge conflicts and push the resulting merge commit to this pull request.
> The below commands should be run in a local clone of your [personal fork](https://wiki.openjdk.java.net/display/skara#Skara-Personalforks) of the [openjdk/amber](https://github.com/openjdk/amber) repository.
> 
> # Ensure target branch is up to date
> $ git checkout lambda-leftovers
> $ git pull https://github.com/openjdk/amber.git lambda-leftovers
> 
> # Fetch and checkout the branch for this pull request
> $ git fetch https://github.com/openjdk-bot/amber.git +78:openjdk-bot-78
> $ git checkout openjdk-bot-78
> 
> # Merge the target branch
> $ git merge lambda-leftovers
> 
> When you have resolved the conflicts resulting from the `git merge` command above, run the following commands to create a merge commit:
> 
> $ git add paths/to/files/with/conflicts
> $ git commit -m 'Merge master'
> 
> 
> When you have created the merge commit, run the following command to push the merge commit to this pull request:
> 
> $ git push https://github.com/openjdk-bot/amber.git openjdk-bot-78:78
> 
> _Note_: if you are using SSH to push commits to GitHub, then change the URL in the above `git push` command accordingly.
> 
> Thanks,
> J. Duke

J. Duke has updated the pull request incrementally with 207 additional commits since the last revision:

 - 8259350: Add some internal debugging APIs to the debug agent
   
   Reviewed-by: sspitsyn, amenkov
 - 8259278: Optimize Vector API slice and unslice operations
   
   Reviewed-by: psandoz, vlivanov
 - 8255019: Shenandoah: Split STW and concurrent mark into separate classes
   
   Reviewed-by: rkennke, shade
 - 8258956: Memory Leak in StringCoding on ThreadLocal resultCached StringCoding.Result
   
   Reviewed-by: rriggs, alanb
 - 8253866: Security Libs Terminology Refresh
   
   Reviewed-by: erikj, weijun, mullan
 - 8259727: Remove redundant "target" arguments to methods in Links
   
   Reviewed-by: hannesw
 - 8259723: Move Table class to formats.html package
   
   Reviewed-by: hannesw
 - 8258912: Remove JVM options CountJNICalls and CountJVMCalls
   
   Reviewed-by: coleenp, lfoltan, shade
 - 8226416: MonitorUsedDeflationThreshold can cause repeated async deflation requests
   
   Reviewed-by: dholmes, coleenp
 - 8259699: Reduce char[] copying in URLEncoder.encode(String, Charset)
   
   Reviewed-by: attila, redestad, chegar
 - ... and 197 more: https://git.openjdk.java.net/amber/compare/f5ee3565...d18d26e8

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

Changes:
  - all: https://git.openjdk.java.net/amber/pull/75/files
  - new: https://git.openjdk.java.net/amber/pull/75/files/f5ee3565..d18d26e8

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

  Stats: 40134 lines in 1211 files changed: 16015 ins; 11783 del; 12336 mod
  Patch: https://git.openjdk.java.net/amber/pull/75.diff
  Fetch: git fetch https://git.openjdk.java.net/amber pull/75/head:pull/75

PR: https://git.openjdk.java.net/amber/pull/75

From bsrbnd at gmail.com  Fri Jan 15 13:36:05 2021
From: bsrbnd at gmail.com (B. Blaser)
Date: Fri, 15 Jan 2021 14:36:05 +0100
Subject: Records, Intersection type and lambda
In-Reply-To: <83250674-fa48-27c0-446e-d484bee83d89@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>
 <CAEgw74D3xVQmgOdfe4ByBgZNW9TKOGLJ84CY0QgXXuE3=xGbNg@mail.gmail.com>
 <CAEgw74B_Dk_YYu_rc0POD2GdnA-0erqd2u-zK2oukg+Pgjd2uA@mail.gmail.com>
 <83250674-fa48-27c0-446e-d484bee83d89@oracle.com>
Message-ID: <CAEgw74Asmdx1zmQWgHqLSkKrna2iEXSBuKkjJoDmQfUnQ7My5g@mail.gmail.com>

On Thu, 14 Jan 2021 at 22:38, Vicente Romero <vicente.romero at oracle.com> wrote:
>
> Hi Bernard,
>
> On 1/6/21 8:02 AM, B. Blaser wrote:
> > Hi Vicente,
> >
> > I saw you've integrated the initial fix with no additional change
> > which seems reasonable.
> >
> > However, did you also try the example I provided below
>
> no I didn't sorry, I think that we will have to file a follow-up issue

Already filed a few days ago ;-)

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

Bernard

From romanowski.mateusz at gmail.com  Mon Jan 18 23:21:39 2021
From: romanowski.mateusz at gmail.com (Mateusz Romanowski)
Date: Tue, 19 Jan 2021 00:21:39 +0100
Subject: Composing patterns and guards
Message-ID: <CAL-BTSpP84KEvu=69LWy05qgS28t=23iQHsBxUrX53bJVxX3+w@mail.gmail.com>

Hi Brian et al.,
Regarding [1], would it not be possible to turn *any* boolean expression
into patterns if any cardinality was accepted for targets and outputs.

As an example, for `line instanceof Line(var point1, var point2) &&
point1.is(point2)` pattern-composable translation would be similar to `line
instanceof Line(var point1, var point2) && (point1, point2) instanceof
GUARD{Point::is}()`.

I apologize if such an idea has already been raised and I missed it.

Thanks,
Mateusz Romanowski


[1]
https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-January/002747.html

From brian.goetz at oracle.com  Tue Jan 19 01:38:56 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 18 Jan 2021 20:38:56 -0500
Subject: Composing patterns and guards
In-Reply-To: <CAL-BTSpP84KEvu=69LWy05qgS28t=23iQHsBxUrX53bJVxX3+w@mail.gmail.com>
References: <CAL-BTSpP84KEvu=69LWy05qgS28t=23iQHsBxUrX53bJVxX3+w@mail.gmail.com>
Message-ID: <3477A381-C14A-4A45-914F-7DA4BA26E5AD@oracle.com>

There are a few reasons we might not want to do this.

1.  Parsing ambiguities.  It would be ideal if the languages recognized by the Pattern production and the Expression production were disjoint.  We?ve eliminated a lot of them, but there are still several, such as `Foo()`.  (If we denoted constant patterns with constant literals, we?d have more.) Even if we could eliminate them all now, it may well constrain the pattern grammar in the future.  

2.  I think it would likely be confusing to humans, even if there were no parsing ambiguities, to have something like 

     x instnaceof P && g && h && Q, since we would have to keep track of whether we were conjoining patterns or expressions.  

3.  To the extent we support switches on booleans, and constant case labels as patterns, things like

    switch (b) { 
        case false && true: 
   }

would be puzzlers.  


> On Jan 18, 2021, at 6:21 PM, Mateusz Romanowski <romanowski.mateusz at gmail.com> wrote:
> 
> Hi Brian et al.,
> Regarding [1], would it not be possible to turn *any* boolean expression
> into patterns if any cardinality was accepted for targets and outputs.
> 
> As an example, for `line instanceof Line(var point1, var point2) &&
> point1.is(point2)` pattern-composable translation would be similar to `line
> instanceof Line(var point1, var point2) && (point1, point2) instanceof
> GUARD{Point::is}()`.
> 
> I apologize if such an idea has already been raised and I missed it.
> 
> Thanks,
> Mateusz Romanowski
> 
> 
> [1]
> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-January/002747.html


From augustnagro at gmail.com  Wed Jan 20 00:06:05 2021
From: augustnagro at gmail.com (August Nagro)
Date: Tue, 19 Jan 2021 16:06:05 -0800
Subject: Destructuring / Patterns in for-each
Message-ID: <CAHNb0ZNAkesvQLfUcnE_izXA+AW3+Q=K3BEseLFQqR39RvszLQ@mail.gmail.com>

Hello,

I wouldn't be surprised if this has been thought of / discussed before, but
I would love to some day use destructuring in for-each loops, kind of like
the for-of loop in JavaScript.

For example, instead of

record Point(double x, double y) {};

double greatestMagnitude = 0.0;
Point[] points = ...

for (Point p : points) {
  greatestMagnitude =
    max(greatestMagnitude, sqrt(pow(p.x(), 2) + pow(p.y(), 2)))
}

We could have:

for (Point(var x, var y) : points) {
  greatestMagnitude =
    max(greatestMagnitude, sqrt(pow(x, 2) + pow(y, 2)))
}

Not a huge improvement in this example, but there's a lot of code like
this. It would be a nice bonus if Map.Entry could be destructured, but I
don't see how that would be possible since it's an interface.

Regards,

August

From brian.goetz at oracle.com  Wed Jan 20 00:16:38 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 19 Jan 2021 19:16:38 -0500
Subject: Destructuring / Patterns in for-each
In-Reply-To: <CAHNb0ZNAkesvQLfUcnE_izXA+AW3+Q=K3BEseLFQqR39RvszLQ@mail.gmail.com>
References: <CAHNb0ZNAkesvQLfUcnE_izXA+AW3+Q=K3BEseLFQqR39RvszLQ@mail.gmail.com>
Message-ID: <72110829-18dd-cb12-ae05-e5a540f7fc12@oracle.com>

Yes, absolutely this is on the radar.? There is a whole constellation of 
related features to use total patterns in various places.? The use in 
for-loops is a generalization of the pattern-bind statement; right now, 
you can declare locals as

 ??? Foo f = expr

If you squint, you can see this as an unconditional pattern bind; the 
LHS is a pattern (`Foo f` is a type pattern) that declares a binding 
variable `f`, the RHS can be a match target, and the pattern is total on 
the static type of the target, so no conditional wrapping (instanceof, 
switch, try, etc) is needed. If so, we can generalize this to 
deconstruction patterns:

 ??? Point(var x, var y) = aPoint

Readers might find this weird at first, so we've considered other 
syntaxes (e.g., a `let` statement), but I prefer this version for the 
very reason you have cited -- that it can be lifted directly into things 
like foreach loops, try-with-resources blocks, method declarations, and 
any other places where "locals" are declared.

Your Map.Entry inquiry illustrates one of the reasons why we want 
patterns to be full-fledged class members; if we can put a 
deconstruction pattern on an interface like `Map.Entry` (and there's no 
reason we can't), we can iterate a map with:

 ??? for (Map.Entry(var key, var value) : map.entrySet())
 ??????? System.out.printf("%s: %s%n", key, value);

This isn't quite as concise as Python's

 ??? for x, y in dict.items():
 ??????? ...

but it's close.

So: yes, yes, and bonus yes.

On 1/19/2021 7:06 PM, August Nagro wrote:
> Hello,
>
> I wouldn't be surprised if this has been thought of / discussed before, but
> I would love to some day use destructuring in for-each loops, kind of like
> the for-of loop in JavaScript.
>
> For example, instead of
>
> record Point(double x, double y) {};
>
> double greatestMagnitude = 0.0;
> Point[] points = ...
>
> for (Point p : points) {
>    greatestMagnitude =
>      max(greatestMagnitude, sqrt(pow(p.x(), 2) + pow(p.y(), 2)))
> }
>
> We could have:
>
> for (Point(var x, var y) : points) {
>    greatestMagnitude =
>      max(greatestMagnitude, sqrt(pow(x, 2) + pow(y, 2)))
> }
>
> Not a huge improvement in this example, but there's a lot of code like
> this. It would be a nice bonus if Map.Entry could be destructured, but I
> don't see how that would be possible since it's an interface.
>
> Regards,
>
> August


From info at j-kuhn.de  Wed Jan 20 00:30:36 2021
From: info at j-kuhn.de (Johannes Kuhn)
Date: Wed, 20 Jan 2021 01:30:36 +0100
Subject: Q on Patterns and Streams
Message-ID: <e4b3ea9a-f8ab-8b7f-7bb4-09fd26c0df3c@j-kuhn.de>

Turns out I sometimes write code that looks like this:

     foos.stream().filter(e -> e instanceof Foo).map(e -> (Foo) e)...

or

     foos.stream().filter(Foo.class::isInstance).map(Foo.class::cast)...

Nicolas Fr?nkel has even written a blog post about this[1].

Anyway, this can be expressed with a single stream operation:

     foos.stream().flatMap(e -> e instanceof Foo foo ? Stream.of(foo) : 
Stream.of())...

I expect that form to work with any pattern in the future.
But it doesn't look great.

Are there any plans around this?
Or is this something patterns shouldn't be used for?

In a more general way - will there be a way to pass a pattern as an 
argument to some other function?

- Johannes



[1]: https://blog.frankel.ch/changing-coding-habits-stream-friendly/

From augustnagro at gmail.com  Wed Jan 20 00:36:00 2021
From: augustnagro at gmail.com (August Nagro)
Date: Tue, 19 Jan 2021 16:36:00 -0800
Subject: Destructuring / Patterns in for-each
In-Reply-To: <72110829-18dd-cb12-ae05-e5a540f7fc12@oracle.com>
References: <CAHNb0ZNAkesvQLfUcnE_izXA+AW3+Q=K3BEseLFQqR39RvszLQ@mail.gmail.com>
 <72110829-18dd-cb12-ae05-e5a540f7fc12@oracle.com>
Message-ID: <CAHNb0ZMrt3SwV8xdCZKPuZPqT+y_uhFQN9UjaorrNbocFGwvsQ@mail.gmail.com>

Awesome, that's exciting!

I definitely see how such class-member patterns could benefit serialization
libraries too.

On Tue, Jan 19, 2021, 4:16 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> Yes, absolutely this is on the radar.  There is a whole constellation of
> related features to use total patterns in various places.  The use in
> for-loops is a generalization of the pattern-bind statement; right now, you
> can declare locals as
>
>     Foo f = expr
>
> If you squint, you can see this as an unconditional pattern bind; the LHS
> is a pattern (`Foo f` is a type pattern) that declares a binding variable
> `f`, the RHS can be a match target, and the pattern is total on the static
> type of the target, so no conditional wrapping (instanceof, switch, try,
> etc) is needed.  If so, we can generalize this to deconstruction patterns:
>
>     Point(var x, var y) = aPoint
>
> Readers might find this weird at first, so we've considered other syntaxes
> (e.g., a `let` statement), but I prefer this version for the very reason
> you have cited -- that it can be lifted directly into things like foreach
> loops, try-with-resources blocks, method declarations, and any other places
> where "locals" are declared.
>
> Your Map.Entry inquiry illustrates one of the reasons why we want patterns
> to be full-fledged class members; if we can put a deconstruction pattern on
> an interface like `Map.Entry` (and there's no reason we can't), we can
> iterate a map with:
>
>     for (Map.Entry(var key, var value) : map.entrySet())
>         System.out.printf("%s: %s%n", key, value);
>
> This isn't quite as concise as Python's
>
>     for x, y in dict.items():
>         ...
>
> but it's close.
>
> So: yes, yes, and bonus yes.
>
> On 1/19/2021 7:06 PM, August Nagro wrote:
>
> Hello,
>
> I wouldn't be surprised if this has been thought of / discussed before, but
> I would love to some day use destructuring in for-each loops, kind of like
> the for-of loop in JavaScript.
>
> For example, instead of
>
> record Point(double x, double y) {};
>
> double greatestMagnitude = 0.0;
> Point[] points = ...
>
> for (Point p : points) {
>   greatestMagnitude =
>     max(greatestMagnitude, sqrt(pow(p.x(), 2) + pow(p.y(), 2)))
> }
>
> We could have:
>
> for (Point(var x, var y) : points) {
>   greatestMagnitude =
>     max(greatestMagnitude, sqrt(pow(x, 2) + pow(y, 2)))
> }
>
> Not a huge improvement in this example, but there's a lot of code like
> this. It would be a nice bonus if Map.Entry could be destructured, but I
> don't see how that would be possible since it's an interface.
>
> Regards,
>
> August
>
>
>

From sirinath1978m at gmail.com  Wed Jan 20 06:42:03 2021
From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena)
Date: Wed, 20 Jan 2021 12:12:03 +0530
Subject: Pattern features for next iteration
In-Reply-To: <CAAfFNYG0eSipbfU+Y9zKu8YZWDbhXK4tnEb2wtcHo3opiCsg7w@mail.gmail.com>
References: <c14ba7c6-8056-0085-df34-92a99ff32b78@oracle.com>
 <CAAfFNYG0eSipbfU+Y9zKu8YZWDbhXK4tnEb2wtcHo3opiCsg7w@mail.gmail.com>
Message-ID: <CAAfFNYE4OS-QPS=nV4Rhi6_2h5X8bbXa0X9SawfEHpg1q5enyA@mail.gmail.com>

Can we accomodate something like:
   if (strarr instanceof String[] {var head, var... tail} wholestrarr)
or
   if (strarr instanceof String[] {var head, var... tail})
or
   if (strarr instanceof String[] {String head, String... tail} wholestrarr)

or
   if (strarr instanceof String[] {String head, String... tail})

Also need to consider situations like:
   if (true || (strarr instanceof String[] wholestrarr)) {
      // what is wholestrarr here? Is it null? Is it a ClassCastException?
 }
is this similar to
   if (true || (strarr instanceof String[])) {
      String[] wholestrarr = (String[]) strarr;
   }

What about:
   if ((arr instanceof int[] intarr) || (arr instanceof String[] strarr)) {
      // what is intarr / strarr here? Is one of them null? Is it a
ClassCastException?
   }

From sirinath1978m at gmail.com  Wed Jan 20 07:47:06 2021
From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena)
Date: Wed, 20 Jan 2021 13:17:06 +0530
Subject: Pattern features for next iteration
In-Reply-To: <CAAfFNYE4OS-QPS=nV4Rhi6_2h5X8bbXa0X9SawfEHpg1q5enyA@mail.gmail.com>
References: <c14ba7c6-8056-0085-df34-92a99ff32b78@oracle.com>
 <CAAfFNYG0eSipbfU+Y9zKu8YZWDbhXK4tnEb2wtcHo3opiCsg7w@mail.gmail.com>
 <CAAfFNYE4OS-QPS=nV4Rhi6_2h5X8bbXa0X9SawfEHpg1q5enyA@mail.gmail.com>
Message-ID: <CAAfFNYFVqFFR_b7FK0eNed5P4UdKtzifMcH2KV7QCjf88jApXQ@mail.gmail.com>

Also perhaps another area to address is low overhead high performance
object deconstruction so that pattern matching can be extended to
Collections and ordinary Java Objects.

From kasperni at gmail.com  Wed Jan 20 10:20:24 2021
From: kasperni at gmail.com (Kasper Nielsen)
Date: Wed, 20 Jan 2021 10:20:24 +0000
Subject: Q on Patterns and Streams
In-Reply-To: <e4b3ea9a-f8ab-8b7f-7bb4-09fd26c0df3c@j-kuhn.de>
References: <e4b3ea9a-f8ab-8b7f-7bb4-09fd26c0df3c@j-kuhn.de>
Message-ID: <CAPs6153c4t8zVByytqrry-5BcgVKmzbqCF7XYuyR=fvb+Uj-NQ@mail.gmail.com>

On Wed, 20 Jan 2021 at 00:31, Johannes Kuhn <info at j-kuhn.de> wrote:
>
> Turns out I sometimes write code that looks like this:
>
>      foos.stream().filter(e -> e instanceof Foo).map(e -> (Foo) e)...
>
> or
>
>      foos.stream().filter(Foo.class::isInstance).map(Foo.class::cast)...
>
> Nicolas Fr?nkel has even written a blog post about this[1].

Now, this is a bit off-topic and I don't want to hijack your question.
But I've always wished Stream<T> had a
  <S> Stream<S> filterOnType(Class<? extends S> type);
method.

/Kasper

From brian.goetz at oracle.com  Wed Jan 20 14:54:24 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 20 Jan 2021 09:54:24 -0500
Subject: Q on Patterns and Streams
In-Reply-To: <e4b3ea9a-f8ab-8b7f-7bb4-09fd26c0df3c@j-kuhn.de>
References: <e4b3ea9a-f8ab-8b7f-7bb4-09fd26c0df3c@j-kuhn.de>
Message-ID: <8e60c3df-658e-34bc-e924-7f14024f73ab@oracle.com>

Indeed, this is a question we've wrestled with.

You are right that this is a sort of flatMap.? And that the current 
flatMap doesn't express it very nicely, or efficiently.

We've recently added another form of flatMap, mapMulti, which is a lot 
more efficient; in that version, your example would be:

 ??? .mapMulti((e,s) -> { if (e instanceof P(b)) s.accept(b); })

If `void` were a type, we could express this as an expression lambda:

 ??? .mapMulti((e,s) -> e instanceof P(b) ? s.accept(b) : void )

A variant of mapMulti optimized for zero-or-one (which would be more 
sensible when Optional is a primitive class) might be:

 ??? .mapMaybe(e -> Optional.ofNullable(e instanceof P(b) ? b : null) )

where mapMaybe takes a T -> Optional<U>.

Note that the use of patterns here is limited to the case where you are 
going to package up all the bindings into a single value.

There's some other possibilities but I want to think about them some 
more before discussing them.


On 1/19/2021 7:30 PM, Johannes Kuhn wrote:
> Turns out I sometimes write code that looks like this:
>
> ??? foos.stream().filter(e -> e instanceof Foo).map(e -> (Foo) e)...
>
> or
>
> foos.stream().filter(Foo.class::isInstance).map(Foo.class::cast)...
>
> Nicolas Fr?nkel has even written a blog post about this[1].
>
> Anyway, this can be expressed with a single stream operation:
>
> ??? foos.stream().flatMap(e -> e instanceof Foo foo ? Stream.of(foo) : 
> Stream.of())...
>
> I expect that form to work with any pattern in the future.
> But it doesn't look great.
>
> Are there any plans around this?
> Or is this something patterns shouldn't be used for?
>
> In a more general way - will there be a way to pass a pattern as an 
> argument to some other function?
>
> - Johannes
>
>
>
> [1]: https://blog.frankel.ch/changing-coding-habits-stream-friendly/


From info at j-kuhn.de  Wed Jan 20 15:23:30 2021
From: info at j-kuhn.de (Johannes Kuhn)
Date: Wed, 20 Jan 2021 16:23:30 +0100
Subject: Q on Patterns and Streams
In-Reply-To: <8e60c3df-658e-34bc-e924-7f14024f73ab@oracle.com>
References: <e4b3ea9a-f8ab-8b7f-7bb4-09fd26c0df3c@j-kuhn.de>
 <8e60c3df-658e-34bc-e924-7f14024f73ab@oracle.com>
Message-ID: <76e7b94b-d15d-158a-d2fc-b9927f9cf819@j-kuhn.de>

Thanks for the reply.

Stream.mapMulty does indeed help a bit.
I think your examples need a type hint so they would actually compile - 
.<P>mapMulti(...).

If I had to guess the future, then I would guess that a pattern, 
followed by the creation of some product type (record...) could be often 
desired. But that's just a guess.

Sure, this can be expressed with .mapMaybe(pattern ? Optional.of(new 
Result(a, b, c)) : Optional.empty()).

But you have it on your radar, so I am certain that you will come up 
with something better.

- Johannes

PS.: Java's type inference is complicated, and limited compared to 
haskell. I still don't understand why one of the following lines doesn't 
compile:

    Supplier<Iterator<? extends CharSequence>> s = () -> 
List.of("foo").iterator();
    Iterable<? extends CharSequence> i = () -> List.of("Foo").iterator();

To me, they appear to have the same shape. Type inference is 
complicated. Or I don't have the right mental model for it.

On 20-Jan-21 15:54, Brian Goetz wrote:
> Indeed, this is a question we've wrestled with.
> 
> You are right that this is a sort of flatMap.? And that the current 
> flatMap doesn't express it very nicely, or efficiently.
> 
> We've recently added another form of flatMap, mapMulti, which is a lot 
> more efficient; in that version, your example would be:
> 
>  ??? .mapMulti((e,s) -> { if (e instanceof P(b)) s.accept(b); })
> 
> If `void` were a type, we could express this as an expression lambda:
> 
>  ??? .mapMulti((e,s) -> e instanceof P(b) ? s.accept(b) : void )
> 
> A variant of mapMulti optimized for zero-or-one (which would be more 
> sensible when Optional is a primitive class) might be:
> 
>  ??? .mapMaybe(e -> Optional.ofNullable(e instanceof P(b) ? b : null) )
> 
> where mapMaybe takes a T -> Optional<U>.
> 
> Note that the use of patterns here is limited to the case where you are 
> going to package up all the bindings into a single value.
> 
> There's some other possibilities but I want to think about them some 
> more before discussing them.
> 
> 
> On 1/19/2021 7:30 PM, Johannes Kuhn wrote:
>> Turns out I sometimes write code that looks like this:
>>
>> ??? foos.stream().filter(e -> e instanceof Foo).map(e -> (Foo) e)...
>>
>> or
>>
>> foos.stream().filter(Foo.class::isInstance).map(Foo.class::cast)...
>>
>> Nicolas Fr?nkel has even written a blog post about this[1].
>>
>> Anyway, this can be expressed with a single stream operation:
>>
>> ??? foos.stream().flatMap(e -> e instanceof Foo foo ? Stream.of(foo) : 
>> Stream.of())...
>>
>> I expect that form to work with any pattern in the future.
>> But it doesn't look great.
>>
>> Are there any plans around this?
>> Or is this something patterns shouldn't be used for?
>>
>> In a more general way - will there be a way to pass a pattern as an 
>> argument to some other function?
>>
>> - Johannes
>>
>>
>>
>> [1]: https://blog.frankel.ch/changing-coding-habits-stream-friendly/
> 

From brian.goetz at oracle.com  Wed Jan 20 15:34:49 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 20 Jan 2021 10:34:49 -0500
Subject: [External] : Re: Q on Patterns and Streams
In-Reply-To: <76e7b94b-d15d-158a-d2fc-b9927f9cf819@j-kuhn.de>
References: <e4b3ea9a-f8ab-8b7f-7bb4-09fd26c0df3c@j-kuhn.de>
 <8e60c3df-658e-34bc-e924-7f14024f73ab@oracle.com>
 <76e7b94b-d15d-158a-d2fc-b9927f9cf819@j-kuhn.de>
Message-ID: <d1015025-02ab-ba38-4d58-a5653f71c84a@oracle.com>



> If I had to guess the future, then I would guess that a pattern, 
> followed by the creation of some product type (record...) could be 
> often desired. But that's just a guess.

Yes, this is a part we're wrestling with.? If there was a 
SAM-conversion-like conversion from a pattern to a T -> Optional<U>, 
then the `mapMaybe` path works great, but this only works for patterns 
that yield one binding.? For patterns that have multiple, an 
intermediate record is required, which is an additional moving part.? 
It's possible this could be a synthetic anonymous record, but there's a 
lot of details to work through, and an evaluation of whether the cost is 
justified by the benefit.? To be continued.



From Gavin.Bierman at oracle.com  Thu Jan 21 11:27:15 2021
From: Gavin.Bierman at oracle.com (Gavin Bierman)
Date: Thu, 21 Jan 2021 11:27:15 +0000
Subject: Pattern features for next iteration
In-Reply-To: <CAAfFNYE4OS-QPS=nV4Rhi6_2h5X8bbXa0X9SawfEHpg1q5enyA@mail.gmail.com>
References: <c14ba7c6-8056-0085-df34-92a99ff32b78@oracle.com>
 <CAAfFNYG0eSipbfU+Y9zKu8YZWDbhXK4tnEb2wtcHo3opiCsg7w@mail.gmail.com>
 <CAAfFNYE4OS-QPS=nV4Rhi6_2h5X8bbXa0X9SawfEHpg1q5enyA@mail.gmail.com>
Message-ID: <137A3F21-673B-417D-BFA7-A08AFA4C5594@oracle.com>



> On 20 Jan 2021, at 06:42, Suminda Sirinath Salpitikorala Dharmasena <sirinath1978m at gmail.com> wrote:
> 
> Can we accomodate something like:
>   if (strarr instanceof String[] {var head, var... tail} wholestrarr)
> or
>   if (strarr instanceof String[] {var head, var... tail})
> or
>   if (strarr instanceof String[] {String head, String... tail} wholestrarr)
> 
> or
>   if (strarr instanceof String[] {String head, String... tail})

I?m not sure I can figure out what these patterns might mean. The form of the array pattern is supposed to match up with the array creation expressions, so we get a nice symmetry

new String[] { ?one?, ?two? } matches String[] { var a, var b}
and
new String[] { ?one?, ?two?, ?three" } matches String[] { var a, var b, ? }

Sure we could go crazy and start offering binding for portions of the array, but that would imply that pattern matching will be in the business of array creation, which I think would be a very confusing model for developers. 


> 
> Also need to consider situations like:
>   if (true || (strarr instanceof String[] wholestrarr)) {
>      // what is wholestrarr here? Is it null? Is it a ClassCastException?

It is not in scope ?here?. This is dealt with in the current JEP 394. 

> }
> is this similar to
>   if (true || (strarr instanceof String[])) {
>      String[] wholestrarr = (String[]) strarr;
>   }
> 
> What about:
>   if ((arr instanceof int[] intarr) || (arr instanceof String[] strarr)) {
>      // what is intarr / strarr here? Is one of them null? Is it a
> ClassCastException?
>   }


Gavin

From duke at openjdk.java.net  Thu Jan 21 23:06:26 2021
From: duke at openjdk.java.net (duke)
Date: Thu, 21 Jan 2021 23:06:26 GMT
Subject: git: openjdk/amber: stats-before-this-super: 95 new changesets
Message-ID: <b73a0189-9112-42a8-b9c4-6d9d81982008@openjdk.org>

Changeset: 4f881ba5
Author:    Chris Plummer <cjplummer at openjdk.org>
Date:      2021-01-14 23:04:07 +0000
URL:       https://git.openjdk.java.net/amber/commit/4f881ba5

8258652: Assert in JvmtiThreadState::cur_stack_depth() can noticeably slow down debugging single stepping

Reviewed-by: sspitsyn, dholmes, amenkov

! src/hotspot/share/prims/jvmtiThreadState.cpp
! src/hotspot/share/runtime/globals.hpp

Changeset: bf28f925
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2021-01-14 23:25:14 +0000
URL:       https://git.openjdk.java.net/amber/commit/bf28f925

8259713: Fix comments about ResetNoHandleMark in deoptimization

Reviewed-by: lfoltan, dcubed, dholmes

! src/hotspot/share/runtime/deoptimization.cpp

Changeset: 978bed6c
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2021-01-15 00:28:08 +0000
URL:       https://git.openjdk.java.net/amber/commit/978bed6c

8259522: Apply java.io.Serial annotations in java.desktop

Reviewed-by: aivanov, psadhukhan

! src/java.desktop/share/classes/com/sun/beans/editors/ColorEditor.java
! src/java.desktop/share/classes/com/sun/beans/editors/FontEditor.java
! src/java.desktop/share/classes/com/sun/beans/finder/SignatureException.java
! src/java.desktop/share/classes/com/sun/imageio/plugins/common/SimpleCMYKColorSpace.java
! src/java.desktop/share/classes/com/sun/media/sound/InvalidDataException.java
! src/java.desktop/share/classes/com/sun/media/sound/InvalidFormatException.java
! src/java.desktop/share/classes/com/sun/media/sound/RIFFInvalidDataException.java
! src/java.desktop/share/classes/com/sun/media/sound/RIFFInvalidFormatException.java
! src/java.desktop/share/classes/java/applet/Applet.java
! src/java.desktop/share/classes/java/awt/AWTError.java
! src/java.desktop/share/classes/java/awt/AWTEvent.java
! src/java.desktop/share/classes/java/awt/AWTException.java
! src/java.desktop/share/classes/java/awt/AWTKeyStroke.java
! src/java.desktop/share/classes/java/awt/AWTPermission.java
! src/java.desktop/share/classes/java/awt/BorderLayout.java
! src/java.desktop/share/classes/java/awt/Button.java
! src/java.desktop/share/classes/java/awt/Canvas.java
! src/java.desktop/share/classes/java/awt/CardLayout.java
! src/java.desktop/share/classes/java/awt/Checkbox.java
! src/java.desktop/share/classes/java/awt/CheckboxGroup.java
! src/java.desktop/share/classes/java/awt/CheckboxMenuItem.java
! src/java.desktop/share/classes/java/awt/Choice.java
! src/java.desktop/share/classes/java/awt/Color.java
! src/java.desktop/share/classes/java/awt/Component.java
! src/java.desktop/share/classes/java/awt/ComponentOrientation.java
! src/java.desktop/share/classes/java/awt/Container.java
! src/java.desktop/share/classes/java/awt/ContainerOrderFocusTraversalPolicy.java
! src/java.desktop/share/classes/java/awt/Cursor.java
! src/java.desktop/share/classes/java/awt/DefaultFocusTraversalPolicy.java
! src/java.desktop/share/classes/java/awt/DefaultKeyboardFocusManager.java
! src/java.desktop/share/classes/java/awt/Dialog.java
! src/java.desktop/share/classes/java/awt/Dimension.java
! src/java.desktop/share/classes/java/awt/Event.java
! src/java.desktop/share/classes/java/awt/FileDialog.java
! src/java.desktop/share/classes/java/awt/FlowLayout.java
! src/java.desktop/share/classes/java/awt/Font.java
! src/java.desktop/share/classes/java/awt/FontFormatException.java
! src/java.desktop/share/classes/java/awt/FontMetrics.java
! src/java.desktop/share/classes/java/awt/Frame.java
! src/java.desktop/share/classes/java/awt/GraphicsConfigTemplate.java
! src/java.desktop/share/classes/java/awt/GridBagConstraints.java
! src/java.desktop/share/classes/java/awt/GridBagLayout.java
! src/java.desktop/share/classes/java/awt/GridBagLayoutInfo.java
! src/java.desktop/share/classes/java/awt/GridLayout.java
! src/java.desktop/share/classes/java/awt/HeadlessException.java
! src/java.desktop/share/classes/java/awt/IllegalComponentStateException.java
! src/java.desktop/share/classes/java/awt/Insets.java
! src/java.desktop/share/classes/java/awt/Label.java
! src/java.desktop/share/classes/java/awt/List.java
! src/java.desktop/share/classes/java/awt/MediaTracker.java
! src/java.desktop/share/classes/java/awt/Menu.java
! src/java.desktop/share/classes/java/awt/MenuBar.java
! src/java.desktop/share/classes/java/awt/MenuComponent.java
! src/java.desktop/share/classes/java/awt/MenuItem.java
! src/java.desktop/share/classes/java/awt/MenuShortcut.java
! src/java.desktop/share/classes/java/awt/Panel.java
! src/java.desktop/share/classes/java/awt/Point.java
! src/java.desktop/share/classes/java/awt/Polygon.java
! src/java.desktop/share/classes/java/awt/PopupMenu.java
! src/java.desktop/share/classes/java/awt/Rectangle.java
! src/java.desktop/share/classes/java/awt/ScrollPane.java
! src/java.desktop/share/classes/java/awt/ScrollPaneAdjustable.java
! src/java.desktop/share/classes/java/awt/Scrollbar.java
! src/java.desktop/share/classes/java/awt/SentEvent.java
! src/java.desktop/share/classes/java/awt/SequencedEvent.java
! src/java.desktop/share/classes/java/awt/SystemColor.java
! src/java.desktop/share/classes/java/awt/TextArea.java
! src/java.desktop/share/classes/java/awt/TextComponent.java
! src/java.desktop/share/classes/java/awt/TextField.java
! src/java.desktop/share/classes/java/awt/Window.java
! src/java.desktop/share/classes/java/awt/color/CMMException.java
! src/java.desktop/share/classes/java/awt/color/ColorSpace.java
! src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java
! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java
! src/java.desktop/share/classes/java/awt/color/ICC_ProfileGray.java
! src/java.desktop/share/classes/java/awt/color/ICC_ProfileRGB.java
! src/java.desktop/share/classes/java/awt/color/ProfileDataException.java
! src/java.desktop/share/classes/java/awt/desktop/AboutEvent.java
! src/java.desktop/share/classes/java/awt/desktop/AppEvent.java
! src/java.desktop/share/classes/java/awt/desktop/AppForegroundEvent.java
! src/java.desktop/share/classes/java/awt/desktop/AppHiddenEvent.java
! src/java.desktop/share/classes/java/awt/desktop/AppReopenedEvent.java
! src/java.desktop/share/classes/java/awt/desktop/FilesEvent.java
! src/java.desktop/share/classes/java/awt/desktop/OpenFilesEvent.java
! src/java.desktop/share/classes/java/awt/desktop/OpenURIEvent.java
! src/java.desktop/share/classes/java/awt/desktop/PreferencesEvent.java
! src/java.desktop/share/classes/java/awt/desktop/PrintFilesEvent.java
! src/java.desktop/share/classes/java/awt/desktop/QuitEvent.java
! src/java.desktop/share/classes/java/awt/desktop/ScreenSleepEvent.java
! src/java.desktop/share/classes/java/awt/desktop/SystemSleepEvent.java
! src/java.desktop/share/classes/java/awt/desktop/UserSessionEvent.java
! src/java.desktop/share/classes/java/awt/dnd/DragGestureEvent.java
! src/java.desktop/share/classes/java/awt/dnd/DragGestureRecognizer.java
! src/java.desktop/share/classes/java/awt/dnd/DragSource.java
! src/java.desktop/share/classes/java/awt/dnd/DragSourceContext.java
! src/java.desktop/share/classes/java/awt/dnd/DragSourceDragEvent.java
! src/java.desktop/share/classes/java/awt/dnd/DragSourceDropEvent.java
! src/java.desktop/share/classes/java/awt/dnd/DragSourceEvent.java
! src/java.desktop/share/classes/java/awt/dnd/DropTarget.java
! src/java.desktop/share/classes/java/awt/dnd/DropTargetContext.java
! src/java.desktop/share/classes/java/awt/dnd/DropTargetDragEvent.java
! src/java.desktop/share/classes/java/awt/dnd/DropTargetDropEvent.java
! src/java.desktop/share/classes/java/awt/dnd/DropTargetEvent.java
! src/java.desktop/share/classes/java/awt/dnd/InvalidDnDOperationException.java
! src/java.desktop/share/classes/java/awt/dnd/MouseDragGestureRecognizer.java
! src/java.desktop/share/classes/java/awt/event/ActionEvent.java
! src/java.desktop/share/classes/java/awt/event/AdjustmentEvent.java
! src/java.desktop/share/classes/java/awt/event/ComponentEvent.java
! src/java.desktop/share/classes/java/awt/event/ContainerEvent.java
! src/java.desktop/share/classes/java/awt/event/FocusEvent.java
! src/java.desktop/share/classes/java/awt/event/HierarchyEvent.java
! src/java.desktop/share/classes/java/awt/event/InputEvent.java
! src/java.desktop/share/classes/java/awt/event/InputMethodEvent.java
! src/java.desktop/share/classes/java/awt/event/InvocationEvent.java
! src/java.desktop/share/classes/java/awt/event/ItemEvent.java
! src/java.desktop/share/classes/java/awt/event/KeyEvent.java
! src/java.desktop/share/classes/java/awt/event/MouseEvent.java
! src/java.desktop/share/classes/java/awt/event/MouseWheelEvent.java
! src/java.desktop/share/classes/java/awt/event/PaintEvent.java
! src/java.desktop/share/classes/java/awt/event/TextEvent.java
! src/java.desktop/share/classes/java/awt/event/WindowEvent.java
! src/java.desktop/share/classes/java/awt/font/NumericShaper.java
! src/java.desktop/share/classes/java/awt/font/TextAttribute.java
! src/java.desktop/share/classes/java/awt/font/TransformAttribute.java
! src/java.desktop/share/classes/java/awt/geom/AffineTransform.java
! src/java.desktop/share/classes/java/awt/geom/Arc2D.java
! src/java.desktop/share/classes/java/awt/geom/CubicCurve2D.java
! src/java.desktop/share/classes/java/awt/geom/Ellipse2D.java
! src/java.desktop/share/classes/java/awt/geom/GeneralPath.java
! src/java.desktop/share/classes/java/awt/geom/IllegalPathStateException.java
! src/java.desktop/share/classes/java/awt/geom/Line2D.java
! src/java.desktop/share/classes/java/awt/geom/NoninvertibleTransformException.java
! src/java.desktop/share/classes/java/awt/geom/Path2D.java
! src/java.desktop/share/classes/java/awt/geom/Point2D.java
! src/java.desktop/share/classes/java/awt/geom/QuadCurve2D.java
! src/java.desktop/share/classes/java/awt/geom/Rectangle2D.java
! src/java.desktop/share/classes/java/awt/geom/RoundRectangle2D.java
! src/java.desktop/share/classes/java/awt/image/ImagingOpException.java
! src/java.desktop/share/classes/java/awt/image/RasterFormatException.java
! src/java.desktop/share/classes/java/awt/image/renderable/ParameterBlock.java
! src/java.desktop/share/classes/java/awt/print/PrinterAbortException.java
! src/java.desktop/share/classes/java/awt/print/PrinterException.java
! src/java.desktop/share/classes/java/awt/print/PrinterIOException.java
! src/java.desktop/share/classes/java/beans/IndexedPropertyChangeEvent.java
! src/java.desktop/share/classes/java/beans/IntrospectionException.java
! src/java.desktop/share/classes/java/beans/PropertyChangeEvent.java
! src/java.desktop/share/classes/java/beans/PropertyChangeSupport.java
! src/java.desktop/share/classes/java/beans/PropertyVetoException.java
! src/java.desktop/share/classes/java/beans/VetoableChangeSupport.java
! src/java.desktop/share/classes/java/beans/beancontext/BeanContextChildSupport.java
! src/java.desktop/share/classes/java/beans/beancontext/BeanContextEvent.java
! src/java.desktop/share/classes/java/beans/beancontext/BeanContextMembershipEvent.java
! src/java.desktop/share/classes/java/beans/beancontext/BeanContextServiceAvailableEvent.java
! src/java.desktop/share/classes/java/beans/beancontext/BeanContextServiceRevokedEvent.java
! src/java.desktop/share/classes/java/beans/beancontext/BeanContextServicesSupport.java
! src/java.desktop/share/classes/java/beans/beancontext/BeanContextSupport.java
! src/java.desktop/share/classes/javax/imageio/IIOException.java
! src/java.desktop/share/classes/javax/imageio/metadata/IIOInvalidTreeException.java
! src/java.desktop/share/classes/javax/imageio/metadata/IIOMetadataNode.java
! src/java.desktop/share/classes/javax/imageio/spi/DigraphNode.java
! src/java.desktop/share/classes/javax/print/DocFlavor.java
! src/java.desktop/share/classes/javax/print/MimeType.java
! src/java.desktop/share/classes/javax/print/PrintException.java
! src/java.desktop/share/classes/javax/print/attribute/AttributeSetUtilities.java
! src/java.desktop/share/classes/javax/print/attribute/DateTimeSyntax.java
! src/java.desktop/share/classes/javax/print/attribute/EnumSyntax.java
! src/java.desktop/share/classes/javax/print/attribute/HashAttributeSet.java
! src/java.desktop/share/classes/javax/print/attribute/HashDocAttributeSet.java
! src/java.desktop/share/classes/javax/print/attribute/HashPrintJobAttributeSet.java
! src/java.desktop/share/classes/javax/print/attribute/HashPrintRequestAttributeSet.java
! src/java.desktop/share/classes/javax/print/attribute/HashPrintServiceAttributeSet.java
! src/java.desktop/share/classes/javax/print/attribute/IntegerSyntax.java
! src/java.desktop/share/classes/javax/print/attribute/ResolutionSyntax.java
! src/java.desktop/share/classes/javax/print/attribute/SetOfIntegerSyntax.java
! src/java.desktop/share/classes/javax/print/attribute/Size2DSyntax.java
! src/java.desktop/share/classes/javax/print/attribute/TextSyntax.java
! src/java.desktop/share/classes/javax/print/attribute/URISyntax.java
! src/java.desktop/share/classes/javax/print/attribute/UnmodifiableSetException.java
! src/java.desktop/share/classes/javax/print/attribute/standard/Chromaticity.java
! src/java.desktop/share/classes/javax/print/attribute/standard/ColorSupported.java
! src/java.desktop/share/classes/javax/print/attribute/standard/Compression.java
! src/java.desktop/share/classes/javax/print/attribute/standard/Copies.java
! src/java.desktop/share/classes/javax/print/attribute/standard/CopiesSupported.java
! src/java.desktop/share/classes/javax/print/attribute/standard/DateTimeAtCompleted.java
! src/java.desktop/share/classes/javax/print/attribute/standard/DateTimeAtCreation.java
! src/java.desktop/share/classes/javax/print/attribute/standard/DateTimeAtProcessing.java
! src/java.desktop/share/classes/javax/print/attribute/standard/Destination.java
! src/java.desktop/share/classes/javax/print/attribute/standard/DialogOwner.java
! src/java.desktop/share/classes/javax/print/attribute/standard/DialogTypeSelection.java
! src/java.desktop/share/classes/javax/print/attribute/standard/DocumentName.java
! src/java.desktop/share/classes/javax/print/attribute/standard/Fidelity.java
! src/java.desktop/share/classes/javax/print/attribute/standard/Finishings.java
! src/java.desktop/share/classes/javax/print/attribute/standard/JobHoldUntil.java
! src/java.desktop/share/classes/javax/print/attribute/standard/JobImpressions.java
! src/java.desktop/share/classes/javax/print/attribute/standard/JobImpressionsCompleted.java
! src/java.desktop/share/classes/javax/print/attribute/standard/JobImpressionsSupported.java
! src/java.desktop/share/classes/javax/print/attribute/standard/JobKOctets.java
! src/java.desktop/share/classes/javax/print/attribute/standard/JobKOctetsProcessed.java
! src/java.desktop/share/classes/javax/print/attribute/standard/JobKOctetsSupported.java
! src/java.desktop/share/classes/javax/print/attribute/standard/JobMediaSheets.java
! src/java.desktop/share/classes/javax/print/attribute/standard/JobMediaSheetsCompleted.java
! src/java.desktop/share/classes/javax/print/attribute/standard/JobMediaSheetsSupported.java
! src/java.desktop/share/classes/javax/print/attribute/standard/JobMessageFromOperator.java
! src/java.desktop/share/classes/javax/print/attribute/standard/JobName.java
! src/java.desktop/share/classes/javax/print/attribute/standard/JobOriginatingUserName.java
! src/java.desktop/share/classes/javax/print/attribute/standard/JobPriority.java
! src/java.desktop/share/classes/javax/print/attribute/standard/JobPrioritySupported.java
! src/java.desktop/share/classes/javax/print/attribute/standard/JobSheets.java
! src/java.desktop/share/classes/javax/print/attribute/standard/JobState.java
! src/java.desktop/share/classes/javax/print/attribute/standard/JobStateReason.java
! src/java.desktop/share/classes/javax/print/attribute/standard/JobStateReasons.java
! src/java.desktop/share/classes/javax/print/attribute/standard/Media.java
! src/java.desktop/share/classes/javax/print/attribute/standard/MediaName.java
! src/java.desktop/share/classes/javax/print/attribute/standard/MediaPrintableArea.java
! src/java.desktop/share/classes/javax/print/attribute/standard/MediaSize.java
! src/java.desktop/share/classes/javax/print/attribute/standard/MediaSizeName.java
! src/java.desktop/share/classes/javax/print/attribute/standard/MediaTray.java
! src/java.desktop/share/classes/javax/print/attribute/standard/MultipleDocumentHandling.java
! src/java.desktop/share/classes/javax/print/attribute/standard/NumberOfDocuments.java
! src/java.desktop/share/classes/javax/print/attribute/standard/NumberOfInterveningJobs.java
! src/java.desktop/share/classes/javax/print/attribute/standard/NumberUp.java
! src/java.desktop/share/classes/javax/print/attribute/standard/NumberUpSupported.java
! src/java.desktop/share/classes/javax/print/attribute/standard/OrientationRequested.java
! src/java.desktop/share/classes/javax/print/attribute/standard/OutputDeviceAssigned.java
! src/java.desktop/share/classes/javax/print/attribute/standard/PDLOverrideSupported.java
! src/java.desktop/share/classes/javax/print/attribute/standard/PageRanges.java
! src/java.desktop/share/classes/javax/print/attribute/standard/PagesPerMinute.java
! src/java.desktop/share/classes/javax/print/attribute/standard/PagesPerMinuteColor.java
! src/java.desktop/share/classes/javax/print/attribute/standard/PresentationDirection.java
! src/java.desktop/share/classes/javax/print/attribute/standard/PrintQuality.java
! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterInfo.java
! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterIsAcceptingJobs.java
! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterLocation.java
! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterMakeAndModel.java
! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterMessageFromOperator.java
! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterMoreInfo.java
! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterMoreInfoManufacturer.java
! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterName.java
! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterResolution.java
! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterState.java
! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterStateReason.java
! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterStateReasons.java
! src/java.desktop/share/classes/javax/print/attribute/standard/PrinterURI.java
! src/java.desktop/share/classes/javax/print/attribute/standard/QueuedJobCount.java
! src/java.desktop/share/classes/javax/print/attribute/standard/ReferenceUriSchemesSupported.java
! src/java.desktop/share/classes/javax/print/attribute/standard/RequestingUserName.java
! src/java.desktop/share/classes/javax/print/attribute/standard/Severity.java
! src/java.desktop/share/classes/javax/print/attribute/standard/SheetCollate.java
! src/java.desktop/share/classes/javax/print/attribute/standard/Sides.java
! src/java.desktop/share/classes/javax/print/event/PrintEvent.java
! src/java.desktop/share/classes/javax/print/event/PrintJobAttributeEvent.java
! src/java.desktop/share/classes/javax/print/event/PrintJobEvent.java
! src/java.desktop/share/classes/javax/print/event/PrintServiceAttributeEvent.java
! src/java.desktop/share/classes/javax/sound/midi/InvalidMidiDataException.java
! src/java.desktop/share/classes/javax/sound/midi/MidiUnavailableException.java
! src/java.desktop/share/classes/javax/sound/sampled/AudioPermission.java
! src/java.desktop/share/classes/javax/sound/sampled/LineEvent.java
! src/java.desktop/share/classes/javax/sound/sampled/LineUnavailableException.java
! src/java.desktop/share/classes/javax/sound/sampled/UnsupportedAudioFileException.java
! src/java.desktop/share/classes/javax/swing/AbstractAction.java
! src/java.desktop/share/classes/javax/swing/ActionMap.java
! src/java.desktop/share/classes/javax/swing/ActionPropertyChangeListener.java
! src/java.desktop/share/classes/javax/swing/CellRendererPane.java
! src/java.desktop/share/classes/javax/swing/ImageIcon.java
! src/java.desktop/share/classes/javax/swing/InputMap.java
! src/java.desktop/share/classes/javax/swing/JButton.java
! src/java.desktop/share/classes/javax/swing/JCheckBox.java
! src/java.desktop/share/classes/javax/swing/JCheckBoxMenuItem.java
! src/java.desktop/share/classes/javax/swing/JColorChooser.java
! src/java.desktop/share/classes/javax/swing/JComboBox.java
! src/java.desktop/share/classes/javax/swing/JComponent.java
! src/java.desktop/share/classes/javax/swing/JDesktopPane.java
! src/java.desktop/share/classes/javax/swing/JEditorPane.java
! src/java.desktop/share/classes/javax/swing/JFileChooser.java
! src/java.desktop/share/classes/javax/swing/JFormattedTextField.java
! src/java.desktop/share/classes/javax/swing/JInternalFrame.java
! src/java.desktop/share/classes/javax/swing/JLabel.java
! src/java.desktop/share/classes/javax/swing/JLayer.java
! src/java.desktop/share/classes/javax/swing/JList.java
! src/java.desktop/share/classes/javax/swing/JMenu.java
! src/java.desktop/share/classes/javax/swing/JMenuBar.java
! src/java.desktop/share/classes/javax/swing/JMenuItem.java
! src/java.desktop/share/classes/javax/swing/JOptionPane.java
! src/java.desktop/share/classes/javax/swing/JPanel.java
! src/java.desktop/share/classes/javax/swing/JPasswordField.java
! src/java.desktop/share/classes/javax/swing/JPopupMenu.java
! src/java.desktop/share/classes/javax/swing/JProgressBar.java
! src/java.desktop/share/classes/javax/swing/JRadioButton.java
! src/java.desktop/share/classes/javax/swing/JRadioButtonMenuItem.java
! src/java.desktop/share/classes/javax/swing/JScrollBar.java
! src/java.desktop/share/classes/javax/swing/JScrollPane.java
! src/java.desktop/share/classes/javax/swing/JSeparator.java
! src/java.desktop/share/classes/javax/swing/JSlider.java
! src/java.desktop/share/classes/javax/swing/JSpinner.java
! src/java.desktop/share/classes/javax/swing/JSplitPane.java
! src/java.desktop/share/classes/javax/swing/JTabbedPane.java
! src/java.desktop/share/classes/javax/swing/JTable.java
! src/java.desktop/share/classes/javax/swing/JTextArea.java
! src/java.desktop/share/classes/javax/swing/JTextField.java
! src/java.desktop/share/classes/javax/swing/JTextPane.java
! src/java.desktop/share/classes/javax/swing/JToggleButton.java
! src/java.desktop/share/classes/javax/swing/JToolBar.java
! src/java.desktop/share/classes/javax/swing/JToolTip.java
! src/java.desktop/share/classes/javax/swing/JTree.java
! src/java.desktop/share/classes/javax/swing/KeyStroke.java
! src/java.desktop/share/classes/javax/swing/LayoutFocusTraversalPolicy.java
! src/java.desktop/share/classes/javax/swing/LegacyGlueFocusTraversalPolicy.java
! src/java.desktop/share/classes/javax/swing/Timer.java
! src/java.desktop/share/classes/javax/swing/event/EventListenerList.java
! src/java.desktop/share/classes/javax/swing/event/SwingPropertyChangeSupport.java
! src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java
! src/java.desktop/share/classes/javax/swing/table/JTableHeader.java
! src/java.desktop/share/classes/javax/swing/text/AbstractDocument.java
! src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java
! src/java.desktop/share/classes/javax/swing/text/DefaultStyledDocument.java
! src/java.desktop/share/classes/javax/swing/text/GapContent.java
! src/java.desktop/share/classes/javax/swing/text/InternationalFormatter.java
! src/java.desktop/share/classes/javax/swing/text/JTextComponent.java
! src/java.desktop/share/classes/javax/swing/text/MaskFormatter.java
! src/java.desktop/share/classes/javax/swing/text/SimpleAttributeSet.java
! src/java.desktop/share/classes/javax/swing/text/StyleContext.java
! src/java.desktop/share/classes/javax/swing/text/html/CSS.java
! src/java.desktop/share/classes/javax/swing/text/html/HTML.java
! src/java.desktop/share/classes/javax/swing/text/html/parser/ParserDelegator.java
! src/java.desktop/share/classes/javax/swing/tree/DefaultMutableTreeNode.java
! src/java.desktop/share/classes/javax/swing/tree/DefaultTreeModel.java
! src/java.desktop/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java
! src/java.desktop/share/classes/sun/awt/CausedFocusEvent.java
! src/java.desktop/share/classes/sun/awt/EmbeddedFrame.java
! src/java.desktop/share/classes/sun/awt/im/CompositionArea.java
! src/java.desktop/share/classes/sun/awt/im/InputMethodJFrame.java
! src/java.desktop/share/classes/sun/awt/im/SimpleInputMethodWindow.java
! src/java.desktop/share/classes/sun/awt/shell/DefaultShellFolder.java
! src/java.desktop/share/classes/sun/awt/shell/ShellFolder.java
! src/java.desktop/share/classes/sun/font/FontDesignMetrics.java
! src/java.desktop/share/classes/sun/print/CustomMediaSizeName.java
! src/java.desktop/share/classes/sun/print/CustomMediaTray.java
! src/java.desktop/share/classes/sun/print/PrinterJobWrapper.java
! src/java.desktop/share/classes/sun/print/SunAlternateMedia.java
! src/java.desktop/share/classes/sun/swing/PrintColorUIResource.java
! src/java.desktop/unix/classes/sun/awt/X11/XMouseDragGestureRecognizer.java
! src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolder2.java
! src/java.desktop/windows/classes/sun/awt/windows/WMouseDragGestureRecognizer.java

Changeset: e3b548a6
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2021-01-15 01:58:36 +0000
URL:       https://git.openjdk.java.net/amber/commit/e3b548a6

8257736: InputStream from BodyPublishers.ofInputStream() leaks when IOE happens

Reviewed-by: dfuchs, chegar

! src/java.net.http/share/classes/jdk/internal/net/http/RequestPublishers.java
+ test/jdk/java/net/httpclient/StreamCloseTest.java

Changeset: 90960c5f
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2021-01-15 02:47:30 +0000
URL:       https://git.openjdk.java.net/amber/commit/90960c5f

8252657: JVMTI agent is not unloaded when Agent_OnAttach is failed

Reviewed-by: dholmes, sspitsyn

! src/hotspot/share/prims/jvmti.xml
! src/hotspot/share/prims/jvmtiExport.cpp
! test/hotspot/jtreg/serviceability/dcmd/jvmti/AttachFailed/AttachReturnError.java

Changeset: 0148adf2
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
Date:      2021-01-14 17:18:44 +0000
URL:       https://git.openjdk.java.net/amber/commit/0148adf2

8255120: C2: assert(outer->outcnt() >= phis + 2 && outer->outcnt() <= phis + 2 + stores + 1) failed: only phis

Reviewed-by: thartmann

! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/loopnode.hpp
! test/hotspot/jtreg/ProblemList.txt

Changeset: 4307fa68
Author:    Erik Gahlin <egahlin at openjdk.org>
Date:      2021-01-14 21:26:13 +0000
URL:       https://git.openjdk.java.net/amber/commit/4307fa68

8253505: JFR: onFlush invoked out of order with a sorted event stream

Reviewed-by: mgronlun

! src/jdk.jfr/share/classes/jdk/jfr/consumer/RecordingFile.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/ChunkParser.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/Dispatcher.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventDirectoryStream.java
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/EventFileStream.java

Changeset: d701babb
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
Date:      2021-01-15 03:10:55 +0000
URL:       https://git.openjdk.java.net/amber/commit/d701babb

Merge

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java
! test/hotspot/jtreg/ProblemList.txt
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/jdk.jfr/share/classes/jdk/jfr/internal/consumer/AbstractEventStream.java
! test/hotspot/jtreg/ProblemList.txt

Changeset: 2c8e337d
Author:    Tagir F. Valeev <tvaleev at openjdk.org>
Date:      2021-01-15 04:11:31 +0000
URL:       https://git.openjdk.java.net/amber/commit/2c8e337d

8259622: TreeMap.computeIfAbsent deviates from spec

Reviewed-by: smarks

! src/java.base/share/classes/java/util/TreeMap.java
! test/jdk/java/util/Map/InPlaceOpsCollisions.java

Changeset: 6d4a593f
Author:    Richard Reingruber <rrich at openjdk.org>
Date:      2021-01-15 07:39:38 +0000
URL:       https://git.openjdk.java.net/amber/commit/6d4a593f

8259627: Potential memory leaks in JVMTI after JDK-8227745

Reviewed-by: shade, stuefe, dholmes, sspitsyn

! src/hotspot/share/prims/jvmtiEnv.cpp

Changeset: b01a15e4
Author:    K Suman Rajkumaar <70650887+skodanda at users.noreply.github.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
Date:      2021-01-15 09:40:31 +0000
URL:       https://git.openjdk.java.net/amber/commit/b01a15e4

8258884: [TEST_BUG] Convert applet-based test open/test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java to a regular java test

Reviewed-by: aivanov, serb

- test/jdk/javax/swing/JMenuItem/8031573/bug8031573.html
! test/jdk/javax/swing/JMenuItem/8031573/bug8031573.java

Changeset: 0ec2c969
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2021-01-15 12:45:22 +0000
URL:       https://git.openjdk.java.net/amber/commit/0ec2c969

8259820: JShell does not handle -source 8 properly

Reviewed-by: sundar

! src/jdk.jshell/share/classes/jdk/jshell/TaskFactory.java
+ test/langtools/jdk/jshell/SourceLevelTest.java

Changeset: 707bce08
Author:    Conor Cleary <ccleary at openjdk.org>
Committer: Chris Hegarty <chegar at openjdk.org>
Date:      2021-01-15 14:06:38 +0000
URL:       https://git.openjdk.java.net/amber/commit/707bce08

8257212: (bf spec) Clarify byte order of the buffer returned by CharBuffer.subsequence(int,int)

Reviewed-by: chegar, bpb, alanb

! src/java.base/share/classes/java/nio/X-Buffer.java.template
! test/jdk/java/nio/Buffer/Order-X.java.template
! test/jdk/java/nio/Buffer/OrderChar.java
! test/jdk/java/nio/Buffer/OrderDouble.java
! test/jdk/java/nio/Buffer/OrderFloat.java
! test/jdk/java/nio/Buffer/OrderInt.java
! test/jdk/java/nio/Buffer/OrderLong.java
! test/jdk/java/nio/Buffer/OrderShort.java

Changeset: bbac91a4
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2021-01-15 14:51:34 +0000
URL:       https://git.openjdk.java.net/amber/commit/bbac91a4

8257959: Add gtest run with -XX:+UseLargePages

Reviewed-by: lfoltan, tschatzl

! test/hotspot/jtreg/TEST.groups
+ test/hotspot/jtreg/gtest/LargePageGtests.java

Changeset: bcf20a0d
Author:    Jatin Bhateja <jbhateja at openjdk.org>
Date:      2021-01-15 15:03:04 +0000
URL:       https://git.openjdk.java.net/amber/commit/bcf20a0d

8259777: Incorrect predication condition generated by ADLC

Reviewed-by: vlivanov

! src/hotspot/share/adlc/formssel.cpp
! src/hotspot/share/adlc/formssel.hpp

Changeset: eb7fa006
Author:    liach <liach at users.noreply.github.com>
Committer: Hannes Walln?fer <hannesw at openjdk.org>
Date:      2021-01-15 15:12:34 +0000
URL:       https://git.openjdk.java.net/amber/commit/eb7fa006

8259216: javadoc omits method receiver for any nested type annotation

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java
! test/langtools/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java

Changeset: b78cd633
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2021-01-15 16:53:33 +0000
URL:       https://git.openjdk.java.net/amber/commit/b78cd633

8259846: [BACKOUT] JDK-8259278 Optimize Vector API slice and unslice operations

Reviewed-by: vlivanov, psandoz

! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/cpu/x86/stubRoutines_x86.cpp
! src/hotspot/cpu/x86/stubRoutines_x86.hpp
! src/hotspot/cpu/x86/x86.ad
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template

Changeset: 360c7226
Author:    Phil Race <prr at openjdk.org>
Date:      2021-01-15 17:02:05 +0000
URL:       https://git.openjdk.java.net/amber/commit/360c7226

8259729: Missed JNFInstanceOf -> IsInstanceOf conversion

Reviewed-by: serb, psadhukhan, kizune

! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m

Changeset: 5855d52a
Author:    Phil Race <prr at openjdk.org>
Date:      2021-01-15 17:04:53 +0000
URL:       https://git.openjdk.java.net/amber/commit/5855d52a

8259651: [macOS] Replace JNF_COCOA_ENTER/EXIT macros

Reviewed-by: serb

! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTEvent.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTSurfaceLayers.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CCursorManager.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CDataTransferer.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CDesktopPeer.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CDragSource.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CDragSourceContextPeer.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CDropTarget.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CDropTargetContextPeer.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CFRetainedResource.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CFileDialog.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsDevice.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsEnv.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CImage.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CInputMethod.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CMenu.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CMenuBar.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CMenuItem.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CPopupMenu.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CSystemColors.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CTextPipe.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CTrayIcon.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CWrapper.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/ImageSurfaceData.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/PrintModel.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterSurfaceData.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzRenderer.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.h
! src/java.desktop/macosx/native/libawt_lwawt/awt/QuartzSurfaceData.m
! src/java.desktop/macosx/native/libawt_lwawt/font/AWTFont.m
! src/java.desktop/macosx/native/libawt_lwawt/font/AWTStrike.m
! src/java.desktop/macosx/native/libawt_lwawt/font/CCharToGlyphMapper.m
! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLGraphicsConfig.m
! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLLayer.m
! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLSurfaceData.m
! src/java.desktop/macosx/native/libosx/CFileManager.m
! src/java.desktop/macosx/native/libosxapp/JNIUtilities.h
! src/java.desktop/macosx/native/libosxui/AquaFileView.m
! src/java.desktop/macosx/native/libosxui/AquaNativeResources.m
! src/java.desktop/macosx/native/libosxui/ScreenMenu.m

Changeset: 27a39c8d
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Peter Levart <plevart at openjdk.org>
Date:      2021-01-15 17:38:08 +0000
URL:       https://git.openjdk.java.net/amber/commit/27a39c8d

8193031: Collections.addAll is likely to perform worse than Collection.addAll

Reviewed-by: plevart

! src/java.base/share/classes/java/util/Collections.java

Changeset: 9aa5672a
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2021-01-15 17:47:33 +0000
URL:       https://git.openjdk.java.net/amber/commit/9aa5672a

8259068: Streamline class loader locking

Reviewed-by: dcubed, iklam

! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/runtime/synchronizer.cpp
! src/hotspot/share/runtime/synchronizer.hpp

Changeset: fe84ecd5
Author:    Kiran Sidhartha Ravikumar <kravikumar at openjdk.org>
Date:      2021-01-15 19:14:08 +0000
URL:       https://git.openjdk.java.net/amber/commit/fe84ecd5

8259048: (tz) Upgrade time-zone data to tzdata2020f

Reviewed-by: naoto, erikj

! make/data/tzdata/VERSION
! make/data/tzdata/africa
! make/data/tzdata/asia
! make/data/tzdata/australasia
! make/data/tzdata/backward
! make/data/tzdata/etcetera
! make/data/tzdata/europe
! make/data/tzdata/leapseconds
! make/data/tzdata/northamerica
! make/data/tzdata/zone.tab

Changeset: d7d34dd9
Author:    Leonid Mesnik <lmesnik at openjdk.org>
Date:      2021-01-15 19:33:23 +0000
URL:       https://git.openjdk.java.net/amber/commit/d7d34dd9

8259799: vmTestbase/nsk/jvmti/Breakpoint/breakpoint001 is incorrect

Reviewed-by: iignatyev, sspitsyn, cjplummer

! test/hotspot/jtreg/vmTestbase/nsk/jvmti/Breakpoint/breakpoint001/breakpoint001.cpp

Changeset: d63388c0
Author:    Alex Menkov <amenkov at openjdk.org>
Date:      2021-01-15 22:40:47 +0000
URL:       https://git.openjdk.java.net/amber/commit/d63388c0

8259266: com/sun/jdi/JdbOptions.java failed with "RuntimeException: 'prop[boo] = >foo 2<' missing from stdout/stderr"

Reviewed-by: cjplummer, sspitsyn

! src/jdk.jdi/share/classes/com/sun/tools/example/debug/tty/VMConnection.java

Changeset: e85892bf
Author:    Jaroslav Bachorik <jbachorik at openjdk.org>
Date:      2021-01-15 15:12:03 +0000
URL:       https://git.openjdk.java.net/amber/commit/e85892bf

8258396: SIGILL in jdk.jfr.internal.PlatformRecorder.rotateDisk()

Reviewed-by: egahlin
Backport-of: a06cea50a5ea04fb0399d7ea3f6a2a20d9b4d254

! src/hotspot/share/jfr/recorder/storage/jfrStorage.cpp

Changeset: 536082db
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
Date:      2021-01-16 02:46:13 +0000
URL:       https://git.openjdk.java.net/amber/commit/536082db

Merge


Changeset: 90c73d05
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2021-01-16 05:17:10 +0000
URL:       https://git.openjdk.java.net/amber/commit/90c73d05

8259569: gtest os.dll_address_to_function_and_library_name_vm fails

Reviewed-by: dcubed

! test/hotspot/gtest/runtime/test_os.cpp

Changeset: bbb93ca3
Author:    Pankaj Bansal <pbansal at openjdk.org>
Date:      2021-01-16 07:52:04 +0000
URL:       https://git.openjdk.java.net/amber/commit/bbb93ca3

8256126: Create implementation for NSAccessibilityImage protocol peer

Reviewed-by: kizune, serb

! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m
= src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ImageAccessibility.h
+ src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ImageAccessibility.m

Changeset: afd3f78a
Author:    Sebastian Stenzel <sebastian.stenzel at skymatic.de>
Committer: Alan Bateman <alanb at openjdk.org>
Date:      2021-01-16 08:36:05 +0000
URL:       https://git.openjdk.java.net/amber/commit/afd3f78a

8030048: (fs) Support UserDefinedFileAttributeView/extended attributes on OS X / HFS+

Reviewed-by: alanb

! src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java
! src/java.base/macosx/classes/sun/nio/fs/BsdFileSystem.java
! src/java.base/macosx/classes/sun/nio/fs/BsdFileSystemProvider.java
! src/java.base/macosx/classes/sun/nio/fs/BsdNativeDispatcher.java
= src/java.base/macosx/classes/sun/nio/fs/BsdUserDefinedFileAttributeView.java
! src/java.base/macosx/native/libnio/fs/BsdNativeDispatcher.c
! src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template

Changeset: 6d6a23e3
Author:    Andy Herrick <herrick at openjdk.org>
Date:      2021-01-16 14:37:19 +0000
URL:       https://git.openjdk.java.net/amber/commit/6d6a23e3

8259062: Remove MacAppStoreBundler

Reviewed-by: asemenyuk, almatvee, kizune

- src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppStoreBundler.java
! src/jdk.jpackage/macosx/classes/module-info.java.extra

Changeset: c3bdbf9d
Author:    Andy Herrick <herrick at openjdk.org>
Date:      2021-01-16 14:38:10 +0000
URL:       https://git.openjdk.java.net/amber/commit/c3bdbf9d

8259238: Clean up Log.java and remove usage of non-final static variables.

Reviewed-by: asemenyuk, almatvee, kizune

! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Arguments.java
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/Log.java
! src/jdk.jpackage/share/classes/jdk/jpackage/main/Main.java

Changeset: da4cf05d
Author:    Andy Herrick <herrick at openjdk.org>
Date:      2021-01-16 14:38:57 +0000
URL:       https://git.openjdk.java.net/amber/commit/da4cf05d

8258755: jpackage: Invalid 32-bit exe when building app-image

Reviewed-by: asemenyuk, almatvee, kizune

! src/jdk.jpackage/share/native/applauncher/JvmLauncher.cpp
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixPipeline.java
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WixSourcesBuilder.java

Changeset: 5f2e280c
Author:    Alan Bateman <alanb at openjdk.org>
Date:      2021-01-17 18:13:08 +0000
URL:       https://git.openjdk.java.net/amber/commit/5f2e280c

8259865: (fs) test/jdk/java/nio/file/attribute/UserDefinedFileAttributeView/Basic.java failing on macOS 10.13

Reviewed-by: dcubed

! src/java.base/macosx/classes/sun/nio/fs/BsdFileStore.java

Changeset: 5dc5d940
Author:    Alexander Zuev <kizune at openjdk.org>
Date:      2021-01-17 20:39:22 +0000
URL:       https://git.openjdk.java.net/amber/commit/5dc5d940

8256110: Create implementation for NSAccessibilityStepper protocol

Reviewed-by: pbansal, serb

! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/ButtonAccessibility.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.h
! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m
+ src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SpinboxAccessibility.h
+ src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/SpinboxAccessibility.m

Changeset: 68cf65d2
Author:    Valerie Peng <valeriep at openjdk.org>
Date:      2021-01-18 02:26:17 +0000
URL:       https://git.openjdk.java.net/amber/commit/68cf65d2

8023980: JCE doesn't provide any class to handle RSA private key in PKCS#1

Reviewed-by: weijun

! src/java.base/share/classes/sun/security/rsa/RSAKeyFactory.java
! src/java.base/share/classes/sun/security/rsa/RSAPrivateCrtKeyImpl.java
! src/java.base/share/classes/sun/security/rsa/RSAPublicKeyImpl.java
! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11RSAKeyFactory.java
! test/jdk/sun/security/pkcs11/rsa/TestKeyFactory.java
! test/jdk/sun/security/rsa/TestKeyFactory.java

Changeset: 3f19ef63
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2021-01-18 07:20:12 +0000
URL:       https://git.openjdk.java.net/amber/commit/3f19ef63

8202880: Test javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java fails

Reviewed-by: aivanov

! test/jdk/ProblemList.txt
! test/jdk/javax/swing/JPopupMenu/8075063/ContextMenuScrollTest.java

Changeset: 917f7e9a
Author:    Alexander Zuev <kizune at openjdk.org>
Date:      2021-01-18 08:23:55 +0000
URL:       https://git.openjdk.java.net/amber/commit/917f7e9a

8259650: javax/swing/JComponent/7154030/bug7154030.java still fails with "Exception: Failed to hide opaque button"

Reviewed-by: jdv

! test/jdk/javax/swing/JComponent/7154030/bug7154030.java

Changeset: e93f08e2
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
Date:      2021-01-18 08:33:33 +0000
URL:       https://git.openjdk.java.net/amber/commit/e93f08e2

8074101: Add verification that all tasks are actually claimed during roots processing

Reviewed-by: kbarrett, tschatzl

! src/hotspot/share/gc/g1/g1RootProcessor.cpp
! src/hotspot/share/gc/g1/g1RootProcessor.hpp
! src/hotspot/share/gc/serial/serialHeap.cpp
! src/hotspot/share/gc/shared/genCollectedHeap.cpp
! src/hotspot/share/gc/shared/genCollectedHeap.hpp
! src/hotspot/share/gc/shared/workgroup.cpp
! src/hotspot/share/gc/shared/workgroup.hpp
! src/hotspot/share/runtime/safepoint.cpp

Changeset: ff275b37
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-18 10:28:14 +0000
URL:       https://git.openjdk.java.net/amber/commit/ff275b37

8259403: Zero: crash with NULL MethodHandle receiver

Reviewed-by: coleenp

! src/hotspot/cpu/zero/methodHandles_zero.cpp
! src/hotspot/cpu/zero/methodHandles_zero.hpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp
! src/hotspot/share/interpreter/interpreterRuntime.hpp

Changeset: 61292be7
Author:    Laurent Bourg?s <lbourges at openjdk.org>
Date:      2021-01-18 11:34:10 +0000
URL:       https://git.openjdk.java.net/amber/commit/61292be7

8259681: Remove the Marlin rendering engine (single-precision)

Reviewed-by: serb

! src/java.desktop/share/classes/sun/java2d/marlin/CollinearSimplifier.java
! src/java.desktop/share/classes/sun/java2d/marlin/Curve.java
- src/java.desktop/share/classes/sun/java2d/marlin/DCollinearSimplifier.java
- src/java.desktop/share/classes/sun/java2d/marlin/DCurve.java
- src/java.desktop/share/classes/sun/java2d/marlin/DDasher.java
- src/java.desktop/share/classes/sun/java2d/marlin/DHelpers.java
! src/java.desktop/share/classes/sun/java2d/marlin/DMarlinRenderingEngine.java
- src/java.desktop/share/classes/sun/java2d/marlin/DPathSimplifier.java
- src/java.desktop/share/classes/sun/java2d/marlin/DRenderer.java
- src/java.desktop/share/classes/sun/java2d/marlin/DRendererContext.java
- src/java.desktop/share/classes/sun/java2d/marlin/DStroker.java
- src/java.desktop/share/classes/sun/java2d/marlin/DTransformingPathConsumer2D.java
! src/java.desktop/share/classes/sun/java2d/marlin/Dasher.java
- src/java.desktop/share/classes/sun/java2d/marlin/FloatArrayCache.java
! src/java.desktop/share/classes/sun/java2d/marlin/Helpers.java
- src/java.desktop/share/classes/sun/java2d/marlin/IRendererContext.java
! src/java.desktop/share/classes/sun/java2d/marlin/MarlinCache.java
- src/java.desktop/share/classes/sun/java2d/marlin/MarlinRenderer.java
- src/java.desktop/share/classes/sun/java2d/marlin/MarlinRenderingEngine.java
! src/java.desktop/share/classes/sun/java2d/marlin/MarlinTileGenerator.java
! src/java.desktop/share/classes/sun/java2d/marlin/PathSimplifier.java
! src/java.desktop/share/classes/sun/java2d/marlin/Renderer.java
! src/java.desktop/share/classes/sun/java2d/marlin/RendererContext.java
! src/java.desktop/share/classes/sun/java2d/marlin/Stroker.java
! src/java.desktop/share/classes/sun/java2d/marlin/TransformingPathConsumer2D.java
! src/java.desktop/share/classes/sun/java2d/marlin/Version.java
! test/jdk/sun/java2d/marlin/ClipShapeTest.java
! test/jdk/sun/java2d/marlin/StrokedLinePerf.java

Changeset: db9c114d
Author:    Jaikiran Pai <jpai at openjdk.org>
Date:      2021-01-18 11:53:22 +0000
URL:       https://git.openjdk.java.net/amber/commit/db9c114d

7146776: deadlock between URLStreamHandler.getHostAddress and file.Handler.openconnection

Reviewed-by: alanb, chegar

! src/java.base/share/classes/java/net/URL.java
! src/java.base/share/classes/java/net/URLStreamHandler.java

Changeset: e60c9926
Author:    Roman Kennke <rkennke at openjdk.org>
Date:      2021-01-18 15:29:54 +0000
URL:       https://git.openjdk.java.net/amber/commit/e60c9926

8259849: Shenandoah: Rename store-val to IU-barrier

Reviewed-by: zgu, shade

! src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp
! src/hotspot/cpu/x86/gc/shenandoah/c1/shenandoahBarrierSetC1_x86.cpp
! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.hpp
! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp
! src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.hpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.hpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp
! src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.hpp
! src/hotspot/share/gc/shenandoah/mode/shenandoahIUMode.cpp
! src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp
! src/hotspot/share/gc/shenandoah/mode/shenandoahSATBMode.cpp
! src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSetClone.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp
! src/hotspot/share/opto/classes.hpp
! test/hotspot/jtreg/gc/shenandoah/options/TestSelectiveBarrierFlags.java
! test/hotspot/jtreg/gc/shenandoah/options/TestWrongBarrierDisable.java
! test/hotspot/jtreg/gc/shenandoah/options/TestWrongBarrierEnable.java

Changeset: 061ffc47
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2021-01-18 16:14:07 +0000
URL:       https://git.openjdk.java.net/amber/commit/061ffc47

8249245: assert(((((JfrTraceIdBits::load(klass)) & ((JfrTraceIdEpoch::this_epoch_method_and_class_bits()))) != 0))) failed: invariant

Reviewed-by: egahlin

! src/hotspot/share/jfr/recorder/checkpoint/types/traceid/jfrTraceIdLoadBarrier.inline.hpp

Changeset: 6b4732fe
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-18 18:42:05 +0000
URL:       https://git.openjdk.java.net/amber/commit/6b4732fe

8259679: GitHub actions should use MSVC 14.28

Reviewed-by: ihse, redestad

! .github/workflows/submit.yml

Changeset: 533a2d39
Author:    Xin Liu <xliu at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
Date:      2021-01-18 22:34:05 +0000
URL:       https://git.openjdk.java.net/amber/commit/533a2d39

8258961: move some fields of SafePointNode from public to protected

Reviewed-by: thartmann, kvn

! src/hotspot/share/gc/shared/c2/barrierSetC2.cpp
! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/callnode.hpp
! src/hotspot/share/opto/generateOptoStub.cpp
! src/hotspot/share/opto/parse1.cpp

Changeset: 492bebc7
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2021-01-19 04:32:51 +0000
URL:       https://git.openjdk.java.net/amber/commit/492bebc7

8258004: Remove unnecessary inclusion of vm_version.hpp

Reviewed-by: dholmes, stefank

! src/hotspot/cpu/ppc/assembler_ppc.inline.hpp
! src/hotspot/cpu/ppc/c1_LIRAssembler_ppc.cpp
! src/hotspot/cpu/ppc/c1_LIRGenerator_ppc.cpp
! src/hotspot/cpu/ppc/c2_MacroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/c2_init_ppc.cpp
! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.cpp
! src/hotspot/cpu/ppc/macroAssembler_ppc.inline.hpp
! src/hotspot/cpu/ppc/stubGenerator_ppc.cpp
! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/c2_init_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/x86.ad
! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp
! src/hotspot/share/asm/assembler.hpp
! src/hotspot/share/c1/c1_Compiler.cpp
! src/hotspot/share/c1/c1_LIR.cpp
! src/hotspot/share/c1/c1_LIRAssembler.cpp
! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp
! src/hotspot/share/jfr/periodic/jfrOSInterface.cpp
! src/hotspot/share/jfr/periodic/jfrPeriodic.cpp
! src/hotspot/share/oops/cpCache.cpp
! src/hotspot/share/prims/jvmtiExport.cpp
! src/hotspot/share/runtime/java.cpp
! src/hotspot/share/runtime/sharedRuntime.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/hotspot/share/services/diagnosticCommand.cpp

Changeset: d5ca3b3f
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2021-01-18 07:54:48 +0000
URL:       https://git.openjdk.java.net/amber/commit/d5ca3b3f

8259641: C2: assert(early->dominates(LCA)) failed: early is high enough

Reviewed-by: chagedorn, thartmann

! src/hotspot/share/opto/loopnode.cpp
+ test/hotspot/jtreg/compiler/loopopts/TestBrokenAntiDependenceWithPhi.java

Changeset: cd25bf2e
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2021-01-18 10:22:16 +0000
URL:       https://git.openjdk.java.net/amber/commit/cd25bf2e

8259574: SIGSEGV in BFSClosure::closure_impl

Reviewed-by: stefank, egahlin

! src/hotspot/share/jfr/leakprofiler/chains/bfsClosure.cpp
! src/hotspot/share/jfr/leakprofiler/chains/rootSetClosure.cpp
! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp

Changeset: bb0821eb
Author:    Alexander Zuev <kizune at openjdk.org>
Date:      2021-01-18 22:12:06 +0000
URL:       https://git.openjdk.java.net/amber/commit/bb0821eb

8258643: [TESTBUG] javax/swing/JComponent/7154030/bug7154030.java failed with "Exception: Failed to hide opaque button"

Reviewed-by: trebari, psadhukhan

! test/jdk/javax/swing/JComponent/7154030/bug7154030.java

Changeset: a1a851b6
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
Date:      2021-01-19 05:43:27 +0000
URL:       https://git.openjdk.java.net/amber/commit/a1a851b6

Merge

! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/loopnode.cpp

Changeset: 14ce8f1a
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2021-01-19 06:44:54 +0000
URL:       https://git.openjdk.java.net/amber/commit/14ce8f1a

8259870: zBarrier.inline.hpp should not include javaClasses.hpp

Reviewed-by: stefank, tschatzl

! src/hotspot/share/gc/z/zBarrier.cpp
! src/hotspot/share/gc/z/zBarrier.hpp
! src/hotspot/share/gc/z/zBarrier.inline.hpp

Changeset: dfee7b8a
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2021-01-19 07:16:02 +0000
URL:       https://git.openjdk.java.net/amber/commit/dfee7b8a

8259511: java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java failed with "RuntimeException: Test failed: 20 failure(s)"

Reviewed-by: jdv

! test/jdk/java/awt/Window/MainKeyWindowTest/TestMainKeyWindow.java
! test/jdk/java/awt/Window/MainKeyWindowTest/libTestMainKeyWindow.c

Changeset: bd81ccfd
Author:    Jie Fu <jiefu at openjdk.org>
Date:      2021-01-19 07:43:53 +0000
URL:       https://git.openjdk.java.net/amber/commit/bd81ccfd

8259957: Build failure without C1 Compiler after JDK-8258004

Reviewed-by: dholmes, shade

! src/hotspot/share/jvmci/vmStructs_jvmci.cpp

Changeset: 139f5d33
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2021-01-19 08:57:44 +0000
URL:       https://git.openjdk.java.net/amber/commit/139f5d33

8259035: Comments for load order of hsdis should be updated

Reviewed-by: thartmann

! src/hotspot/share/compiler/disassembler.cpp

Changeset: a9519c83
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-19 09:38:36 +0000
URL:       https://git.openjdk.java.net/amber/commit/a9519c83

8259924: GitHub actions fail on Linux x86_32 with "Could not configure libc6:i386"

Reviewed-by: dholmes

! .github/workflows/submit.yml

Changeset: 82adfb32
Author:    Harold Seigel <hseigel at openjdk.org>
Date:      2021-01-19 13:44:07 +0000
URL:       https://git.openjdk.java.net/amber/commit/82adfb32

8134540: Much nearly duplicated code for PerfMemory support

Reviewed-by: coleenp, dholmes

! src/hotspot/os/aix/os_aix.inline.hpp
- src/hotspot/os/aix/perfMemory_aix.cpp
! src/hotspot/os/bsd/os_bsd.inline.hpp
- src/hotspot/os/bsd/perfMemory_bsd.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/linux/os_linux.hpp
! src/hotspot/os/linux/os_linux.inline.hpp
! src/hotspot/os/posix/os_posix.inline.hpp
= src/hotspot/os/posix/perfMemory_posix.cpp

Changeset: c0e9c446
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-19 14:39:04 +0000
URL:       https://git.openjdk.java.net/amber/commit/c0e9c446

8259962: Shenandoah: task queue statistics is inconsistent after JDK-8255019

Reviewed-by: zgu

! src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp

Changeset: 5cfb36e7
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2021-01-19 15:27:22 +0000
URL:       https://git.openjdk.java.net/amber/commit/5cfb36e7

8259036: Failed JfrVersionSystem invariant when VM built with -fno-elide-constructors

Reviewed-by: egahlin

! src/hotspot/share/jfr/utilities/jfrConcurrentLinkedListHost.inline.hpp
! src/hotspot/share/jfr/utilities/jfrConcurrentQueue.inline.hpp
! src/hotspot/share/jfr/utilities/jfrRefCountPointer.hpp
! src/hotspot/share/jfr/utilities/jfrVersionSystem.hpp
! src/hotspot/share/jfr/utilities/jfrVersionSystem.inline.hpp

Changeset: 5d8861b0
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2021-01-19 16:56:07 +0000
URL:       https://git.openjdk.java.net/amber/commit/5d8861b0

8259995: Missing comma to separate years in copyright header

Reviewed-by: egahlin

! src/hotspot/share/jfr/utilities/jfrConcurrentLinkedListHost.inline.hpp
! src/hotspot/share/jfr/utilities/jfrVersionSystem.hpp
! src/hotspot/share/jfr/utilities/jfrVersionSystem.inline.hpp

Changeset: 3edf393d
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-19 18:33:18 +0000
URL:       https://git.openjdk.java.net/amber/commit/3edf393d

8259978: PPC64 builds broken after JDK-8258004

Reviewed-by: lucy, iklam

! src/hotspot/cpu/ppc/nativeInst_ppc.hpp
! src/hotspot/share/oops/method.cpp

Changeset: 33dcc00c
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2021-01-19 19:14:30 +0000
URL:       https://git.openjdk.java.net/amber/commit/33dcc00c

8132984: incorrect type for Reference.discovered

Use unbounded wildcard placeholders, plus a new helper to get back to the Reference<T> domain.

Reviewed-by: rkennke, plevart, rriggs, mchung

! src/java.base/share/classes/java/lang/ref/Reference.java

Changeset: a37cd5a3
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2021-01-19 20:01:45 +0000
URL:       https://git.openjdk.java.net/amber/commit/a37cd5a3

8259859: Missing metaspace NMT memory tag

Reviewed-by: iklam

! src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp

Changeset: f7b96d34
Author:    Martin Buchholz <martin at openjdk.org>
Date:      2021-01-19 18:41:08 +0000
URL:       https://git.openjdk.java.net/amber/commit/f7b96d34

8259796: timed CompletableFuture.get may swallow InterruptedException

Reviewed-by: dl, alanb

! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java
! test/jdk/java/util/concurrent/CompletableFuture/SwallowedInterruptedException.java

Changeset: cf25383d
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
Date:      2021-01-19 22:49:44 +0000
URL:       https://git.openjdk.java.net/amber/commit/cf25383d

Merge

! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java
! src/java.base/share/classes/java/util/concurrent/CompletableFuture.java

Changeset: 9f21bb6a
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2021-01-20 07:49:07 +0000
URL:       https://git.openjdk.java.net/amber/commit/9f21bb6a

8259983: do not use uninitialized expand_ms value in G1CollectedHeap::expand_heap_after_young_collection

Reviewed-by: kbarrett, lucy

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp

Changeset: 7c32ffea
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2021-01-20 11:48:27 +0000
URL:       https://git.openjdk.java.net/amber/commit/7c32ffea

8258383: vmTestbase/gc/g1/unloading/tests/unloading_compilation_level[1,2,3] time out without TieredCompilation

Reviewed-by: kvn

! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/loading/ClassLoadingHelper.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_inMemoryCompilation_keep_cl/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_inMemoryCompilation_keep_class/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_inMemoryCompilation_keep_obj/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_keep_cl/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_keep_class/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level1_keep_obj/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_inMemoryCompilation_keep_cl/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_inMemoryCompilation_keep_class/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_inMemoryCompilation_keep_obj/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_keep_cl/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_keep_class/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level2_keep_obj/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_inMemoryCompilation_keep_cl/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_inMemoryCompilation_keep_class/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_inMemoryCompilation_keep_obj/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_keep_cl/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_keep_class/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level3_keep_obj/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_inMemoryCompilation_keep_cl/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_inMemoryCompilation_keep_class/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_inMemoryCompilation_keep_obj/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_keep_cl/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_keep_class/TestDescription.java
! test/hotspot/jtreg/vmTestbase/gc/g1/unloading/tests/unloading_compilation_level4_keep_obj/TestDescription.java

Changeset: 05294802
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Claes Redestad <redestad at openjdk.org>
Date:      2021-01-20 12:02:39 +0000
URL:       https://git.openjdk.java.net/amber/commit/05294802

8259867: Move encoding checks into ZipCoder

Reviewed-by: redestad, lancea

! src/java.base/share/classes/java/util/zip/ZipCoder.java
! src/java.base/share/classes/java/util/zip/ZipFile.java

Changeset: 0b01d692
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2021-01-20 13:11:35 +0000
URL:       https://git.openjdk.java.net/amber/commit/0b01d692

8260005: Shenandoah: Remove unused AlwaysTrueClosure in ShenandoahConcurrentRootScanner::roots_do()

Reviewed-by: shade, rkennke

! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp

Changeset: 70b5b311
Author:    Stanimir Stamenkov <stanio at yahoo.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
Date:      2021-01-20 13:34:52 +0000
URL:       https://git.openjdk.java.net/amber/commit/70b5b311

8257664: HTMLEditorKit: Wrong CSS relative font sizes

Reviewed-by: aivanov, psadhukhan

! src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java
+ test/jdk/javax/swing/text/html/StyleSheet/TestWrongCSSFontSize.java

Changeset: 52ed2aab
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2021-01-20 15:04:28 +0000
URL:       https://git.openjdk.java.net/amber/commit/52ed2aab

8259786: initialize last parameter of getpwuid_r

Reviewed-by: mdoerr, hseigel

! src/hotspot/os/posix/perfMemory_posix.cpp
! src/jdk.security.auth/unix/native/libjaas/Unix.c

Changeset: 69f90b5f
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2021-01-20 15:08:02 +0000
URL:       https://git.openjdk.java.net/amber/commit/69f90b5f

8259843: initialize dli_fname array before calling dll_address_to_library_name

Reviewed-by: lucy, dholmes

! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/share/prims/nativeLookup.cpp
! src/hotspot/share/runtime/frame.cpp

Changeset: 5891509d
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2021-01-20 15:14:48 +0000
URL:       https://git.openjdk.java.net/amber/commit/5891509d

8259947: (fs) Optimize UnixPath.encode implementation

Reviewed-by: chegar, shade, alanb

! src/java.base/macosx/classes/sun/nio/fs/BsdNativeDispatcher.java
! src/java.base/macosx/classes/sun/nio/fs/MacOSXFileSystem.java
! src/java.base/macosx/classes/sun/nio/fs/MacOSXNativeDispatcher.java
! src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java
! src/java.base/unix/classes/sun/nio/fs/UnixPath.java
! test/micro/org/openjdk/bench/java/io/FileOpen.java

Changeset: 07851474
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2021-01-20 16:13:42 +0000
URL:       https://git.openjdk.java.net/amber/commit/07851474

8259949: x86 32-bit build fails when -fcf-protection is passed in the compiler flags

Use -march=i686 instead of -march=i586 if -fcf-protection is passed to the build as CMOV is required

Reviewed-by: erikj

! make/autoconf/flags-cflags.m4

Changeset: 4f11ff32
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2021-01-20 21:41:15 +0000
URL:       https://git.openjdk.java.net/amber/commit/4f11ff32

8259488: Shenandoah: Missing timing tracking for STW CLD root processing

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp

Changeset: 8b95d954
Author:    Hai-May Chao <hchao at openjdk.org>
Committer: Sean Mullan <mullan at openjdk.org>
Date:      2021-01-20 22:23:50 +0000
URL:       https://git.openjdk.java.net/amber/commit/8b95d954

8256895: Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension

Reviewed-by: jnimeh, mullan

! src/java.base/share/classes/sun/security/provider/certpath/OCSPNonceExtension.java
! src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java
! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/LuxTrustCA.java
! test/jdk/security/infra/java/security/cert/CertPathValidator/certification/SSLCA.java
! test/jdk/sun/security/provider/certpath/Extensions/OCSPNonceExtensionTests.java

Changeset: 1f47de5f
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2021-01-20 23:42:29 +0000
URL:       https://git.openjdk.java.net/amber/commit/1f47de5f

8260010: UTF8ZipCoder not thread-safe since JDK-8243469

Reviewed-by: lancea

! src/java.base/share/classes/java/util/zip/ZipCoder.java

Changeset: 27cc62a5
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2021-01-20 23:42:58 +0000
URL:       https://git.openjdk.java.net/amber/commit/27cc62a5

8259911: byteArrayViewVarHandle should throw ArrayIndexOutOfBoundsException

Reviewed-by: jvernee, mchung

! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
! src/java.base/share/classes/java/lang/invoke/X-VarHandleByteArrayView.java.template
! test/jdk/java/lang/invoke/VarHandles/VarHandleBaseTest.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessByte.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessChar.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessDouble.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessFloat.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessInt.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessLong.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessShort.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessString.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsChar.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsDouble.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsFloat.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsInt.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsLong.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestByteArrayAsShort.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessBoolean.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessByte.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessChar.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessDouble.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessFloat.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessInt.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessLong.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessShort.java
! test/jdk/java/lang/invoke/VarHandles/VarHandleTestMethodHandleAccessString.java
! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestAccess.java.template
! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestByteArrayView.java.template
! test/jdk/java/lang/invoke/VarHandles/X-VarHandleTestMethodHandleAccess.java.template

Changeset: 35c9da70
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2021-01-20 23:45:55 +0000
URL:       https://git.openjdk.java.net/amber/commit/35c9da70

8259498: Reduce overhead of MD5 and SHA digests

Reviewed-by: valeriep

! src/java.base/share/classes/sun/security/provider/ByteArrayAccess.java
! src/java.base/share/classes/sun/security/provider/MD4.java
! src/java.base/share/classes/sun/security/provider/MD5.java
! src/java.base/share/classes/sun/security/provider/SHA.java
! src/java.base/share/classes/sun/security/provider/SHA2.java
! src/java.base/share/classes/sun/security/provider/SHA5.java
! test/micro/org/openjdk/bench/java/security/MessageDigests.java
! test/micro/org/openjdk/bench/java/util/UUIDBench.java

Changeset: 77a43023
Author:    David Holmes <dholmes at openjdk.org>
Date:      2021-01-21 02:41:52 +0000
URL:       https://git.openjdk.java.net/amber/commit/77a43023

8223056: Remove Type-Stable-Memory support for Parkers

Reviewed-by: coleenp, rehn

! src/hotspot/os/posix/os_posix.cpp
! src/hotspot/os/posix/os_posix.hpp
! src/hotspot/os/windows/os_windows.cpp
! src/hotspot/os/windows/os_windows.hpp
! src/hotspot/share/prims/unsafe.cpp
! src/hotspot/share/runtime/park.cpp
! src/hotspot/share/runtime/park.hpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp

Changeset: 044bae0e
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2021-01-21 03:54:16 +0000
URL:       https://git.openjdk.java.net/amber/commit/044bae0e

8260191: Do not include access.hpp in oop.hpp

Reviewed-by: kbarrett

! src/hotspot/share/gc/z/zBarrierSetRuntime.cpp
! src/hotspot/share/oops/oop.hpp

Changeset: 01205109
Author:    Leo Jiang <ljiang at openjdk.org>
Date:      2021-01-20 13:58:49 +0000
URL:       https://git.openjdk.java.net/amber/commit/01205109

8259732: JDK 16 L10n resource file update - msg drop 10

Reviewed-by: naoto

! src/demo/share/jfc/SwingSet2/resources/swingset_ja.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_ja.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_ja.properties
! src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties
! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources_ja.java
! src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources_zh_CN.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_ja.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard_zh_CN.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_ja.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties
! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_ja.properties
! src/jdk.jdeps/share/classes/com/sun/tools/javap/resources/javap_zh_CN.properties
! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_ja.properties
! src/jdk.jlink/share/classes/jdk/tools/jmod/resources/jmod_zh_CN.properties
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/LinuxResources_ja.properties
! src/jdk.jpackage/linux/classes/jdk/jpackage/internal/resources/LinuxResources_zh_CN.properties
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_ja.properties
! src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_zh_CN.properties
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_ja.properties
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources_zh_CN.properties
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_ja.properties
! src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_zh_CN.properties
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_ja.properties
! src/jdk.jpackage/windows/classes/jdk/jpackage/internal/resources/WinResources_zh_CN.properties
! src/jdk.jshell/share/classes/jdk/jshell/resources/l10n_ja.properties
! src/jdk.jshell/share/classes/jdk/jshell/resources/l10n_zh_CN.properties

Changeset: 0408b23b
Author:    Igor Ignatyev <iignatyev at openjdk.org>
Date:      2021-01-20 18:48:10 +0000
URL:       https://git.openjdk.java.net/amber/commit/0408b23b

8259757: add a regression test for 8259353 and 8259601

Co-authored-by: Xiaohong Gong <xgong at openjdk.org>
Co-authored-by: Igor Ignatyev <iignatyev at openjdk.org>
Reviewed-by: kvn, jiefu

+ test/hotspot/jtreg/compiler/vectorapi/Test8259353.java

Changeset: 133bcb09
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
Date:      2021-01-21 05:23:42 +0000
URL:       https://git.openjdk.java.net/amber/commit/133bcb09

Merge

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_ja.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclint/resources/doclint_zh_CN.properties

Changeset: f8a9602a
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2021-01-21 06:08:13 +0000
URL:       https://git.openjdk.java.net/amber/commit/f8a9602a

8260025: Missing comma in VM_Version_Ext::_family_id_amd

Reviewed-by: dholmes, stuefe

! src/hotspot/cpu/x86/vm_version_ext_x86.cpp

Changeset: 5940287b
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-21 07:21:24 +0000
URL:       https://git.openjdk.java.net/amber/commit/5940287b

8260048: Shenandoah: ShenandoahMarkingContext asserts are unnecessary

Reviewed-by: zgu, rkennke

! src/hotspot/share/gc/shenandoah/shenandoahMarkingContext.inline.hpp

Changeset: 7f7166db
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2021-01-21 08:27:39 +0000
URL:       https://git.openjdk.java.net/amber/commit/7f7166db

8260035: Deproblemlist few problemlisted test

Reviewed-by: jdv

! test/jdk/ProblemList.txt
! test/jdk/javax/swing/JMenuItem/6249972/bug6249972.java
! test/jdk/javax/swing/JTree/6263446/bug6263446.java
! test/jdk/javax/swing/plaf/basic/Test6984643.java

Changeset: 4dfd8cc4
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2021-01-21 10:30:36 +0000
URL:       https://git.openjdk.java.net/amber/commit/4dfd8cc4

8259897: gtest os.dll_address_to_function_and_library_name_vm fails on AIX

Reviewed-by: mdoerr

! test/hotspot/gtest/runtime/test_os.cpp

Changeset: e1de0bf8
Author:    Eirik Bjorsnos <eirbjo at gmail.com>
Committer: Claes Redestad <redestad at openjdk.org>
Date:      2021-01-21 10:37:40 +0000
URL:       https://git.openjdk.java.net/amber/commit/e1de0bf8

8260043: Reduce allocation in sun.net.www.protocol.jar.Handler.parseURL

Reviewed-by: redestad, chegar

! src/java.base/share/classes/sun/net/www/ParseUtil.java
! src/java.base/share/classes/sun/net/www/protocol/jar/Handler.java

Changeset: 4bcffeb9
Author:    Fei Yang <fyang at openjdk.org>
Date:      2021-01-21 11:58:23 +0000
URL:       https://git.openjdk.java.net/amber/commit/4bcffeb9

8260029: aarch64: fix typo in verify_oop_array

Co-authored-by: Zhuxuan Ni <nizhuxuan at huawei.com>
Reviewed-by: shade, aph

! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp

Changeset: 6ce0799b
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
Date:      2021-01-21 12:10:37 +0000
URL:       https://git.openjdk.java.net/amber/commit/6ce0799b

8259851: Use boolean type for tasks in SubTasksDone

Reviewed-by: kbarrett, tschatzl

! src/hotspot/share/gc/shared/workgroup.cpp
! src/hotspot/share/gc/shared/workgroup.hpp

Changeset: c3c66625
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-21 13:32:45 +0000
URL:       https://git.openjdk.java.net/amber/commit/c3c66625

8259954: gc/shenandoah/mxbeans tests fail with -Xcomp

Reviewed-by: rkennke, zgu

! test/hotspot/jtreg/gc/shenandoah/mxbeans/TestChurnNotifications.java
! test/hotspot/jtreg/gc/shenandoah/mxbeans/TestPauseNotifications.java

Changeset: 34eb8b34
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2021-01-21 16:55:56 +0000
URL:       https://git.openjdk.java.net/amber/commit/34eb8b34

8255765: Shenandoah: Isolate concurrent, degenerated and full GC

Reviewed-by: rkennke, shade

! src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.cpp
! src/hotspot/share/gc/shenandoah/shenandoahCollectorPolicy.hpp
+ src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp
+ src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.hpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp
! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp
! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp
+ src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp
+ src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.hpp
+ src/hotspot/share/gc/shenandoah/shenandoahGC.cpp
+ src/hotspot/share/gc/shenandoah/shenandoahGC.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.hpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp
! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp
! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.hpp

Changeset: a8073efe
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2021-01-21 21:36:19 +0000
URL:       https://git.openjdk.java.net/amber/commit/a8073efe

8253478: (se) epoll Selector should use eventfd for wakeup instead of pipe

Reviewed-by: alanb

! src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java
+ src/java.base/linux/classes/sun/nio/ch/EventFD.java
+ src/java.base/linux/native/libnio/ch/EventFD.c
+ test/micro/org/openjdk/bench/java/nio/SelectorWakeup.java

Changeset: 2f47c39a
Author:    Brian Burkhalter <bpb at openjdk.org>
Date:      2021-01-21 21:54:24 +0000
URL:       https://git.openjdk.java.net/amber/commit/2f47c39a

8259943: FileDescriptor.close0 does not handle EINTR

Reviewed-by: naoto, alanb

! src/java.base/unix/native/libjava/io_util_md.c

Changeset: 34761321
Author:    duke <duke at openjdk.org>
Date:      2021-01-21 22:03:59 +0000
URL:       https://git.openjdk.java.net/amber/commit/34761321

Automatic merge of master into stats-before-this-super



From amaembo at gmail.com  Fri Jan 22 16:23:15 2021
From: amaembo at gmail.com (Tagir Valeev)
Date: Fri, 22 Jan 2021 23:23:15 +0700
Subject: Q on Patterns and Streams
In-Reply-To: <8e60c3df-658e-34bc-e924-7f14024f73ab@oracle.com>
References: <e4b3ea9a-f8ab-8b7f-7bb4-09fd26c0df3c@j-kuhn.de>
 <8e60c3df-658e-34bc-e924-7f14024f73ab@oracle.com>
Message-ID: <CAE+3fjb=1Lkd=NX24QCuWgGbrcteyAwHcaPaPb904YMJD_anuw@mail.gmail.com>

>   .mapMaybe(e -> Optional.ofNullable(e instanceof P(b) ? b : null) )

Btw it's already possible today because we have Stream.ofNullable!

.flatMap(e -> Stream.ofNullable( e instanceof P(b) ? b : null) )

On Wed, Jan 20, 2021 at 9:56 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> Indeed, this is a question we've wrestled with.
>
> You are right that this is a sort of flatMap.  And that the current
> flatMap doesn't express it very nicely, or efficiently.
>
> We've recently added another form of flatMap, mapMulti, which is a lot
> more efficient; in that version, your example would be:
>
>      .mapMulti((e,s) -> { if (e instanceof P(b)) s.accept(b); })
>
> If `void` were a type, we could express this as an expression lambda:
>
>      .mapMulti((e,s) -> e instanceof P(b) ? s.accept(b) : void )
>
> A variant of mapMulti optimized for zero-or-one (which would be more
> sensible when Optional is a primitive class) might be:
>
>      .mapMaybe(e -> Optional.ofNullable(e instanceof P(b) ? b : null) )
>
> where mapMaybe takes a T -> Optional<U>.
>
> Note that the use of patterns here is limited to the case where you are
> going to package up all the bindings into a single value.
>
> There's some other possibilities but I want to think about them some
> more before discussing them.
>
>
> On 1/19/2021 7:30 PM, Johannes Kuhn wrote:
> > Turns out I sometimes write code that looks like this:
> >
> >     foos.stream().filter(e -> e instanceof Foo).map(e -> (Foo) e)...
> >
> > or
> >
> > foos.stream().filter(Foo.class::isInstance).map(Foo.class::cast)...
> >
> > Nicolas Fr?nkel has even written a blog post about this[1].
> >
> > Anyway, this can be expressed with a single stream operation:
> >
> >     foos.stream().flatMap(e -> e instanceof Foo foo ? Stream.of(foo) :
> > Stream.of())...
> >
> > I expect that form to work with any pattern in the future.
> > But it doesn't look great.
> >
> > Are there any plans around this?
> > Or is this something patterns shouldn't be used for?
> >
> > In a more general way - will there be a way to pass a pattern as an
> > argument to some other function?
> >
> > - Johannes
> >
> >
> >
> > [1]: https://blog.frankel.ch/changing-coding-habits-stream-friendly/
>
>

From scolebourne at joda.org  Sun Jan 24 14:18:30 2021
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sun, 24 Jan 2021 14:18:30 +0000
Subject: Feedback: Guards and static/instance pattern declarations
Message-ID: <CACzrW9Cueut29tXJQDh+H-eKW-ktSJ2Ly8yBdgaBUuJUOyFZpQ@mail.gmail.com>

The semantic approach of turning boolean expressions into guard
patterns seems reasonable. But it seems to me that the goal should be
to integrate boolean expressions and patterns as completely as
possible, rather than trying to make them disjoint. Currently:

* the use of & is nasty given its meaning of evaluating both sides
*  true(<booleanExpr>) and false(<booleanExpr>) seem like overkill
("new stuff wants to look new")

// this is the current proposal
 case NumBox(int i) & true(i == 0):
 case NumBox(int i) & true(i > 6) & true(i < 10):

// this seems much more desirable
 case NumBox(0):
 case NumBox(int i) && i > 6 && i < 10:
 case NumBox(int i) && (i < 6 || i > 10):

ie. a guard pattern should just look like a boolean expression. I
think this will be less confusing in the long run - IDEs can highlight
a pattern context in italic/bold/colour if desired.

By introducing a pattern context with a leading keyword, the rule
would be that everything to the right of the keyword is interpreted
using pattern context rules. Params would be used to control the
boundaries of the pattern context if needed.

Rather than letting instanceof operator precedence drive the syntax,
it would be better to add case expressions (everything to the right of
`case` is in the pattern context):

  if (x case NumBox(int i) && i > 6 && i < 10) {...}

(Ideally you'd drop support for type patterns after instanceof in Java
17 - I'm sure people would cope since it has only been there a few
months)

More complex cases would use params:

  if ((x case NumBox(int i) && i > 6) ||
      (x case NumBox(double d) && d > 6) ) {...}

----
A separate part of the discussion is around how to use (and define)
pattern methods that take an input argument. I can see why you'd like
to add them to the language, but most of the examples provided so far
tend to make code less readable, not more. I'm not yet convinced that
user-defined patterns will be net positive to the daily use of the
language.

As the language gets more complex I fear that the developer's brain is
being asked to infer too much from ASCII punctuation. Here, the double
args list in patternMethodCall()() is difficult to follow.

 case regex(REGEX_PATTERN)(var regexMatch1, var regexMatch2):

I'd like to suggest an additional keyword between the two args-lists
makes it much more palatable to read. Here is one possible way:

 if (x case regex(REGEX_PATTERN) match (var regexGroup1, var
regexMatch2)) { ... }

 switch (m) {
  case regex(REGEX_PATTERN_A) match (var regexMatch1) -> ...
  case regex(REGEX_PATTERN_B) {
     match (var regexMatch1) -> ...
     match (var regexMatch1, var regexMatch2) -> ...
   }
  }

In the above, `match` would always be allowed to precede the result
part of the pattern match, but `match` would be omitted with built in
pattern. ie. the first is the verbose form and the second is the
sugar:

  case match (StringBuffer b) -> ...
  case StringBuffer b -> ...

(and no, I don't think this is just because user-defined patterns are
new syntax - I suggest this because I genuinely think the double
arg-list in patternMethodCall()() is hard to read).


----
In summary, I think pattern contexts are a good direction to explore,
but I think doubling down on them and unifying with normal boolean
expressions ought to be possible and readable to avoid creating two
disjoint syntax universes.

By contrast, the user-defined pattern method examples so far look
mostly like a case of "look what we could do" rather than "is this
really beneficial" If user-defined pattern methods are added, I think
an extra keyword to separate obtaining the pattern from matching the
pattern makes it hugely more readable.

Stephen

From scolebourne at joda.org  Sun Jan 24 14:18:25 2021
From: scolebourne at joda.org (Stephen Colebourne)
Date: Sun, 24 Jan 2021 14:18:25 +0000
Subject: Feedback: Using pattern context to make type patterns more consistent
 and manage nulls
Message-ID: <CACzrW9DdhWQ5tVNS9L=LdR7Sct610-oqtq2qiO6Jh_fWe1tfNw@mail.gmail.com>

When nulls were last discussed I expressed reservations about how they
were intended to flow through switch/patterns. It looks like the
latest approach is an improvement.

"So the alternative idea to explore is: make `case null` the _only_
nullable case, but relax fallthrough to allow falling through from
`case null` to a type pattern,"

  case Object o: // non-null
  case null, Object o:  // accepts null

This looks like it would be much better than the original proposal. It
argues that null-acceptance derives from the context, with the
proximity of `instanceof` and `case` driving null rejection. However,
I think it is possible to do better by following a slightly different
context-driven mental model.

----
Based on recent discussions it seems like pattern contexts will become
a significant concept in the language. I think pattern contexts can be
used to make type patterns work more consistently. Indirectly this
allows developers to manage null in patterns.

It seems eminently reasonable, defendable and teachable to say that
`var o` and `Object o` behave differently in a pattern context to a
non-pattern context. I argue that this is more consistent than carving
out a narrow rule that says a type pattern behaves differently when
prefixed by `instanceof` or `case`.

My proposal is that within a pattern context:
* `Foo o` requires the target to match the type Foo as per instanceof
* `var o` matches any type, inferring the type of the local variable

The implication for null is that:
* `Foo o` o rejects null in pattern contexts
* `var o` accepts null in pattern contexts

As can be seen this really this isn't about null, but about making
type patterns actually work consistently. If the type pattern says
`Number n` it should always mean `n instanceof Number`, whereas today
it depends on whether the target of the pattern is Number or Object
(which isn't necessarily visible in the code) and rules around sealed
types, enums and totality (all very confusing). My proposed rule is
absolutely simple and consistent. It results in a huge improvement to
the readability of patterns - if a type is specified in the pattern
then it is matched, no ifs or buts. It focuses on matching the type of
the target, not the type of the method overload (which is a lot
simpler for the developer to comprehend at the use-site). The null
accept/reject outcome is secondary.

This unifies behaviour between instanceof and switch:

 if (x instanceof Object o) ... // o is non-null because it is in a
pattern context
 switch (x) {case Object o ... } // o is non-null because it is in a
pattern context

This also unifies behaviour between the root and nested levels:

 if (x instanceof Box(Object o)) ... // o is non-null because it is in
a pattern context
 switch (x) {case Box(Object o) ... } // o is non-null because it is
in a pattern context

But this does not change any of the recent best practice code which
uses `var` when accepting "everything else":

 if (x instanceof Box(var o)) ... // o may be null
 switch (box) {
   case Box(String s) -> ...  // s is not null
   case Box(Number n) -> ... // n is not null
   case Box(var o) -> ...  // o may be null
 }

What will actually happen is that the totality requirement of
expressions will push developers to use `var o` instead of `Object o`.
Which is a very good thing for readability as `var` will be a helpful
indicator of totality. But it also gives developers a new choice to
insert `case Box(Object o)` and guarantee a non-null object. For
example, the following expression switch would not compile because the
developer has not expressed what should happen with `Box(null)`:

 var result = switch (obj) {
   case Box(String str) -> ...
   case Box(Object o) -> ...
 };

The developer would either need to add a default clause, add a
`Box(var o)` clause at the end, or change from `Box(Object o)` to
`Box(var o)` (most likely). The advice to developers is to always use
`var` in patterns unless explicitly matching against a type.

----
I know that there is a desire to retcon a local variable declaration
to be a pattern. But I haven't broken that desire with anything I've
said above! A local variable declaration can still be thought of as a
pattern, but one that is *not* in a pattern context. A type pattern
outside a pattern context would not require instanceof-like matching
and thus would accept null, as today:

 Object o = someMethod();  // o may be non-null because the pattern is
not in a pattern context
 var o = someMethod();  // o may be non-null

And if a keyword like `let` was added to start a pattern context you would have:

 let (Object o = someMethod()) {...}  // o is non-null, because it is
in a pattern context
 let (var o = someMethod()) {...}  // o may be null

With a nested pattern local variable there *is* a pattern context
(implied by the nest). So the desired short syntax is still possible:

 Box(Object o) = someMethod();  // does not compile, it is not total
 Box(var o) = someMethod();  // o may be non-null

----
In summary, I've outlined how pattern contexts can be used to define
more consistent type pattern behaviour with big readability benefits.
The type pattern `String s` would always behave like instanceof
(rejecting null), whether at the root or nested, so long as it is
within a pattern context. The `var o` pattern doesn't specify a type
to match thus it naturally accepts null, meaning that all the best
practice code examples still work. Local variables are not in a
pattern context, so work as they do today.

Stephen

From brian.goetz at oracle.com  Sun Jan 24 16:09:22 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 24 Jan 2021 11:09:22 -0500
Subject: Feedback: Guards and static/instance pattern declarations
In-Reply-To: <CACzrW9Cueut29tXJQDh+H-eKW-ktSJ2Ly8yBdgaBUuJUOyFZpQ@mail.gmail.com>
References: <CACzrW9Cueut29tXJQDh+H-eKW-ktSJ2Ly8yBdgaBUuJUOyFZpQ@mail.gmail.com>
Message-ID: <377DCF36-D6B0-4F68-B0A7-61583FA46A95@oracle.com>

> The semantic approach of turning boolean expressions into guard
> patterns seems reasonable. But it seems to me that the goal should be
> to integrate boolean expressions and patterns as completely as
> possible, rather than trying to make them disjoint.

> // this is the current proposal
> case NumBox(int i) & true(i == 0):
> case NumBox(int i) & true(i > 6) & true(i < 10):
> 
> // this seems much more desirable
> case NumBox(0):
> case NumBox(int i) && i > 6 && i < 10:
> case NumBox(int i) && (i < 6 || i > 10):


Yes, this is the thing that one would ?obviously want? after a first look at the problem.  And indeed, we thought that way at first too, and we spent a fair amount of time exploring this direction. And, it may even still be technically possible, but what I learned is that I am not sure we?d like the result (or the constraints) if we went all the way there.  But the reasons are not obvious from trivial examples such as these; in the trivial examples it works great, so OF COURSE that seems more desirable.  

> *  true(<booleanExpr>) and false(<booleanExpr>) seem like overkill
> ("new stuff wants to look new?)

I was sure someone would level that accusation, and you did not disappoint :)  But that?s not the motivation here.  

A better way to think about this distinction is it is like the ?bun? in a stream pipeline.  Recall that when we did streams, there was a strong desire at first (including, on my part) to just expose the stream methods on collections, rather than requiring a ?bun? where you have to exit from Collection World and enter Stream World.  The choice to require the .stream() call was a painful decision to make, full of self-about about what we were subjecting Java developers to, and much ink was spilled about the ?unneeded verbosity".  In hindsight, though, it was ?obviously? the absolute slam-dunk right move.  

The essence of the ?bun? decision was that there was a transition in the programming model; collections are eager, mutative, data-centric , and streams are  lazy, computation-centric.  The programming models were different, so having a clean transition between them made sense, not because Streams were ?new?, but because they were qualitatively different.  This decision turned out to have paid significant dividends beyond collections.  (At first, our desire to integrate these behaviors into collections was so powerful it blinded us to the much more powerful abstraction of Stream; only when we ?gave into the bun? did we see this!  Kind of scary in hindsight.) 

The same is true, at least qualitatively, between patterns and guard expressions.  Patterns are templates for behavior, and their evaluation model is different from expressions.  Even absent syntactic ambiguities, it seems likely to lead to confusion when we get beyond the simplest examples.  And, there are syntactic forms that are currently in the intersection of the pattern and expression grammar (e.g., `Foo(), null, and possibly other constant literals`).  Even if we distorted the syntax to avoid these (which might generate more complaints about clunky syntax), ambiguities exist not only in grammars, but in our interpretation of programs.  The ?bun? is a useful demarcation for streams, and while I totally understand how `true` seems a little heavy handed, I think its a useful demarcation here too.  

In an earlier set of questions about pattern matching, you asked ?why not just have an if-match form, rather than make pattern matches full expressions.?  The response gave a number of examples, but the summary is that ?we win when we lean into composition; we lose when we lean against it."

The ?guards at the end? approach (whether conjoined with && or `when`) is another example of anti-compositional thinking in action.  Just as ?if match? shunts the pattern to one corner of the if-else, and doesn?t allow it to be combined with other logic, treating guards as things we tack onto the tail of a case (which again, might seem the ?obvious? move at first) means that we are constrained to execute all the patterns and then all the guards, rather than allow them to compose naturally in the order the programmer intends.  

> * the use of & is nasty given its meaning of evaluating both sides

Yeah, the both-sides thing is a concern.  

> By introducing a pattern context with a leading keyword, the rule
> would be that everything to the right of the keyword is interpreted
> using pattern context rules. Params would be used to control the
> boundaries of the pattern context if needed.

This is exactly the anti-compositional result I was discussing above.  Once you exit pattern-world, you can?t get back.  But, if you look at the sketches of examples for, say, JSON parsing, you want to be able to get back.  Because, composition.  

> it would be better to add case expressions
> (Ideally you'd drop support for type patterns after instanceof in Java
> 17 - I'm sure people would cope since it has only been there a few
> months)

I?m a little confused why we?re even talking about this; this ship has sailed?

> A separate part of the discussion is around how to use (and define)
> pattern methods that take an input argument. I can see why you'd like
> to add them to the language, but most of the examples provided so far
> tend to make code less readable, not more. I'm not yet convinced that
> user-defined patterns will be net positive to the daily use of the
> language.

I?m confident you?ll get there!  Even the most obvious examples (regular expressions, Map::get, JSON parsing) are pretty compelling, and you would stumble across them after only a short time using this stuff.  Do you really want to write a new ?method? for every new regular expression you want to match?  That will get tired by the second day, I promise you.  

I get that this can be a lot to take in; if you haven?t been thinking about the problem for years, it may all seem very YAGNI.  But, there?s a deeper thing here beyond the surface features ? we?ve been in such pain for the lack of these features for years, that we don?t even notice how painful it is that decomposition is completely ad-hoc and different from how we express aggregation, that conditional extraction is not compositional, that encapsulation is a unnecessarily one-way street.  

It is fair to wonder whether this is all too much, but it would be better to use that energy to imagine what you can do with this ? and what the boundaries of that are, so they can be extended before the model becomes too set.  

> case regex(REGEX_PATTERN)(var regexMatch1, var regexMatch2):
> 
> I'd like to suggest an additional keyword between the two args-lists
> makes it much more palatable to read. Here is one possible way:

I appreciate the suggestion, but I think it?s premature to start nigling on the syntax of this at this point.  (Unless, you already are 100% convinced the model is 100% right, and you?re just trying to accelerate time-to-integration?)  The purpose of this document was not to fire the bikeshed-starting-gun (though I know its hard to resist), but to help people understand where we?re headed, and why.  Until you?re 100% on board with the where and why, I think getting caught up on the syntax is probably getting in the way of seeing the bigger picture.



From brian.goetz at oracle.com  Sun Jan 24 16:56:14 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 24 Jan 2021 11:56:14 -0500
Subject: Feedback: Using pattern context to make type patterns more
 consistent and manage nulls
In-Reply-To: <CACzrW9DdhWQ5tVNS9L=LdR7Sct610-oqtq2qiO6Jh_fWe1tfNw@mail.gmail.com>
References: <CACzrW9DdhWQ5tVNS9L=LdR7Sct610-oqtq2qiO6Jh_fWe1tfNw@mail.gmail.com>
Message-ID: <A11E56BB-9B9E-402D-A292-A416CC7EADF1@oracle.com>

> When nulls were last discussed I expressed reservations about how they
> were intended to flow through switch/patterns. It looks like the
> latest approach is an improvement.

I agree, though I want to point out that it is a very small change from the previous iteration ? it is limited solely to how nulls interact with switch, and does not affect the semantics of pattern matching at all.  (I?m happy you?re happy, but it?s more important that you understand what exactly is being proposed.)

> This looks like it would be much better than the original proposal. It
> argues that null-acceptance derives from the context

I?m not sure where you get this.  We?ve been pretty consistent from the beginning in saying that both context and patterns can have opinions about nullity, and the context always gets to express its opinions first, and can choose to not even pay attention to the pattern.  Patterns have their own semantics, which are independent of context, and then contexts get to layer their semantics on top. 

> It seems eminently reasonable, defendable and teachable to say that
> `var o` and `Object o` behave differently in a pattern context to a

Believe me, I have spent more hours thinking about this proposal than you?ll know.  There?s even a trivial existence proof that this is viable, in that this is what Scala does, and the Scala work hasn?t blown up (at least, not because of this).  But I am convinced that this would be the wrong move for Java.  

The cost of this is subtle, but significant ? `var` becomes a far more complicated concept; it is no longer mere type inference.  It means that in some contexts, swapping var for a manifest type subtly changes the semantics, in extremely subtle ways that won?t be noticed at first and in ways that are likely to be persistently error-prone. (And for types that are not denotable and therefore var is your only choice, it means you?re locked into one particular null handling regime.)  Essentially, this is a trade-off of ?let?s make var way more complicated in a super-subtle way that ordinary users will never internalize in a million years?.  

So, let?s say we made that trade; what do we get?  I don?t think the return is there.  You can?t banish the complexity of null handling, you can only moving it to where it is more surprising or increase the complexity of the mechanisms.  Your proposal just moves it to var.  

I?ll state again, too, that I think the ?OMG the nulls will eat us in our sleep? fears are dramatically overblown.  Before we set anything on fire, I think we should come to terms with why we think there is such a problem.  

> As can be seen this really this isn't about null, but about making
> type patterns actually work consistently.

Type patterns do work consistently when you zoom out just a tiny bit, and recognize that pattern matching exists in a static type context.  Suppose I have `record Box(Object) {}`.  Then the pattern:

    case Box(Object o): 

is, in some sense is ?one? pattern match; the inner pattern (Object o) can be statically determined to always succeed when the outer one does, and therefore the only dynamic test here is for Box-hood.  So we test for Box-hood, conditionally cast, extract the contents, and *assign* it to o.  Assignment doesn?t say ?if the contents are null, fail?; it?s just that there *is no inner match here*.   But in the pattern:

    case Box(String s): 

this is ?two? pattern matches: even if the outer pattern matches, the inner might not.  There are two dynamic tests, first for box-hood, and then for string-hood of the box contents. And the string-hood test is done as if by instanceof, which is where the null rejection comes from ? nothing new here.  It is not that type patterns are ?inconsistent?; it is that some patterns are really just assignment, and this is identified on the basis of whether a dynamic test is needed or not.  There?s a reason that `instanceof` and casting are ?inconsistent? with each other respect to nulls, and that reason is flowing into the semantics of patterns.  (Do the thought experiment of ?what if instanceof passed nulls? or ?what if checkcast rejected nulls?, and imagine what would break.  A lot.)  

Trust me, we?ve been through all of these proposals (and more); they all lead to their own corner cases, composition failures, refactoring anomalies, etc. that seem worse (in some cases, far worse) or are more complex, or both.  Rather than tinkering with the rules, I think a better investment of your energy is trying to understand exactly _why_ you find the status quo so problematic that you are inclined to set it on fire.  I think investing that effort in better understanding the problem, rather than trying to ?solve? it, is far more likely to yield a useful result, and as a bonus, is far more likely to move the needle if there really is something there. 

> If the type pattern says
> `Number n` it should always mean `n instanceof Number`

We?ve been through this already in a previous round.  I get that you have decided that this is the fixed point of your interpretation of what type patterns mean, but the problem is just not as simple as you would like it to be.  While it is theoretically possible to distort the design to adopt this as the founding principle, it  just moves the damage elsewhere.  

Perhaps this would help: you are saying ?Please don?t set my understanding of `instanceof` on fire.  I have a proposal so that you don?t have to do it, all you have to do is set `var` on fire.?  You can see how this might not seem an obvious trade.  



From brian.goetz at oracle.com  Sun Jan 24 17:46:49 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Sun, 24 Jan 2021 12:46:49 -0500
Subject: Feedback: Guards and static/instance pattern declarations
In-Reply-To: <377DCF36-D6B0-4F68-B0A7-61583FA46A95@oracle.com>
References: <CACzrW9Cueut29tXJQDh+H-eKW-ktSJ2Ly8yBdgaBUuJUOyFZpQ@mail.gmail.com>
 <377DCF36-D6B0-4F68-B0A7-61583FA46A95@oracle.com>
Message-ID: <67C408D6-E580-4F51-B3E8-D1E8B96DD87C@oracle.com>

> 
>> * the use of & is nasty given its meaning of evaluating both sides
> 
> Yeah, the both-sides thing is a concern.  

On further thought (actually, retracing my steps from the first time), it?s not really as concerning as it first looks, for reasons that connect to the ?bun? argument ? that the & is applying in ?pattern world?, not ?left to right expression world?.  

A good way to think of a pattern is that it is a deferred computation, not unlike a lambda.  When I say `x instanceof P`, P is a recipe for computation, which will be ?invoked? via instanceof at the appropriate time.  To the extent that P refers to state from the enclosing computation, we almost certainly impose the same requirement as we do on lambdas: that it be effectively final; this avoids messy and generally unhelpful questions about the semantics of patterns.  (Guard patterns can refer to bindings from earlier in the pattern, and to ?captured? locals from the local context, so long as they are effectively final.)  So when we say P&Q, we mean the conjunction of the patterns P and Q, but we are not saying ?compete P, compute Q, and take their intersection?; we are specifying a new pattern, but we haven?t evaluated anything yet.  

More concretely, if we say 

    if (t instanceof Foo(var x, var y) & true(x > y) & Bar(var z)) { ? }

then we are defining a pattern that is the combination of three simpler patterns.  When we test against that composite pattern, there are of course rules for how to interpret matching.  In my recent mail about ?next steps?, there's something like:

  - matches(x, A&B) === matches(x, A) && matches(x, B)

Bottom line is I think it will be useful to think of a complex pattern as being a specifier for some deferred computation, like a lambda.  The & conjunction builds bigger deferred computations from smaller ones.  The bun lets us pull expressions that are suitable for deferred computation into the pattern.

From scolebourne at joda.org  Mon Jan 25 00:46:49 2021
From: scolebourne at joda.org (Stephen Colebourne)
Date: Mon, 25 Jan 2021 00:46:49 +0000
Subject: Feedback: Using pattern context to make type patterns more
 consistent and manage nulls
In-Reply-To: <A11E56BB-9B9E-402D-A292-A416CC7EADF1@oracle.com>
References: <CACzrW9DdhWQ5tVNS9L=LdR7Sct610-oqtq2qiO6Jh_fWe1tfNw@mail.gmail.com>
 <A11E56BB-9B9E-402D-A292-A416CC7EADF1@oracle.com>
Message-ID: <CACzrW9D54gwmOntkbe3gYQBFczjSEUJQb4UNAkw1vkRwnqOOaQ@mail.gmail.com>

On Sun, 24 Jan 2021 at 16:56, Brian Goetz <brian.goetz at oracle.com> wrote:
> I think the ?OMG the nulls will eat us in our sleep? fears are dramatically overblown.  Before we set anything on fire, I think we should come to terms with why we think there is such a problem.

And I'll point out that my last email tried really hard to express
that I consider null to be a secondary effect here. I'm not concerned
with null, but with basic code readability and consistency.

> Type patterns do work consistently when you zoom out just a tiny bit, and recognize that pattern matching exists in a static type context.  Suppose I have `record Box(Object) {}`.  Then the pattern:
>     case Box(Object o):
> is, in some sense is ?one? pattern match; the inner pattern (Object o) can be statically determined to always succeed when the outer one does, and therefore the only dynamic test here is for Box-hood.  So we test for Box-hood, conditionally cast, extract the contents, and *assign* it to o.  Assignment doesn?t say ?if the contents are null, fail?; it?s just that there *is no inner match here*.   But in the pattern:
>     case Box(String s):
> this is ?two? pattern matches: even if the outer pattern matches, the inner might not.  There are two dynamic tests, first for box-hood, and then for string-hood of the box contents.

That is a huge inconsistency! A developer has nothing in the code to
separate the static one from the dynamic one:

 switch (box) {
   case Box(Integer i) ...
   case Box(Number n) ...
}

Reading this code I have no way of knowing what it does. None.

If box is Box<Number> it does one thing. If box is Box<Object> it does
something else. Sure the impact is only on null, but that is a
secondary detail and not what is driving my concern. The key point is
that someone reading the code can't tell what branch the code will
take, and can get a different outcome for two identical patterns in
different parts of the codebase.

> zoom out just a tiny bit, and recognize that pattern matching exists in a static type context

This is the key bit. While obviously there is a static type context
that provides a boundary to the problem space, the context can be
*invisible*. What you are offering is a proposal where the meaning of
the pattern `Type t` varies based on hidden information. Using the
static context is effectively a premature optimization with very
negative effects.

What I am suggesting is a simple requirement, that a pattern `Type t`
is always dynamic, matching like instanceof wherever it is found, This
has to be the requirement because that is what the developer
physically wrote in the code, and identical looking coding elements
should work in identical ways (eg. String s and Object o).

If you can find an alternative to using `var` in the way I propose
that is fine by me. As I pointed out in my last email, the situations
where there is a conflict to resolve are relatively rare, because best
practice is to use `var` for the final case anyway.

As it stands, the proposal will never be acceptable to me because it
fails the code readability test - premature optimization by using the
static context means the code doesn't do what it says it does.

Stephen

From john.r.rose at oracle.com  Mon Jan 25 04:20:23 2021
From: john.r.rose at oracle.com (John Rose)
Date: Sun, 24 Jan 2021 20:20:23 -0800
Subject: Feedback: Using pattern context to make type patterns more
 consistent and manage nulls
In-Reply-To: <CACzrW9D54gwmOntkbe3gYQBFczjSEUJQb4UNAkw1vkRwnqOOaQ@mail.gmail.com>
References: <CACzrW9DdhWQ5tVNS9L=LdR7Sct610-oqtq2qiO6Jh_fWe1tfNw@mail.gmail.com>
 <A11E56BB-9B9E-402D-A292-A416CC7EADF1@oracle.com>
 <CACzrW9D54gwmOntkbe3gYQBFczjSEUJQb4UNAkw1vkRwnqOOaQ@mail.gmail.com>
Message-ID: <7D8B4F2D-15BC-4C56-AC7E-7BAF8449D648@oracle.com>

On Jan 24, 2021, at 4:46 PM, Stephen Colebourne <scolebourne at joda.org> wrote:
> 
> switch (box) {
>   case Box(Integer i) ...
>   case Box(Number n) ...
> }
> 
> Reading this code I have no way of knowing what it does. None.

That?s too hyperbolic.  We know 99% of what will happen even
if we are ignorant of the type of box.  So the details of what
happens with an expression sometimes depend on the precise
type of the expression.  That?s endemic to every statically
typed language, and not at all unique to this case, so it?s not
at all clear to me why you are pulling the emergency brake
at this point.  In short, I don?t buy it; I don?t even see how
I could begin to convince myself that you have a reasonable
point.  Sorry.

> If box is Box<Number> it does one thing. If box is Box<Object> it does
> something else. Sure the impact is only on null, but that is a
> secondary detail and not what is driving my concern. The key point is
> that someone reading the code can't tell what branch the code will
> take, and can get a different outcome for two identical patterns in
> different parts of the codebase.

At some point, there?s a burden on the writer of the code
to avoid what we affectionately call ?puzzlers?.  As has been
said before, the existence of new puzzlers cannot be any
conclusive argument against a proposed language feature.

The burden, in this case, on the author of the switch statement,
is to gauge whether the handling of nulls and/or non-Number
boxed items is significant or not, and use the resources of the
language to communicate the policy of this switch towards
such values.  A separate default case, or a proposed ?this is total?
marker on the final case, would do the job more than adequately.

? John



From forax at univ-mlv.fr  Mon Jan 25 11:17:52 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 25 Jan 2021 12:17:52 +0100 (CET)
Subject: Feedback: Using pattern context to make type patterns more
 consistent and manage nulls
In-Reply-To: <CACzrW9D54gwmOntkbe3gYQBFczjSEUJQb4UNAkw1vkRwnqOOaQ@mail.gmail.com>
References: <CACzrW9DdhWQ5tVNS9L=LdR7Sct610-oqtq2qiO6Jh_fWe1tfNw@mail.gmail.com>
 <A11E56BB-9B9E-402D-A292-A416CC7EADF1@oracle.com>
 <CACzrW9D54gwmOntkbe3gYQBFczjSEUJQb4UNAkw1vkRwnqOOaQ@mail.gmail.com>
Message-ID: <58004658.359858.1611573472517.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Stephen Colebourne" <scolebourne at joda.org>
> ?: "amber-dev" <amber-dev at openjdk.java.net>
> Envoy?: Lundi 25 Janvier 2021 01:46:49
> Objet: Re: Feedback: Using pattern context to make type patterns more consistent and manage nulls

> On Sun, 24 Jan 2021 at 16:56, Brian Goetz <brian.goetz at oracle.com> wrote:
>> I think the ?OMG the nulls will eat us in our sleep? fears are dramatically
>> overblown.  Before we set anything on fire, I think we should come to terms
>> with why we think there is such a problem.
> 
> And I'll point out that my last email tried really hard to express
> that I consider null to be a secondary effect here. I'm not concerned
> with null, but with basic code readability and consistency.
> 
>> Type patterns do work consistently when you zoom out just a tiny bit, and
>> recognize that pattern matching exists in a static type context.  Suppose I
>> have `record Box(Object) {}`.  Then the pattern:
>>     case Box(Object o):
>> is, in some sense is ?one? pattern match; the inner pattern (Object o) can be
>> statically determined to always succeed when the outer one does, and therefore
>> the only dynamic test here is for Box-hood.  So we test for Box-hood,
>> conditionally cast, extract the contents, and *assign* it to o.  Assignment
>> doesn?t say ?if the contents are null, fail?; it?s just that there *is no inner
>> match here*.   But in the pattern:
>>     case Box(String s):
>> this is ?two? pattern matches: even if the outer pattern matches, the inner
>> might not.  There are two dynamic tests, first for box-hood, and then for
>> string-hood of the box contents.
> 
> That is a huge inconsistency! A developer has nothing in the code to
> separate the static one from the dynamic one:
> 
> switch (box) {
>   case Box(Integer i) ...
>   case Box(Number n) ...
> }
> 
> Reading this code I have no way of knowing what it does. None.
> 
> If box is Box<Number> it does one thing. If box is Box<Object> it does
> something else. Sure the impact is only on null, but that is a
> secondary detail and not what is driving my concern. The key point is
> that someone reading the code can't tell what branch the code will
> take, and can get a different outcome for two identical patterns in
> different parts of the codebase.
> 
>> zoom out just a tiny bit, and recognize that pattern matching exists in a static
>> type context
> 
> This is the key bit. While obviously there is a static type context
> that provides a boundary to the problem space, the context can be
> *invisible*. What you are offering is a proposal where the meaning of
> the pattern `Type t` varies based on hidden information. Using the
> static context is effectively a premature optimization with very
> negative effects.
> 
> What I am suggesting is a simple requirement, that a pattern `Type t`
> is always dynamic, matching like instanceof wherever it is found, This
> has to be the requirement because that is what the developer
> physically wrote in the code, and identical looking coding elements
> should work in identical ways (eg. String s and Object o).
> 
> If you can find an alternative to using `var` in the way I propose
> that is fine by me. As I pointed out in my last email, the situations
> where there is a conflict to resolve are relatively rare, because best
> practice is to use `var` for the final case anyway.
> 
> As it stands, the proposal will never be acceptable to me because it
> fails the code readability test - premature optimization by using the
> static context means the code doesn't do what it says it does.

I'm sympathetic to what you are writing because it was what i was thinking few months ago.
I totally agree that 
  switch(box) {
    case Box(Integer i) ...
    case Box(var number) ...
  }
is more readable in term of intent.

But at the same time as a developer, i want to know what is the inferred type of "number", at least in my IDE, given that var is inferred as Number,
it's not unreasonable to think that if i replace var by Number, it works the same way.

Now, the discussion about null, i or number are bindings, more or less like multiple return parameters (Brian: i said more or less).
Those bindings will be sometimes null, by example,
  map.put("what!", null);
  ... map.value("what!", var value) -> ... // value is null here

so we (the EG) have to choose what is the best semantics, throw a NPE by default or being null permissive.
Obviously, as a user you don't want to propagate null so raising a NPE seems a good idea, but in fact it's not.
First, it means that in a middle of a switch, you will get spurious NPE but more importantly it's not compatible with the way we deal with null when we do a method call (invoking a pattern is alike doing a method call). With a method call, we will check if the return is null or not and act accordingly.

Another idea is to split things saying, the compiler should mandate a Box(null), but once you start to match multiple bindings, you go to combinatorial hell.

So saying that the total pattern is called if there is a null seems a good pragmatical choice.

> 
> Stephen

R?mi

From brian.goetz at oracle.com  Mon Jan 25 12:46:36 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 25 Jan 2021 07:46:36 -0500
Subject: Feedback: Using pattern context to make type patterns more
 consistent and manage nulls
In-Reply-To: <CACzrW9D54gwmOntkbe3gYQBFczjSEUJQb4UNAkw1vkRwnqOOaQ@mail.gmail.com>
References: <CACzrW9DdhWQ5tVNS9L=LdR7Sct610-oqtq2qiO6Jh_fWe1tfNw@mail.gmail.com>
 <A11E56BB-9B9E-402D-A292-A416CC7EADF1@oracle.com>
 <CACzrW9D54gwmOntkbe3gYQBFczjSEUJQb4UNAkw1vkRwnqOOaQ@mail.gmail.com>
Message-ID: <f7d4f257-c630-836f-ff64-4f79707b51c7@oracle.com>



> I'm not concerned
> with null, but with basic code readability and consistency.


The great thing about being motivated by consistency is that you get to 
pick what you find it most important to be consistent with :)? In a 
complex world, there are always going to be preexisting 
"inconsistencies", which means you always have a choice of what to 
choose to be consistent with.? For example, the null-handling treatment 
of instanceof and cast are different, which one could call 
"inconsistent", except that ... it is right.? Consistency is a good 
guiding principles, and gratuitous inconsistency is surely bad, but it 
is not necessarily the highest good -- nor necessarily even a 
well-defined concept.

In any case, your concern has to be at least a little bit about null, 
because ... that's the only thing that is varying here; no one disagrees 
that `String s` should match all non-null instances of String.? You are 
suggesting type patterns never match null, so they can be "consistent" 
with how the `instanceof` bytecode works. There's nothing wrong with 
that particular preference of "things to be consistent with", but its 
not the only choice, and it has costs.

For the record, here are the consistencies we've chosen:
 ?- var should consistently only mean "type inference", so users can 
orthogonally choose whether to use manifest or inferred types, according 
to what they find more readable, and freely switch back and forth, and ..
 ?- a nested patterns `x matches P(Q)` should mean nothing more than 
P(var alpha) && alpha matches Q.

When you make these two choices, the semantics we have pretty much write 
themselves.

Of course, just because the semantics derive from consistent and 
principled choices, doesn't mean that it results in a good programming 
model; we have to validate that the consequences of these choices leads 
to the programs we actually want.? I think your main concern here is 
that you are worried this is not the case, but we should let actual code 
be our guide here.

It's important to realize that the typical "type switch" examples we've 
long wanted in Java don't actually give us that much intuition for what 
typically happens with *nested* pattern switches.? When you write enough 
code using such things, you see that there are tree-shaped patterns of 
code that emerge where at each level, cases organize themselves into 
lattices, where specialized cases funnel into catch-all cases:

 ??? case Box(Prime p):
 ??? case Box(Even e):
 ??? case Box(Object o):?? // catch all
 ??? ...

and that the typical pattern of how this works, while "inconsistent" 
with respect to who gets the nulls, turns out to actually be what you 
want, a great fraction of the time.? (If null is not in the domain of 
what is in the boxes, it doesn't matter; if it is, catch-all Box code 
(which the last represents) will be prepared to deal with it.)? In the 
cases where it is not what you want, you can exclude it (with guards, 
with null checks, whatever.)

Another thing to realize is that the examples with `Box(Chocolate)` are 
just simple examples.? In the real world, we'll have deconstructors with 
handfuls of bindings (as constructors do today), and a deconstruction 
pattern that reads `Foo(var a, var b, var c, var d, var e)` may not be 
quite as appealing from a readability perspective as when there's only 
one parameter and its obvious what it is.? Forcing users to choose 
between semantics and readability (whichever way they happen to want to 
go with var-vs-manifest) is not a good look.

> That is a huge inconsistency! A developer has nothing in the code to
> separate the static one from the dynamic one:
>
>   switch (box) {
>     case Box(Integer i) ...
>     case Box(Number n) ...
> }
>
> Reading this code I have no way of knowing what it does. None.
>
> If box is Box<Number> it does one thing. If box is Box<Object> it does
> something else. Sure the impact is only on null, but that is a
> secondary detail and not what is driving my concern. The key point is
> that someone reading the code can't tell what branch the code will
> take, and can get a different outcome for two identical patterns in
> different parts of the codebase.

I get that this seems different and scary when it is all theoretical and 
we're extrapolating from almost no examples.? Write some code with it, 
though, and I think you'll find it is surprisingly natural, and the 
things you are worried about don't happen remotely as often as you are 
scared they will.? And, the alternatives are far worse. We could set 
`var` on fire (really not such a good deal), or we could invent multiple 
kinds of type patterns, one nullable, and one not (a lot of added 
complexity, just so users can spend more energy focusing on low-level 
corner cases than they really ever want), or we could tinker with the 
semantics so that the razor blades are hidden in even less expected 
places, or we could add `T!` type patterns but not have `T!` in the 
general type system (imagine the rants about inconsistency then.)? 
Having a simple set of rules derived from a small number of clear 
principles goes a long way towards helping people reason about the 
complexity that we can't make go away.

> If you can find an alternative to using `var` in the way I propose
> that is fine by me. As I pointed out in my last email, the situations
> where there is a conflict to resolve are relatively rare, because best
> practice is to use `var` for the final case anyway.

I agree that will be common in the obvious cases.?? (In which case, the 
things you are worried about will happen even less often.)? But as 
mentioned above, I'm skeptical that this will actually be a "best 
practice" when there are many bindings and its not completely obvious 
what the types are.? This is something users should get to choose for 
themselves.

> As it stands, the proposal will never be acceptable to me because it
> fails the code readability test - premature optimization by using the
> static context means the code doesn't do what it says it does.

These rules, for all the parts you don't like, are simple; I have great 
faith that you will learn how things work and how to read the patterns 
of code that typically emerge.? (You might even like it, after writing 
some actual code with it, but regardless, I don't believe you, or any 
other Java developer, is incapable of understanding what the code says.

We see examples of this all over the place in Java, such as:

 ?- Method overloading.? How do I know which overload of x.foo() I am 
calling, or which overload X::foo refers to?? A: when it's not obvious, 
ask the IDE, or look it up in the Javadoc.
 ?- Type inference.? How do I know what types are being inferred for 
generic method calls, or what gets inferred for `var`?? A: when it's not 
obvious, ask the IDE (or, for masochists, work it out yourself), and 
then, put explicit witnesses in the code so other readers can see.



From sarma.swaranga at gmail.com  Mon Jan 25 22:58:59 2021
From: sarma.swaranga at gmail.com (Swaranga Sarma)
Date: Mon, 25 Jan 2021 14:58:59 -0800
Subject: Pattern matching for nested List with additional size constraints
Message-ID: <CAGZD2TCbAH+8NzaFfHqqzQQh18Xf2xCbvuzzpj_idH0caWhDzg@mail.gmail.com>

Hello, I was going through some code in my work today and came across
several similar looking cases and was wondering if pattern matching would
be a more concise and cleaner way to pxress the logic.

Here is a succinct class hierarchy that illustrates the example:

class Profile {
  Rules rules;
}
class Rules {
  List<Rule> ruleList;
}
class Rule {
  DynamicConfig dynamicConfig;
  StaticConfig staticConfig;
}
class DynamicConfig {
  SomeProperty property;
}
class StaticConfig {
  SomeOtherProperty property;
}

With the above classes, we have a method "isDynamicConfigProfile" that
determines if the Profile is a DynamicConfig profile. A Profile is
considered dynamic if it contains a Rule with a non-null DynamicConfig
member; also ALL the Rules of a profile can only contain one type either
Dynamic or Static so checking just the first element in the ruleList is
sufficient.

The current code is implemented as:

boolean isDynamicProfile (Profile profile) {
  return profile.rules() != null &&
             profile.rules().ruleList() != null &&
             profile.rules().ruleList().size() > 0 &&
             profile.rules().rulesList().get(0).dynamicConfig() != null;
}

Is the above method something that could be expressed with a switch and
pattern matching; assuming these are converted to Record classes? Something
like:

boolean isDynamicProfile (Profile profile) {
  return switch(profile) {
    case Profile(Rules(Rule(DynamicConfig dc), Rule(var r2)...
remainingElements)) -> true;
    default-> false;
  }
}

Is it even a valid usage of patterns? I think even the List interface would
need to support pattern matching in this case.

Regards
Swaranga

From brian.goetz at oracle.com  Wed Jan 27 20:02:33 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 27 Jan 2021 15:02:33 -0500
Subject: Pattern matching for nested List with additional size constraints
In-Reply-To: <CAGZD2TCbAH+8NzaFfHqqzQQh18Xf2xCbvuzzpj_idH0caWhDzg@mail.gmail.com>
References: <CAGZD2TCbAH+8NzaFfHqqzQQh18Xf2xCbvuzzpj_idH0caWhDzg@mail.gmail.com>
Message-ID: <ea9187bb-e33f-fc38-9497-33d80ebd5a2d@oracle.com>

Eventually, yes.

Your example wants to capture a number of conditions:
 ?- the Profile contains a non-null Rules
 ?- the Rules contains a non-null List<Rule>
 ?- The List<Rule> is non-empty
 ?- The first rule in the list is dynamic

Each of these conditions can be captured in a pattern, and the patterns 
can be composed.? Some of them can be handled by built-in patterns (type 
and deconstruction patterns).? Let me rebuild your hierarchy a little:

 ??? record Profile(Rules rules) { }
 ??? record Rules(List<Rule> rulesList) { }
 ??? record Rule(DynamicConfig dc, StaticConfig sc) { }

and let's assume that records already have deconstruction patterns.? So 
we can do the easy parts already with these:

 ??? if (p instanceof Profile(Rules(List<Rule> rulesList))
 ??????? && rulesList != null && rulesList.length() > 0
 ??????? && rulesList.get(0).dc() != null) { ... }

This means:
 ?- If p is a Profile, and non-null, cast to Profile, and extract the 
rules, and
 ?- If the rules is a Rules, and it is non-null, cast to a Rules, and 
extract the rulesList, and
 ?- do the rest imperatively

Obviously, this only helps a little bit.? What we need is a pattern that 
matches lists, and then can further match on their elements.? We have an 
existing varargs list factory List.of(T...); imagine we will have a 
varargs pattern that matches Lists and then matches nested patterns to 
the list elements, and imagine that's called List.of() also.? Then we 
can eliminate the next two tests:

 ??? if (p instanceof Profile(Rules(List.of(var rule, ...)))
 ??????????? && rule.dc() != null) {

 ??????? use(rule.dc());
 ??? }

This means:
 ?- If p is a Profile, and non-null, cast to Profile, and extract the 
rules, and
 ?- If the rules is a Rules, and it is non-null, cast to a Rules, and 
extract the rulesList, and
 ?- If the rulesList is a non-null List, cast to a List, get the length, 
and it has a first element, get the first element, and bind the element 
to `rule`, and
 ?- do the rest imperatively

If you wanted to move all this into a pattern (say, so it could be used 
in a switch), you can move the last condition into a guard:

 ??? if (p instanceof Profile(Rules(List.of(var rule, ...) & 
false(rule.dc() == null))) {
 ??????? use(rule.dc());
 ??? }

In the future, when you can declare your own patterns, you can do 
better, by declaring a pattern in Rule that only matches rules with 
dynamic configuration, and yields up the dynamic configuration:

 ??? if (p instanceof Profile(Rules(List.of(Rule.dynamic(var dc), ...))) {
 ??????? use(dc);
 ??? }

So yes, we'll get there, but it will take a few iterations.


On 1/25/2021 5:58 PM, Swaranga Sarma wrote:
> Hello, I was going through some code in my work today and came across
> several similar looking cases and was wondering if pattern matching would
> be a more concise and cleaner way to pxress the logic.
>
> Here is a succinct class hierarchy that illustrates the example:
>
> class Profile {
>    Rules rules;
> }
> class Rules {
>    List<Rule> ruleList;
> }
> class Rule {
>    DynamicConfig dynamicConfig;
>    StaticConfig staticConfig;
> }
> class DynamicConfig {
>    SomeProperty property;
> }
> class StaticConfig {
>    SomeOtherProperty property;
> }
>
> With the above classes, we have a method "isDynamicConfigProfile" that
> determines if the Profile is a DynamicConfig profile. A Profile is
> considered dynamic if it contains a Rule with a non-null DynamicConfig
> member; also ALL the Rules of a profile can only contain one type either
> Dynamic or Static so checking just the first element in the ruleList is
> sufficient.
>
> The current code is implemented as:
>
> boolean isDynamicProfile (Profile profile) {
>    return profile.rules() != null &&
>               profile.rules().ruleList() != null &&
>               profile.rules().ruleList().size() > 0 &&
>               profile.rules().rulesList().get(0).dynamicConfig() != null;
> }
>
> Is the above method something that could be expressed with a switch and
> pattern matching; assuming these are converted to Record classes? Something
> like:
>
> boolean isDynamicProfile (Profile profile) {
>    return switch(profile) {
>      case Profile(Rules(Rule(DynamicConfig dc), Rule(var r2)...
> remainingElements)) -> true;
>      default-> false;
>    }
> }
>
> Is it even a valid usage of patterns? I think even the List interface would
> need to support pattern matching in this case.
>
> Regards
> Swaranga


From scolebourne at joda.org  Thu Jan 28 00:21:44 2021
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 28 Jan 2021 00:21:44 +0000
Subject: Pattern method names based on existing library conventions [was Re:
 Pattern matching for nested List with additional size constraints]
In-Reply-To: <ea9187bb-e33f-fc38-9497-33d80ebd5a2d@oracle.com>
References: <CAGZD2TCbAH+8NzaFfHqqzQQh18Xf2xCbvuzzpj_idH0caWhDzg@mail.gmail.com>
 <ea9187bb-e33f-fc38-9497-33d80ebd5a2d@oracle.com>
Message-ID: <CACzrW9CWTxv_L2ib6RykS7V23722Ojg6P2_3xo3mV8C062UmRA@mail.gmail.com>

On Wed, 27 Jan 2021 at 20:03, Brian Goetz <brian.goetz at oracle.com> wrote:
>       if (p instanceof Profile(Rules(List.of(var rule, ...)))) {...}

With my library design hat on, I don't think "of" is a suitable method
name here. "of" is strongly linked to creation, not extraction (see
also "valueOf" on some other classes). Looking further, I found three
different kinds pattern method that benefit from different treatment
at the use-site:


1) Factory methods that should be constructors

Some factory methods exist simply because a constructor was not an
acceptable alternative - LocalDate.of(int, int, int),
Integer.valueOf(int) and List.of(T...) being three examples for
different reasons. Given this, it seems desirable that the language
should allow *some* pattern methods to have a use-site syntax that
looks exactly like a deconstructor.

  if (p instanceof Profile(Rules(List(var rule, ...)))) {...}
  if (p instanceof LocalDate(var year, month, day)) { ..}
  if (p instanceof Integer(var value)) { ..}
  if (p instanceof Optional(var value)) { ..}
  if (p instanceof Optional()) { ..}
  for (Map.Entry(var key, var value) : map.entrySet() {...}

In all these situations, the binding is effectively taking the raw
contents and binding them, as records do, and that is what the
use-site syntax should be.


2) Extract everything and Transform.

This is where the inbound factory method performs a meaningful
transformation, not just a straightforward assignment. A typical
example is  `LocalDate.ofYearDay(int, int)` vs `LocalDate.of(int, int,
int)`. The pattern method will typically always match, but it doesn't
have to. Examples so far suggest these kind of transformation
factories would look like:

  if (p instanceof LocalDate.ofYearDay(var year, var dayOfYear)) { ..}

But I'm not creating a LocalDate, I'm extracting it.

It seems to me that there is already a method prefix that already
represents something like "extract and transform" - the method prefix
"as". eg. "I want the LocalDate as a YearDay"


3) Check and Extract.

This is like the `Rule.dynamic(var dc)` example in this thread, where
there is not always a match. Here, there are two distinct parts to the
problem - matching and extraction, but the existing proposed syntax
merges those two parts:

  if (p instanceof Map.withMapping(key)(var value)) {...}

Again, I don't think "withMapping" works well as a method name. Nor do
I believe this flows well when trying to read what it says.

But it seems to me that there is already a boolean method on Map that
performs the desired match. It is called `containsKey`. I believe this
will be true of the vast majority of pattern methods, eg.
`String.contains()`, `Class.isArray()` and many more. Typically these
are `isXxx()` methods.

So, my key observation is that pattern methods should be building on
the existing knowledge developers have of libraries by using these
existing boolean method names in patterns.


Proposal:

Pattern methods should be based on the *existing* method names
developers are already familiar with, with multi-step match & bind
where appropriate.

Instead of this:
  if (p instanceof LocalDate.ofYearDay(var year, var dayOfYear)) {...}
I propose:
  if (p instanceof LocalDate(asYearDay(var year, var dayOfYear)) { ..}

Instead of this:
  if (p instanceof Map.withMapping(key)(var value)) {...}
I propose:
  if (p instanceof Map(containsKey(key).get(var value)) {...}

the regex example:
  if (str instanceof matches(REGEX).groups(var match1, var match2)) { ..}

the JSON example:
switch (doc) {
    case hasKey("firstName").asString(var first) &
         hasKey("lastName").asString(var last) &
         hasKey("age").asInt(var age) &
         hasKey("address").asObject(
                 hasKey("city").asString(var city) &
                 hasKey("state").asString(var state)
         ) & ...
           -> ...
 }

and for the example from this thread:
  if (p instanceof Profile(Rules(List(isDynamic(var dc), ...))) {

Notes:
- the "as" method prefix is normally used when the match does not
fail, but doesn't have to
- the "is" method prefix is used when the match may fail
- this approach allows one pattern match method to have many different
associated pattern binding methods (in the first example, "get()" is
not special, it is just a method name)
- a combined match and bind pattern method is still allowed (the last
example, which is a bit like a cast)
- the JSON example is more like how a library writer might want to
separate the responsibilities (one method for "is there a key" and
many for "what type is it" which could perhaps throw with a meaningful
debug error)

Conceptually, `_.containsKey(key).get(var value)` can be thought of as
conjoined. A bit like a call to `containsKey` followed by a call to
`get` on the same target, but with some linked context. Of course, it
doesn't have to be implemented that way, but it is possible that the
declaration site might look something like:

 public class Map {
  public default pattern containsKey(K key).get(V value) ....
 }

with an implementation that just calls on to the existing two methods
of the same name.

Stephen

From david at livemedia.com.au  Thu Jan 28 06:38:28 2021
From: david at livemedia.com.au (David Ryan)
Date: Thu, 28 Jan 2021 17:38:28 +1100
Subject: Implementing Towards Better PEP/Serialization
In-Reply-To: <CAAO_P5pY2RMvkG=X0phT6xm+W4q8t-y_6J1FPoeLZKjPBHt7vg@mail.gmail.com>
References: <CAAO_P5qObUeGyPCAYYTUm=wOwuo=J0AFUWP_P-Ks9r1cQ47v6g@mail.gmail.com>
 <496af42b-5588-1b9f-c9bf-2d96146dc84f@oracle.com>
 <CAAO_P5pUU0DHU7+UOKnYzNEW7bKfG2Y6saNYhM_KwNFix776HQ@mail.gmail.com>
 <25A6FFA0-9D91-417D-9164-D5B24A140897@oracle.com>
 <CAAO_P5oADo6HvTyG=bpFxXY0803JJRP7qqXV_8=ze5mXCfaUmw@mail.gmail.com>
 <024E0732-BC90-4DE2-BC72-F5FC02185337@oracle.com>
 <CAAO_P5oY_LJbWecu797dybVrBZkZgm1ukG=hi=VwE+jXE=ocXg@mail.gmail.com>
 <9B84623F-BE3B-4B81-8133-9FBD65F8A033@oracle.com>
 <CAAO_P5p+buoTN7EKbTMDc1XaTDzO6aXL3570DvtX49=Q1LrxOQ@mail.gmail.com>
 <3c20bfba-9a45-0d35-fe79-e5cba724a863@oracle.com>
 <CAAO_P5ouEEfi_zbmF4O7=0gc9btO=fxKaXWm2EPuNMvhSiSE+A@mail.gmail.com>
 <BCAB330E-C556-418F-94DA-33A4FE4F3E45@oracle.com>
 <CAAO_P5ogdA=KgXRT=M0JBgzFd51Lgim7yswYJDhtxrOuG29CRA@mail.gmail.com>
 <CAAO_P5rGSL-phvGQwofFBFCnU3+ukL9n_WrM90N0SBBwgtOtiQ@mail.gmail.com>
 <8c170629-62b0-c664-425b-cb6df34aa699@oracle.com>
 <CAAO_P5p98v0U6ug-ES36JZzL=AvAWN-=ZGe-OA023tjwVwyzYg@mail.gmail.com>
 <4858dc10-82d4-c69e-8d43-748cdf021bfc@oracle.com>
 <CAAO_P5ogL3ieZ_BiSuRVUndUYTivH6XEuPeWw5a03WQkTi+_bQ@mail.gmail.com>
 <CAAfFNYHu+rGfP-B1WCmMOeb0jz3a2Y4ECn=KoBEZKa4bcGF0Zw@mail.gmail.com>
 <CAAfFNYFU=17Gqx8nLKDGqWe4dSKxXDAp9qG+rqJ0kou51roc4w@mail.gmail.com>
 <CAAO_P5pY2RMvkG=X0phT6xm+W4q8t-y_6J1FPoeLZKjPBHt7vg@mail.gmail.com>
Message-ID: <CAAO_P5p4qkfwWst41X_SWCNxVPED-yanEO3SwDsh4y1_x=LkYg@mail.gmail.com>

Over the last month or so I fell deeper into the rabbit hole of
serialization (if that were possible). When I was working on the language
PEP interface the question of finding "the ways that a class can be 'data'"
kept bugging me. This lead me down the path of asking what is data and what
are the ways that data structures can be specified. What was initially
going to be a review of different data and schema solutions turned into an
exercise of attempting to understand the concepts that underlie all
serialization. The output is a serialization theory document[1] where I've
documented what I could find regarding the science of serialization. I've
been in my own echo chamber writing this for the last month, so if anyone
could give me feedback or can point me to relevant papers written on the
subject of serialization, I'd like to hear it.

The main finding of this is that algebraic data types (product types and
sum types) are the basis of schema languages. They all have some form of
product type (record, sequence, struct) and Sum type (Choice, Union,
OneOf,|). For product types, each field will have a cardinality of
required, optional, or dynamic size(array). After you add in various atomic
types you cover 90% of serialization. The only other structural element I
could find is annotations (XML attributes are one example) but I haven't
found a good implementation of them.

This relates back to the original discussion regarding projected embedded
pairs from last year and finding how best to decomplect the various aspects
of serialization. The previous discussion was about finding function
pairs(to data/from data) for serialization. The current implementation I've
been working on forces all Java data classes through a homogenous record
style interface using method handles. More recently I added another meta
interface that provides a homogenous interface for array and collections.
The array interface uses the following method handle signatures:

   <ArrayType> constructor( int length );
   int size( <ArrayType> );
   <Iterator> iterator( <ArrayType> );
   void put( <Iterator>, <Array>, <Value> );
   <data> get( <Iterator> iterator, <Array> );

These signatures allow wrapping both Java array types and collections. The
only downside is that the size must be known prior to construction to
account for array implementations. The following examples of using the
array interface is taken from PepMapMapper[2] which serializes to/from a
Map:

  Object arrayData = object;
  int length = (int) arrayClass.size().invoke(arrayData);
  Object[] outputArray = new Object[length];
  Object iterator = arrayClass.iterator().invoke(arrayData);

  PepDataClass arrayDataClass = arrayClass.arrayDataClass();

  for (int x = 0; x < length; x++) {
     Object av = arrayClass.get().invoke(iterator, arrayData);
     outputArray[x] = toMap(arrayDataClass, av);
  }


Reading and constructing an array/collection:

  Object[] inputArray = (Object[]) data;

  int length = inputArray.length;
  Object arrayData = arrayClass.constructor().invoke(length);
  Object iterator = arrayClass.iterator().invoke(arrayData);

  PepDataClass arrayDataClass = arrayClass.arrayDataClass();

  for (int x = 0; x < length; x++) {
    arrayClass.put().invoke(iterator, arrayData, toObject(arrayDataClass,
inputArray[x]));
  }

With this, product types (records, etc) and Array/Collections are
implemented (of the four identified types). There's more work to
investigate how Sum types and annotations map to Java. But if you accept my
conclusions above regarding the reduced set of concepts in serialization
then the homogenous function pairs (to data/from data) for record, array,
annotation, and various atomic types will cover all scenarios. My
conclusion is that I've found all the ways data can be specified and now
finding the ways a class can be data is a lot easier to define and can be
incrementally added.

The next step is to investigate how new atomic types can be specified by
the same type system (allowing new atomic types to be added). A related
topic is to investigate how macros or lambdas might be relevant in
serialization specifications. I've got a feeling lambdas/macros could be
useful for data specifications, but I just haven't worked out how yet.

This is working towards a serialization model and format that encodes the
schema of types prior to first use in the stream. In my review of data
formats, it is interesting that Java's native serialization is the only
example of a popular format that does this. The plan is to have a binary
schema format that is extensible that allows both new atomic types and meta
types and allow dynamic type agreement/resolution between client/server
(this work was done in a previous implementation).

Finally, I think the relevance to Amber and this mailing list is feeling
well and truly tenous. I'm documenting my progress here[3], but won't post
any longer unless I think there's a higher degree of relevance. Thanks for
the input and feedback so far! Also, I'm currently looking for work if
anyone needs a serialization specialist. :)

Thanks,
David.

[1] https://github.com/litterat/litterat/blob/main/litterat-theory.md
[2]
https://github.com/litterat/litterat/blob/main/litterat-json/src/main/java/io/litterat/json/JsonMapper.java
[3] https://github.com/litterat/litterat/blob/main/100DaysOfCode.md

From brian.goetz at oracle.com  Thu Jan 28 16:40:00 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 28 Jan 2021 11:40:00 -0500
Subject: Pattern method names based on existing library conventions [was
 Re: Pattern matching for nested List with additional size constraints]
In-Reply-To: <CACzrW9CWTxv_L2ib6RykS7V23722Ojg6P2_3xo3mV8C062UmRA@mail.gmail.com>
References: <CAGZD2TCbAH+8NzaFfHqqzQQh18Xf2xCbvuzzpj_idH0caWhDzg@mail.gmail.com>
 <ea9187bb-e33f-fc38-9497-33d80ebd5a2d@oracle.com>
 <CACzrW9CWTxv_L2ib6RykS7V23722Ojg6P2_3xo3mV8C062UmRA@mail.gmail.com>
Message-ID: <5d3f83f0-e861-a57b-fcd9-0d30f5168c89@oracle.com>

This is all a great first attempt to navigate this new territory. Having 
spent a lot of time there already, there's some I agree with, and some 
for which I'd say "understandable first thought, but keep going."? It 
will surely take us a while to discover the ideal set of idioms for this 
new language, just as it did in the early days of Java.

If you don't read any further, the takeaway of all this is: patterns are 
not just "better getters", and our API design idioms should not merely 
be extrapolated from what worked with getters, but should reflect the 
richness of what patterns enable.? The old rules will encourage us 
towards some bad habits for the new world, and we should be on lookout 
for that.

> On Wed, 27 Jan 2021 at 20:03, Brian Goetz <brian.goetz at oracle.com> wrote:
>>        if (p instanceof Profile(Rules(List.of(var rule, ...)))) {...}
> With my library design hat on, I don't think "of" is a suitable method
> name here.

There are surely lots of possible library idioms, and I'm sure we've not 
thought of all of them yet, so its good to brainstorm about what some 
others might be.? For the record, here's the rationale behind this 
particular naming choice.

A key design goal for pattern matching in Java is that however you make 
an object, there is a complementary way to take it apart, and, absent a 
good reason to the contrary, that should be as syntactically and 
semantically similar as possible.

If we construct with constructor:

 ??? Foo f = new Foo(a);

we can take apart with the same-descriptor deconstructor:

 ??? if (f instanceof Foo(var a)) { ... }

If we construct with a factory:

 ??? Foo f = Foo.of(a);

we can take apart with the same-named, same-descriptor deconstructor:

 ??? if (f instanceof Foo.of(var a)) { ... }

or, perhaps a more evident example:

 ??? Optional<String> a = Optional.of(x);
 ??? Optional<String> b = Optional.empty();

 ??? switch (x) {
 ??????? case Optional.of(var x): ...
 ??????? case Optional.empty(): ...
 ??? }

In this case (heh), the library designer (hi!) chose to use factory 
methods _for the names_; the deconstruction benefits from the same thing.

(There are other forms of aggregation, which should have corresponding 
patterns -- array initializers and patterns, and eventually, if we ever 
have collection literals, we'll have corresponding collection patterns.)

A good intuition here when reading this might be: "if f could have come 
from invoking Foo.of(...), what parameters would have been provided?"

> 1) Factory methods that should be constructors
>
> Some factory methods exist simply because a constructor was not an
> acceptable alternative - LocalDate.of(int, int, int),
> Integer.valueOf(int) and List.of(T...) being three examples for
> different reasons. Given this, it seems desirable that the language
> should allow *some* pattern methods to have a use-site syntax that
> looks exactly like a deconstructor.
>
>    if (p instanceof Profile(Rules(List(var rule, ...)))) {...}
>    if (p instanceof LocalDate(var year, month, day)) { ..}
>    if (p instanceof Integer(var value)) { ..}
>    if (p instanceof Optional(var value)) { ..}
>    if (p instanceof Optional()) { ..}
>    for (Map.Entry(var key, var value) : map.entrySet() {...}
>
> In all these situations, the binding is effectively taking the raw
> contents and binding them, as records do, and that is what the
> use-site syntax should be.

I think this is overstated, but there's a reasonable design option (for 
*some* classes) buried in here.? Whether you provide a constructor or 
factory is an API design choice; similarly, whether you provide a 
corresponding deconstructor or static member pattern is also an API 
design choice.?? If you choose factories one way, but deconstructors the 
other, that's an asymmetry; there can be cases where such an asymmetry 
is justified, but in others will just be a gratuitous inconsistency, so 
there needs to be a corresponding benefit to make up for the asymmetry.

One of the benefits of factories over constructors is "could return a 
cached instance/subclass", which is not in play for deconstructors.? So 
if a class has _only_ one name of factory method (make, newFoo), I think 
the idiom of "deconstruct those with a deconstructor" might be a 
reasonable option, because deconstructors don't need this degree of 
flexibility, and the name chosen by the API designer isn't really adding 
any value, since they're all the same.? This goes especially so if the 
name is something like "make" rather than "of", since "of" worse fine in 
both directions, whereas "make" does not.

On the other hand, for classes that have multiple names of factories, 
the story is very different.? For example, deconstructing Optional with 
a pair of deconstructors would be a bad choice.?? The names in 
Optional.of / Optional.empty are *the whole point*, and add tremendously 
to the readability, so losing these is pretty bad (and the inconsistency 
of mechanism is just a dis-bonus.)? From a readability perspective, will 
it really be obvious that

 ??? case Optional():

means "empty optional" rather than "yep, its an optional"?? I don't 
think so -- we chose factories in part because names are useful. So, I 
think treating Optional this way would be be a truly bad move.

If we're trying? to extract rules, a candidate rule might be "if there's 
only likely to ever be one name of getter, and it is not suited for use 
in both directions, consider a deconstruction pattern instead."

> 2) Extract everything and Transform.
>
> This is where the inbound factory method performs a meaningful
> transformation, not just a straightforward assignment. A typical
> example is  `LocalDate.ofYearDay(int, int)` vs `LocalDate.of(int, int,
> int)`. The pattern method will typically always match, but it doesn't
> have to. Examples so far suggest these kind of transformation
> factories would look like:
>
>    if (p instanceof LocalDate.ofYearDay(var year, var dayOfYear)) { ..}
>
> But I'm not creating a LocalDate, I'm extracting it.

The pattern of mirroring the factory name depends a lot on how 
"bidirectional" the factory name is.? Some factory names are terrible 
this way ("make" or "newFoo"), and some are just fine ("of").? List.of() 
works well in both directions; "make me a list of these elements", vs 
"are you a list of things matching these patterns." Names like ofX or 
withX also are probably pretty good ("make me a Foo with mustard" / "are 
you a Foo with mustard").

Of course, pre-existing APIs that were designed before we knew patterns 
were coming might not have such reversible names; that's to be 
expected.? I suspect that, now that patterns are part of the language, 
we'll give more thought to whether names are reversible and will 
gravitate towards those names.? But pre-existing APIs might have to be 
more creative with their inverses.

But, I think its important to note that this is *a migration concern*, 
not a language design or "API style guide" issue; existing APIs that 
haven't left room for patterns (because, no one knew they were coming) 
should be, in the long run, the exception rather than the rule.? Let's 
not burden new APIs with compromises necessitated by old language 
limitations.? The old guidelines grew up relative to the old language; 
some of the considerations that were relevant in the old guidelines no 
longer apply.

A word of warning: the intuition of "I'm extracting, not creating" is 
probably pulling you in the wrong direction.? Of course its true, but we 
will be much better off when we design APIs that reflect the inherent 
round-tripping enabled by matched ctor/dtor (or factory/static pattern) 
pairs.? To the extent we are building APIs that can be taken apart with 
patterns, we should be striving to build APIs that are "symmetric" and 
"transparent".

I get how it is super-tempting to think of patterns as just being 
"better getters", and its true to a degree, but it is also missing a big 
part of the point.

<mathematical excursion>
This pairing appeals to the mathematical concepts of 
embedding-projection (alternately, adjunction).? The idea is that you 
have two domains A and B, and a pair of functions e : A->B and p: B->A.? 
Embedding appeals to going from a "smaller" domain to a bigger one; 
projection is the opposite.? Things we know about the smaller domain are 
true in the bigger one, and, if they can be projected from the bigger to 
the smaller, the opposite is also true.? Its allowable for the 
projection to throw away information, but not the reverse.? So composing 
e-then-p is an identity, and composing p-then-e is a "normalization" (or 
may not map a value).

As an example, consider int and Integer.? The latter is "one bigger" 
(null).? The embedding of int into Integer is obvious: new Integer(i).? 
The projection from Integer to int is similarly obvious: for non-null 
Integer, use Integer.intValue(), otherwise there's no mapping (NPE.)? 
You can go int -> Integer -> int as many times as you like, and end up 
where you start; once you go one hop in the other direction and don't 
fall off (Integer -> int), you can continue riding the merry-go-round.? 
And arithmetic is isomorphic in the two domains.

A richer example is the relationship between the pairs of integers (n, 
d) and a Rational class.? A well-behaved ctor/dtor pair (and similar for 
factory/pattern pair) forms an embedding-projection between these two 
domains; the Rational constructor might reject zero denominator, and 
might normalize numerator and denominator by factoring out GCD, but once 
this is done, the two domains ((n,d) pair, vs Rational object) behave 
identically and can be freely interconverted without further loss of 
information.? (Adhering to this behavior gives us, among other things, 
free marshalling to XML.)?? This is a behavior worth aspiring to.
</mathematical excursion>

> It seems to me that there is already a method prefix that already
> represents something like "extract and transform" - the method prefix
> "as". eg. "I want the LocalDate as a YearDay"

... in some particular APIs which some characteristics that already use 
certain naming conventions.?? Surely let's identify suitable conversions 
for migrating those, but let's not extrapolate too much from the APIs we 
built before we knew where we were going.? This is old-think; treating 
patterns as merely "better getters."? They're more than that.

> 3) Check and Extract.
>
> This is like the `Rule.dynamic(var dc)` example in this thread, where
> there is not always a match. Here, there are two distinct parts to the
> problem - matching and extraction, but the existing proposed syntax
> merges those two parts:
>
>    if (p instanceof Map.withMapping(key)(var value)) {...}
>
> Again, I don't think "withMapping" works well as a method name. Nor do
> I believe this flows well when trying to read what it says.

Again, I think this bothers you because you're still trying to think of 
a pattern as a "conditional multi-getter", rather than as a projection.? 
I will agree that `withMapping` is a little clunky, but it does work in 
both directions -- you could use it to make a map "with a given 
mapping", and identify whether a map is one "with a given mapping."

> But it seems to me that there is already a boolean method on Map that
> performs the desired match. It is called `containsKey`. I believe this
> will be true of the vast majority of pattern methods, eg.
> `String.contains()`, `Class.isArray()` and many more. Typically these
> are `isXxx()` methods.

I don't disagree that `containsKey` is a good name, or even a better 
name, for this pattern.? But, you might find it useful to know that I 
deliberately chose *not to* use containsKey in these examples -- because 
I was concerned it would play into exactly the wrong mental models for 
patterns that I've been pushing back on in this very mail, so I chose to 
stick with the more symmetric naming style for purposes of 
illustration.? So while in this case, I might actually agree that this 
is a better name, and might advocate for that in the end, I think that 
may be more the exception than the rule of borrowing from the old 
intuitions.? The old intuitions need to be set aside to make room for 
new ones, and then we can see what we want to keep of the old ones.

> So, my key observation is that pattern methods should be building on
> the existing knowledge developers have of libraries by using these
> existing boolean method names in patterns.

While I totally understand how you got here, I disagree with this almost 
completely.? This burdens a better tool with the compromises we had to 
make to make the bad old tools work.

The "almost" part is: existing patterns of API naming came from a 
reasonable thought process, and it might be reasonable to re-run some of 
that thought process in the context of the newer, more powerful language 
we have now, and some of those intuitions will be helpful in building 
symmetric / transparent / round-trippable APIs. But let's not try to 
cram patterns into the idioms we developed to approximate them.

In short: look ahead, not backwards.

> Proposal:

While I am sure that people will code as you have suggested in this 
proposal (for the same reason: seeking the comfort of the old rules), I 
think most of these would be seriously suboptimal choices.? They seem to 
mostly flow from "let's cram patterns into the mental model we have 
now", rather than broadening the model.

So, I think these are good first thoughts, just not the place we want to 
land.? My advice is: broaden your perspective, try to embrace the degree 
to which patterns are not "just" better getters, and iterate!? That's 
how we discover better API design idioms.



From brian.goetz at oracle.com  Thu Jan 28 19:19:10 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 28 Jan 2021 14:19:10 -0500
Subject: Feedback: Guards and static/instance pattern declarations
In-Reply-To: <CACzrW9Cueut29tXJQDh+H-eKW-ktSJ2Ly8yBdgaBUuJUOyFZpQ@mail.gmail.com>
References: <CACzrW9Cueut29tXJQDh+H-eKW-ktSJ2Ly8yBdgaBUuJUOyFZpQ@mail.gmail.com>
Message-ID: <be02d61b-ea8c-c2c4-9822-a4b27decd7ce@oracle.com>



On 1/24/2021 9:18 AM, Stephen Colebourne wrote:
> The semantic approach of turning boolean expressions into guard
> patterns seems reasonable. But it seems to me that the goal should be
> to integrate boolean expressions and patterns as completely as
> possible, rather than trying to make them disjoint. Currently:
>
> * the use of & is nasty given its meaning of evaluating both sides
> *  true(<booleanExpr>) and false(<booleanExpr>) seem like overkill
> ("new stuff wants to look new")
>
> // this is the current proposal
>   case NumBox(int i) & true(i == 0):
>   case NumBox(int i) & true(i > 6) & true(i < 10):
>
> // this seems much more desirable
>   case NumBox(0):
>   case NumBox(int i) && i > 6 && i < 10:
>   case NumBox(int i) && (i < 6 || i > 10):

Here's a more concrete example of where this approach starts to lose it 
when we get past trivial guards.?? If we try to interpret an arbitrary 
boolean expression as pattern, when it is the right operand of a && 
whose left operand is a pattern, what do we do with this:

 ???? t instanceof Foo(var x) && x instanceof Bar(var y) && Q:

`x instanceof Bar(var y)` is surely an allowable boolean expression, but 
now it is really not clear whether the user meant to match t to Foo(var 
x) and to Q, subject to the guard that x is a Bar(var y), or meant to do 
to separate instanceof tests, the second to "Bar(var Y) && Q".

So while in the trivial cases, I can see the desire to let the user be 
"sloppy" and use an expression where a pattern is expected,? and 
automatically make up the difference, when we get outside the trivial 
cases, it gets really hard to understand what the user means.? Instead, 
if we wrap the boolean in a guard:

 ??? t instanceof (Foo(var x) & true(x instanceof Bar(var y)) & Q)

the fact that there is a composite pattern with an embedded 
pattern-match guard becomes more obvious.



From duke at openjdk.java.net  Thu Jan 28 22:09:41 2021
From: duke at openjdk.java.net (duke)
Date: Thu, 28 Jan 2021 22:09:41 GMT
Subject: git: openjdk/amber: stats-before-this-super: 119 new changesets
Message-ID: <903fd7b9-32af-43e6-9de3-0190e6aa1e9e@openjdk.org>

Changeset: a7c2ebc7
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2021-01-22 00:21:36 +0000
URL:       https://git.openjdk.java.net/amber/commit/a7c2ebc7

8239894: Xserver crashes when the wrong high refresh rate is used

Reviewed-by: kizune

! src/java.desktop/unix/classes/sun/awt/X11GraphicsDevice.java
! src/java.desktop/unix/native/common/awt/systemscale/systemScale.c
! src/java.desktop/unix/native/common/awt/systemscale/systemScale.h
! src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c
! src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c

Changeset: 92c2f084
Author:    Phil Race <prr at openjdk.org>
Date:      2021-01-22 01:50:00 +0000
URL:       https://git.openjdk.java.net/amber/commit/92c2f084

8259869: [macOS] Remove desktop module dependencies on JNF Reference APIs

Reviewed-by: serb

! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTView.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.h
! src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CClipboard.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CDragSource.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CDragSourceContextPeer.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CDropTarget.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CDropTargetContextPeer.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CFileDialog.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CGraphicsEnv.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CInputMethod.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CMenuComponent.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CPopupMenu.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/CTrayIcon.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/ImageSurfaceData.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaAccessibilityAction.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/JavaComponentAccessibility.m
! src/java.desktop/macosx/native/libawt_lwawt/awt/PrinterView.m
! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLLayer.h
! src/java.desktop/macosx/native/libawt_lwawt/java2d/opengl/CGLLayer.m
! src/java.desktop/macosx/native/libosxui/ScreenMenu.m

Changeset: ba386615
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2021-01-22 04:20:41 +0000
URL:       https://git.openjdk.java.net/amber/commit/ba386615

8259882: Reduce the inclusion of perfData.hpp

Reviewed-by: redestad, coleenp

! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/classLoader.hpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/compiler/compileBroker.hpp
! src/hotspot/share/gc/epsilon/epsilonMonitoringSupport.cpp
! src/hotspot/share/gc/shared/ageTable.cpp
! src/hotspot/share/gc/shared/ageTable.hpp
! src/hotspot/share/gc/shared/collectedHeap.cpp
! src/hotspot/share/gc/shared/collectedHeap.hpp
! src/hotspot/share/gc/shared/generationCounters.cpp
! src/hotspot/share/gc/shared/generationCounters.hpp
! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp
! src/hotspot/share/gc/shared/threadLocalAllocBuffer.hpp
! src/hotspot/share/runtime/arguments.hpp
! src/hotspot/share/runtime/objectMonitor.cpp
! src/hotspot/share/runtime/objectMonitor.hpp
! src/hotspot/share/runtime/perfData.hpp
+ src/hotspot/share/runtime/perfDataTypes.hpp
! src/hotspot/share/runtime/synchronizer.cpp
! src/hotspot/share/runtime/synchronizer.hpp
! src/hotspot/share/runtime/vmThread.cpp
! src/hotspot/share/runtime/vmThread.hpp
! src/hotspot/share/services/management.hpp

Changeset: a70acf2c
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-22 07:05:30 +0000
URL:       https://git.openjdk.java.net/amber/commit/a70acf2c

8259928: compiler/jvmci tests fail with -Xint

Reviewed-by: kvn, iignatyev

! test/jtreg-ext/requires/VMProps.java

Changeset: 14522800
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2021-01-22 08:02:56 +0000
URL:       https://git.openjdk.java.net/amber/commit/14522800

8164484: Unity, JTable cell editor, javax/swing/JComboBox/6559152/bug6559152.java

Reviewed-by: serb, jdv

! test/jdk/ProblemList.txt
! test/jdk/javax/swing/JComboBox/6559152/bug6559152.java

Changeset: d066f2b0
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2021-01-22 09:00:56 +0000
URL:       https://git.openjdk.java.net/amber/commit/d066f2b0

8260030: Improve stringStream buffer handling

Reviewed-by: iklam, kbarrett

! src/hotspot/share/utilities/ostream.cpp
! src/hotspot/share/utilities/ostream.hpp
! test/hotspot/gtest/utilities/test_ostream.cpp

Changeset: 58ceb254
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2021-01-22 11:27:13 +0000
URL:       https://git.openjdk.java.net/amber/commit/58ceb254

8259842: Remove Result cache from StringCoding

Reviewed-by: naoto, plevart, rriggs

! src/java.base/share/classes/java/lang/String.java
! src/java.base/share/classes/java/lang/StringCoding.java
! src/java.base/share/classes/java/lang/System.java
+ test/micro/org/openjdk/bench/java/lang/StringDecode.java
+ test/micro/org/openjdk/bench/java/lang/StringEncode.java

Changeset: bfac3fb5
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-22 11:39:16 +0000
URL:       https://git.openjdk.java.net/amber/commit/bfac3fb5

8260212: Shenandoah: resolve-only UpdateRefsMode is not used

Reviewed-by: rkennke, zgu

! src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.hpp

Changeset: 7ed8ba1c
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2021-01-22 13:12:39 +0000
URL:       https://git.openjdk.java.net/amber/commit/7ed8ba1c

8256814: WeakProcessorPhases may be redundant

Remove WeakProcessorPhase, adding scoped enum categories to OopStorageSet.

Reviewed-by: stefank, tschatzl, rkennke

! src/hotspot/share/gc/g1/g1FullGCAdjustTask.hpp
! src/hotspot/share/gc/g1/g1GCPhaseTimes.cpp
! src/hotspot/share/gc/g1/g1GCPhaseTimes.hpp
! src/hotspot/share/gc/g1/g1RootProcessor.cpp
! src/hotspot/share/gc/shared/oopStorageSet.cpp
! src/hotspot/share/gc/shared/oopStorageSet.hpp
! src/hotspot/share/gc/shared/oopStorageSet.inline.hpp
! src/hotspot/share/gc/shared/oopStorageSetParState.hpp
! src/hotspot/share/gc/shared/oopStorageSetParState.inline.hpp
! src/hotspot/share/gc/shared/weakProcessor.cpp
! src/hotspot/share/gc/shared/weakProcessor.hpp
! src/hotspot/share/gc/shared/weakProcessor.inline.hpp
- src/hotspot/share/gc/shared/weakProcessorPhase.hpp
- src/hotspot/share/gc/shared/weakProcessorPhaseTimes.cpp
- src/hotspot/share/gc/shared/weakProcessorPhaseTimes.hpp
+ src/hotspot/share/gc/shared/weakProcessorTimes.cpp
+ src/hotspot/share/gc/shared/weakProcessorTimes.hpp
! src/hotspot/share/gc/shenandoah/shenandoahParallelCleaning.hpp
! src/hotspot/share/gc/shenandoah/shenandoahRootVerifier.cpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.hpp
! src/hotspot/share/jfr/leakprofiler/checkpoint/rootResolver.cpp
! src/hotspot/share/jfr/leakprofiler/utilities/rootType.cpp
! src/hotspot/share/jfr/leakprofiler/utilities/rootType.hpp
! src/hotspot/share/runtime/serviceThread.cpp
! test/hotspot/gtest/gc/shared/test_oopStorageSet.cpp

Changeset: f928265e
Author:    Harold Seigel <hseigel at openjdk.org>
Date:      2021-01-22 13:52:05 +0000
URL:       https://git.openjdk.java.net/amber/commit/f928265e

8260009: InstanceKlass::has_as_permitted_subclass() fails if subclass was redefined

Reviewed-by: lfoltan, sspitsyn, dholmes

! src/hotspot/share/oops/instanceKlass.cpp
+ test/hotspot/jtreg/runtime/sealedClasses/RedefinePermittedSubclass.java

Changeset: acbcde8c
Author:    Pankaj Bansal <pbansal at openjdk.org>
Date:      2021-01-22 13:53:36 +0000
URL:       https://git.openjdk.java.net/amber/commit/acbcde8c

8256111: Create implementation for NSAccessibilityStaticText protocol

Reviewed-by: serb, kizune

! src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonComponentAccessibility.m
+ src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonTextAccessibility.h
+ src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/CommonTextAccessibility.m
+ src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/StaticTextAccessibility.h
+ src/java.desktop/macosx/native/libawt_lwawt/awt/a11y/StaticTextAccessibility.m

Changeset: 154e1d63
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2021-01-22 14:16:29 +0000
URL:       https://git.openjdk.java.net/amber/commit/154e1d63

8259009: G1 heap summary should be shown in "Heap Parameters" window on HSDB

Reviewed-by: cjplummer, tschatzl

! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/g1/G1CollectedHeap.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/tools/HeapSummary.java

Changeset: a97f3c18
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2021-01-22 14:44:35 +0000
URL:       https://git.openjdk.java.net/amber/commit/a97f3c18

8258853: Support separate function declaration and definition with ENABLE_IF-based SFINAE

Add ENABLE_IF_SDEFN, unit tests

Reviewed-by: jrose, eosterlund

! src/hotspot/share/metaprogramming/enableIf.hpp
! test/hotspot/gtest/metaprogramming/test_enableIf.cpp

Changeset: 18eb6d9e
Author:    Sean Coffey <coffeys at openjdk.org>
Date:      2021-01-22 15:31:35 +0000
URL:       https://git.openjdk.java.net/amber/commit/18eb6d9e

8255348: NPE in PKIXCertPathValidator event logging code

Reviewed-by: mullan

! src/java.base/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java
! test/jdk/jdk/jfr/event/security/TestX509CertificateEvent.java
! test/jdk/jdk/jfr/event/security/TestX509ValidationEvent.java
! test/jdk/jdk/security/logging/TestX509CertificateLog.java
! test/jdk/jdk/security/logging/TestX509ValidationLog.java
! test/lib/jdk/test/lib/security/TestCertificate.java

Changeset: 0ea58626
Author:    Guoxiong Li <lgxbslgx at gmail.com>
Committer: Maurizio Cimadamore <mcimadamore at openjdk.org>
Date:      2021-01-22 15:47:05 +0000
URL:       https://git.openjdk.java.net/amber/commit/0ea58626

8260053: Optimize Tokens' use of Names

Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/Tokens.java

Changeset: bf5e8015
Author:    Johannes Kuhn <info at j-kuhn.de>
Committer: Mandy Chung <mchung at openjdk.org>
Date:      2021-01-22 17:18:06 +0000
URL:       https://git.openjdk.java.net/amber/commit/bf5e8015

8259922: MethodHandles.collectArguments does not throw IAE if pos is outside the arity range

Reviewed-by: mchung

! src/java.base/share/classes/java/lang/invoke/MethodHandles.java
+ test/jdk/java/lang/invoke/MethodHandlesCollectArgsTest.java

Changeset: c5ad713e
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-22 17:19:33 +0000
URL:       https://git.openjdk.java.net/amber/commit/c5ad713e

8260250: Duplicate check in DebugInformationRecorder::recorders_frozen

Reviewed-by: iveresov, thartmann

! src/hotspot/share/code/debugInfoRec.cpp

Changeset: 874aef4a
Author:    Alexey Bakhtin <abakhtin at openjdk.org>
Committer: Daniel Fuchs <dfuchs at openjdk.org>
Date:      2021-01-22 18:21:59 +0000
URL:       https://git.openjdk.java.net/amber/commit/874aef4a

8259707: LDAP channel binding does not work with StartTLS extension

Reviewed-by: mullan, dfuchs, aefimov

! src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java
! src/java.naming/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java

Changeset: a8871776
Author:    Stuart Marks <smarks at openjdk.org>
Date:      2021-01-22 18:51:32 +0000
URL:       https://git.openjdk.java.net/amber/commit/a8871776

8246788: ZoneRules invariants can be broken

Reviewed-by: rriggs, naoto

! src/java.base/share/classes/java/time/zone/ZoneRules.java
+ test/jdk/java/time/test/java/time/zone/TestMutableZoneRules.java

Changeset: 53fecba7
Author:    Dmitry Markov <dmarkov at openjdk.org>
Date:      2021-01-22 19:21:10 +0000
URL:       https://git.openjdk.java.net/amber/commit/53fecba7

8258805: Japanese characters not entered by mouse click on Windows 10

Reviewed-by: aivanov

! src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java

Changeset: 5aca934c
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-22 19:21:45 +0000
URL:       https://git.openjdk.java.net/amber/commit/5aca934c

8260304: (se) EPollSelectorImpl wakeup mechanism broken on Linux 32-bit

Reviewed-by: bpb, alanb

! src/java.base/linux/native/libnio/ch/EventFD.c

Changeset: 7be9113b
Author:    Dan Lemmond <dlemmond at amazon.com>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2021-01-22 20:33:44 +0000
URL:       https://git.openjdk.java.net/amber/commit/7be9113b

8255216: Change _directive->BreakAtCompileOption to env()->break_at_compile()

Reviewed-by: kvn, phh

! src/hotspot/share/c1/c1_Compilation.cpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/opto/compile.cpp

Changeset: bdc305e1
Author:    Alex Menkov <amenkov at openjdk.org>
Date:      2021-01-22 21:33:02 +0000
URL:       https://git.openjdk.java.net/amber/commit/bdc305e1

8258917: NativeMemoryTracking is handled by launcher inconsistenly

Reviewed-by: zgu

! src/java.base/share/native/libjli/java.c
! test/jdk/tools/launcher/TestSpecialArgs.java

Changeset: aa57d07c
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2021-01-22 22:47:08 +0000
URL:       https://git.openjdk.java.net/amber/commit/aa57d07c

8259214: MetaspaceClosure support for Arrays of MetaspaceObj

Reviewed-by: fparain, ccheung

! src/hotspot/share/memory/metaspaceClosure.hpp
+ test/hotspot/gtest/utilities/test_metaspaceClosure.cpp

Changeset: a5367cbb
Author:    Brian Burkhalter <bpb at openjdk.org>
Committer: Henry Jen <henryjen at openjdk.org>
Date:      2020-07-29 09:52:13 +0000
URL:       https://git.openjdk.java.net/amber/commit/a5367cbb

8247619: Improve Direct Buffering of Characters

Reviewed-by: alanb, ahgross, rhalade, psandoz

! src/java.base/share/classes/java/nio/Buffer.java
! src/java.base/share/classes/java/nio/Heap-X-Buffer.java.template
! src/java.base/share/classes/java/nio/X-Buffer.java.template

Changeset: 62eab505
Author:    Weijun Wang <weijun at openjdk.org>
Committer: Henry Jen <henryjen at openjdk.org>
Date:      2020-10-23 13:00:08 +0000
URL:       https://git.openjdk.java.net/amber/commit/62eab505

8255199: Catching a few NumberFormatExceptions in xmldsig

Reviewed-by: rhalade

! src/java.xml.crypto/share/classes/com/sun/org/apache/xml/internal/security/utils/RFC2253Parser.java
! src/java.xml.crypto/share/classes/org/jcp/xml/dsig/internal/dom/DOMHMACSignatureMethod.java

Changeset: ede1beae
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2021-01-21 18:21:07 +0000
URL:       https://git.openjdk.java.net/amber/commit/ede1beae

8227695: assert(pss->trim_ticks().seconds() == 0.0) failed: Unexpected partial trimming during evacuation

Change FP comparison to integer comparison.

Reviewed-by: kbarrett, iwalulya, eosterlund

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp

Changeset: d90e06af
Author:    Jie Fu <jiefu at openjdk.org>
Date:      2021-01-22 00:13:58 +0000
URL:       https://git.openjdk.java.net/amber/commit/d90e06af

8259775: [Vector API] Incorrect code-gen for VectorReinterpret operation

Reviewed-by: rbackman, neliasso, kvn

! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/x86.ad
+ test/hotspot/jtreg/compiler/vectorapi/VectorReinterpretTest.java

Changeset: 685c03dc
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2021-01-22 11:20:52 +0000
URL:       https://git.openjdk.java.net/amber/commit/685c03dc

8259271: gc/parallel/TestDynShrinkHeap.java still fails "assert(covered_region.contains(new_memregion)) failed: new region is not in covered_region"

Use load_acquire to order reads of top and end.

Reviewed-by: tschatzl, iwalulya, eosterlund

! src/hotspot/share/gc/parallel/mutableSpace.cpp

Changeset: 6f2a3943
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
Date:      2021-01-23 03:15:43 +0000
URL:       https://git.openjdk.java.net/amber/commit/6f2a3943

Merge

! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/x86.ad
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/java.base/share/classes/java/nio/X-Buffer.java.template
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/x86.ad
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/java.base/share/classes/java/nio/X-Buffer.java.template

Changeset: 5cdcce1c
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2021-01-23 06:24:22 +0000
URL:       https://git.openjdk.java.net/amber/commit/5cdcce1c

8260307: Do not include method.hpp in frame.hpp

Reviewed-by: lfoltan, coleenp

! src/hotspot/cpu/arm/interp_masm_arm.hpp
! src/hotspot/cpu/x86/interp_masm_x86.hpp
! src/hotspot/share/ci/ciInstanceKlass.hpp
! src/hotspot/share/ci/ciMethod.hpp
! src/hotspot/share/classfile/resolutionErrors.cpp
! src/hotspot/share/code/compiledMethod.hpp
! src/hotspot/share/compiler/methodMatcher.cpp
! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp
! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp
! src/hotspot/share/interpreter/abstractInterpreter.hpp
! src/hotspot/share/jvmci/jvmci_globals.cpp
! src/hotspot/share/memory/metaspace.cpp
! src/hotspot/share/memory/metaspace/printMetaspaceInfoKlassClosure.cpp
! src/hotspot/share/memory/metaspaceCounters.cpp
! src/hotspot/share/oops/methodCounters.cpp
! src/hotspot/share/prims/jvmtiExport.hpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/deoptimization.hpp
! src/hotspot/share/runtime/frame.hpp
! src/hotspot/share/runtime/handles.cpp
! src/hotspot/share/runtime/thread.hpp

Changeset: f624dba6
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2021-01-23 11:38:00 +0000
URL:       https://git.openjdk.java.net/amber/commit/f624dba6

8240247: No longer need to wrap files with contentContainer

Reviewed-by: serb

! src/java.desktop/share/classes/java/awt/doc-files/AWTThreadIssues.html
! src/java.desktop/share/classes/java/awt/doc-files/DesktopProperties.html
! src/java.desktop/share/classes/java/awt/doc-files/FocusSpec.html
! src/java.desktop/share/classes/java/awt/doc-files/Modality.html
! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/bmp_metadata.html
! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html
! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/jpeg_metadata.html
! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/png_metadata.html
! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/standard_metadata.html
! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html
! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/wbmp_metadata.html
! src/java.desktop/share/classes/javax/swing/plaf/multi/doc-files/multi_tsc.html
! src/java.desktop/share/classes/javax/swing/plaf/nimbus/doc-files/properties.html
! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html
! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html

Changeset: b53d5cac
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2021-01-23 17:03:09 +0000
URL:       https://git.openjdk.java.net/amber/commit/b53d5cac

8260315: Typo "focul" instead of "focus" in FocusSpec.html

Reviewed-by: kizune, pbansal

! src/java.desktop/share/classes/java/awt/doc-files/FocusSpec.html

Changeset: 6c4c96fa
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2021-01-23 19:47:24 +0000
URL:       https://git.openjdk.java.net/amber/commit/6c4c96fa

8258742: Move PtrQueue reset to PtrQueueSet subclasses

Reviewed-by: tschatzl, iwalulya

! src/hotspot/share/gc/g1/g1BarrierSet.cpp
! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1DirtyCardQueue.cpp
! src/hotspot/share/gc/shared/ptrQueue.cpp
! src/hotspot/share/gc/shared/ptrQueue.hpp
! src/hotspot/share/gc/shared/satbMarkQueue.cpp
! src/hotspot/share/gc/shared/satbMarkQueue.hpp
! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp

Changeset: 06348dfc
Author:    Kim Barrett <kbarrett at openjdk.org>
Date:      2021-01-23 22:47:31 +0000
URL:       https://git.openjdk.java.net/amber/commit/06348dfc

8259776: Remove ParallelGC non-CAS oldgen allocation

Reviewed-by: tschatzl, sjohanss

! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp
! src/hotspot/share/gc/parallel/mutableNUMASpace.hpp
! src/hotspot/share/gc/parallel/mutableSpace.cpp
! src/hotspot/share/gc/parallel/mutableSpace.hpp
! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp
! src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp
! src/hotspot/share/gc/parallel/psOldGen.cpp
! src/hotspot/share/gc/parallel/psOldGen.hpp
! src/hotspot/share/gc/parallel/psPromotionManager.inline.hpp
! src/hotspot/share/gc/parallel/psYoungGen.hpp

Changeset: 535c2927
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2021-01-24 02:40:57 +0000
URL:       https://git.openjdk.java.net/amber/commit/535c2927

8260306: Do not include osThread.hpp in thread.hpp

Reviewed-by: coleenp, lfoltan

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/os/posix/os_posix.cpp
! src/hotspot/share/gc/shared/threadLocalAllocBuffer.inline.hpp
! src/hotspot/share/interpreter/bytecodeTracer.cpp
! src/hotspot/share/jfr/support/jfrThreadId.hpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/jvmtiEnvBase.cpp
! src/hotspot/share/prims/jvmtiExport.cpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/objectMonitor.inline.hpp
! src/hotspot/share/runtime/os.cpp
! src/hotspot/share/runtime/osThread.hpp
! src/hotspot/share/runtime/safepointMechanism.cpp
! src/hotspot/share/runtime/semaphore.inline.hpp
! src/hotspot/share/runtime/stackWatermark.cpp
! src/hotspot/share/runtime/thread.hpp
! src/hotspot/share/runtime/vframe.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/hotspot/share/utilities/vmError.cpp

Changeset: c52c6c66
Author:    Hamlin Li <mli at openjdk.org>
Date:      2021-01-25 01:05:40 +0000
URL:       https://git.openjdk.java.net/amber/commit/c52c6c66

8260273: DataOutputStream writeChars optimization

Reviewed-by: rriggs, bpb, alanb

! src/java.base/share/classes/java/io/DataOutputStream.java
! test/micro/org/openjdk/bench/java/io/DataOutputStreamTest.java

Changeset: 4ae39b14
Author:    Hamlin Li <mli at openjdk.org>
Date:      2021-01-25 01:06:33 +0000
URL:       https://git.openjdk.java.net/amber/commit/4ae39b14

8260208: Improve dummy object filling condition in G1CollectedHeap::fill_archive_regions in cds

Reviewed-by: tschatzl, iklam

! src/hotspot/share/gc/g1/g1CollectedHeap.cpp

Changeset: 764111ff
Author:    Dongbo He <dongbohe at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
Date:      2021-01-25 01:08:38 +0000
URL:       https://git.openjdk.java.net/amber/commit/764111ff

8260272: bash configure --prefix does not work after JDK-8257679

Reviewed-by: erikj, ihse

! make/autoconf/util_paths.m4

Changeset: 5898ab65
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2021-01-25 08:00:40 +0000
URL:       https://git.openjdk.java.net/amber/commit/5898ab65

8259894: refactor parts of jvm.h into jvm_io.h and jvm_constants.h

Reviewed-by: dholmes, coleenp

! src/hotspot/os/windows/os_perf_windows.cpp
! src/hotspot/share/ci/ciFlags.hpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/vmIntrinsics.cpp
! src/hotspot/share/include/jvm.h
+ src/hotspot/share/include/jvm_constants.h
+ src/hotspot/share/include/jvm_io.h
! src/hotspot/share/logging/logSelection.cpp
! src/hotspot/share/prims/stackwalk.hpp
! src/hotspot/share/runtime/abstract_vm_version.cpp
! src/hotspot/share/runtime/flags/jvmFlag.cpp
! src/hotspot/share/runtime/os.hpp
! src/hotspot/share/utilities/accessFlags.hpp
! src/hotspot/share/utilities/constantTag.hpp
! src/hotspot/share/utilities/formatBuffer.hpp
! test/hotspot/gtest/logging/test_gcTraceTime.cpp
! test/hotspot/gtest/logging/test_logStream.cpp

Changeset: d825339d
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2021-01-25 08:38:47 +0000
URL:       https://git.openjdk.java.net/amber/commit/d825339d

8260263: Remove PtrQueue::_qset

Remove dead code related to PtrQueue::_qset and itself.

Reviewed-by: kbarrett, sjohanss

! src/hotspot/share/gc/g1/g1DirtyCardQueue.hpp
! src/hotspot/share/gc/shared/ptrQueue.cpp
! src/hotspot/share/gc/shared/ptrQueue.hpp
! src/hotspot/share/gc/shared/satbMarkQueue.hpp

Changeset: af155fc0
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2021-01-25 08:57:56 +0000
URL:       https://git.openjdk.java.net/amber/commit/af155fc0

8258836: JNI local refs exceed capacity getDiagnosticCommandInfo

Reviewed-by: cjplummer, shade

! src/jdk.management/share/native/libmanagement_ext/DiagnosticCommandImpl.c
+ test/jdk/com/sun/management/DiagnosticCommandMBean/DcmdMBeanTestCheckJni.java

Changeset: 09489e28
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2021-01-25 09:12:49 +0000
URL:       https://git.openjdk.java.net/amber/commit/09489e28

8260338: Some fields in HaltNode is not cloned

Reviewed-by: xliu, neliasso, thartmann

! src/hotspot/share/opto/rootnode.cpp
! src/hotspot/share/opto/rootnode.hpp

Changeset: ca20c63c
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2021-01-25 10:50:39 +0000
URL:       https://git.openjdk.java.net/amber/commit/ca20c63c

8259710: Inlining trace leaks memory

Reviewed-by: thartmann, neliasso

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp

Changeset: 6e037354
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2021-01-25 13:40:43 +0000
URL:       https://git.openjdk.java.net/amber/commit/6e037354

8259845: Move placeholder implementation details to cpp file and add logging

Reviewed-by: iklam, lfoltan, dholmes

! src/hotspot/share/classfile/placeholders.cpp
! src/hotspot/share/classfile/placeholders.hpp
! src/hotspot/share/logging/logTag.hpp

Changeset: d076977d
Author:    Eric Caspole <ecaspole at openjdk.org>
Date:      2021-01-25 14:11:33 +0000
URL:       https://git.openjdk.java.net/amber/commit/d076977d

8260169: LogCompilation: Unexpected method mismatch

Reviewed-by: kvn, vlivanov

! src/utils/LogCompilation/src/main/java/com/sun/hotspot/tools/compiler/LogParser.java
! src/utils/LogCompilation/src/test/java/com/sun/hotspot/tools/compiler/TestLogCompilation.java

Changeset: ef247ab2
Author:    Dan Lutker <lutkerd at amazon.com>
Committer: Igor Ignatyev <iignatyev at openjdk.org>
Date:      2021-01-25 17:16:21 +0000
URL:       https://git.openjdk.java.net/amber/commit/ef247ab2

8260308: Update LogCompilation junit to 4.13.1

Reviewed-by: ecaspole, iignatyev

! src/utils/LogCompilation/pom.xml

Changeset: 47c7dc77
Author:    Martin Balao <mbalao at openjdk.org>
Date:      2021-01-25 18:01:59 +0000
URL:       https://git.openjdk.java.net/amber/commit/47c7dc77

8258833: Cancel multi-part cipher operations in SunPKCS11 after failures

Reviewed-by: valeriep

! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11AEADCipher.java
! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Cipher.java
! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Mac.java
! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11PSSSignature.java
! src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Signature.java
+ test/jdk/sun/security/pkcs11/Cipher/CancelMultipart.java

Changeset: 5b0b24b5
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2021-01-25 18:20:21 +0000
URL:       https://git.openjdk.java.net/amber/commit/5b0b24b5

8260381: ProblemList com/sun/management/DiagnosticCommandMBean/DcmdMBeanTestCheckJni.java on Win with ZGC

Reviewed-by: sspitsyn, sgehwolf

! test/jdk/ProblemList-zgc.txt

Changeset: 73c78c8a
Author:    Joe Darcy <darcy at openjdk.org>
Date:      2021-01-25 19:06:56 +0000
URL:       https://git.openjdk.java.net/amber/commit/73c78c8a

8260329: Update references to TAOCP to latest edition

Reviewed-by: alanb, bpb

! src/java.base/share/classes/java/math/MutableBigInteger.java
! src/java.base/share/classes/java/util/Random.java

Changeset: 12ccd211
Author:    Andrew Leonard <aleonard at openjdk.org>
Date:      2021-01-25 19:26:36 +0000
URL:       https://git.openjdk.java.net/amber/commit/12ccd211

8260289: Unable to customize module lists after change JDK-8258411

Reviewed-by: ihse, alanb

! make/common/Modules.gmk

Changeset: d6fb9d72
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2021-01-25 21:44:58 +0000
URL:       https://git.openjdk.java.net/amber/commit/d6fb9d72

8255464: Cannot access ModuleTree in a CompilationUnitTree

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/source/tree/CompilationUnitTree.java
! src/jdk.compiler/share/classes/com/sun/source/util/TreeScanner.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/JCTree.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/tree/Pretty.java
+ test/langtools/tools/javac/tree/CompilationUnitTreeTest.java

Changeset: 982e42b8
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2021-01-25 21:45:54 +0000
URL:       https://git.openjdk.java.net/amber/commit/982e42b8

8259726: Use of HashSet leads to undefined order in test output

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Table.java
! test/langtools/jdk/javadoc/doclet/testAbstractMethod/TestAbstractMethod.java
! test/langtools/jdk/javadoc/doclet/testDeprecatedDocs/TestDeprecatedDocs.java
! test/langtools/jdk/javadoc/doclet/testHtmlTableTags/TestHtmlTableTags.java
! test/langtools/jdk/javadoc/doclet/testInterface/TestInterface.java
! test/langtools/jdk/javadoc/doclet/testJavaFX/TestJavaFX.java
! test/langtools/jdk/javadoc/doclet/testLambdaFeature/TestLambdaFeature.java
! test/langtools/jdk/javadoc/doclet/testMemberInheritance/TestMemberInheritance.java
! test/langtools/jdk/javadoc/doclet/testMemberSummary/TestMemberSummary.java
! test/langtools/jdk/javadoc/doclet/testMethodTypes/TestMethodTypes.java
! test/langtools/jdk/javadoc/doclet/testModules/TestModulePackages.java
! test/langtools/jdk/javadoc/doclet/testModules/TestModules.java
! test/langtools/jdk/javadoc/doclet/testNewLanguageFeatures/TestNewLanguageFeatures.java
! test/langtools/jdk/javadoc/doclet/testOverriddenMethods/TestOverrideMethods.java
! test/langtools/jdk/javadoc/doclet/testProperty/TestProperty.java
! test/langtools/jdk/javadoc/doclet/testTypeAnnotations/TestTypeAnnotations.java
! test/langtools/jdk/javadoc/doclet/testTypeParams/TestTypeParameters.java
! test/langtools/jdk/javadoc/doclet/testUnnamedPackage/TestUnnamedPackage.java

Changeset: 9ea93238
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2021-01-25 23:58:33 +0000
URL:       https://git.openjdk.java.net/amber/commit/9ea93238

8254246: SymbolHashMapEntry wastes space

Reviewed-by: redestad

! src/hotspot/share/oops/constantPool.hpp

Changeset: c538cd8b
Author:    Serguei Spitsyn <sspitsyn at openjdk.org>
Date:      2021-01-26 07:15:50 +0000
URL:       https://git.openjdk.java.net/amber/commit/c538cd8b

8165276: Spec states to invoke the premain method in an agent class if it's public but implementation differs

Reviewed-by: mchung, dholmes, alanb

! src/java.instrument/share/classes/sun/instrument/InstrumentationImpl.java
+ test/jdk/java/lang/instrument/NegativeAgentRunner.java
! test/jdk/java/lang/instrument/PremainClass/InheritAgent0001.java
! test/jdk/java/lang/instrument/PremainClass/InheritAgent0010.java
! test/jdk/java/lang/instrument/PremainClass/InheritAgent0011.java
! test/jdk/java/lang/instrument/PremainClass/InheritAgent0100.java
! test/jdk/java/lang/instrument/PremainClass/InheritAgent0101.java
! test/jdk/java/lang/instrument/PremainClass/InheritAgent0110.java
! test/jdk/java/lang/instrument/PremainClass/InheritAgent0111.java
! test/jdk/java/lang/instrument/PremainClass/InheritAgent1000.java
! test/jdk/java/lang/instrument/PremainClass/InheritAgent1001.java
! test/jdk/java/lang/instrument/PremainClass/InheritAgent1010.java
! test/jdk/java/lang/instrument/PremainClass/InheritAgent1011.java
! test/jdk/java/lang/instrument/PremainClass/InheritAgent1100.java
! test/jdk/java/lang/instrument/PremainClass/InheritAgent1101.java
! test/jdk/java/lang/instrument/PremainClass/InheritAgent1110.java
! test/jdk/java/lang/instrument/PremainClass/InheritAgent1111.java
! test/jdk/java/lang/instrument/PremainClass/NoPremainAgent.java
- test/jdk/java/lang/instrument/PremainClass/NoPremainAgentTest.java
+ test/jdk/java/lang/instrument/PremainClass/NonPublicAgent.java
+ test/jdk/java/lang/instrument/PremainClass/NonPublicPremainAgent.java
! test/jdk/java/lang/instrument/PremainClass/ZeroArgPremainAgent.java
- test/jdk/java/lang/instrument/PremainClass/ZeroArgPremainAgentTest.java

Changeset: abd9310b
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2021-01-26 07:42:15 +0000
URL:       https://git.openjdk.java.net/amber/commit/abd9310b

8260222: remove unused _thread member SymbolTableLookup

Reviewed-by: coleenp, dholmes, shade

! src/hotspot/share/classfile/symbolTable.cpp

Changeset: 23edb6f6
Author:    Guoxiong Li <lgxbslgx at gmail.com>
Committer: Joel Borggr?n-Franck <jfranck at openjdk.org>
Date:      2021-01-26 08:57:20 +0000
URL:       https://git.openjdk.java.net/amber/commit/23edb6f6

8236490: Compiler bug relating to @NonNull annotation

Reviewed-by: vromero, jfranck

! src/jdk.compiler/share/classes/com/sun/tools/javac/code/TypeAnnotationPosition.java
+ test/langtools/tools/javac/annotations/typeAnnotations/8236490/T8236490.java

Changeset: b4ace3e9
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2021-01-26 10:14:53 +0000
URL:       https://git.openjdk.java.net/amber/commit/b4ace3e9

8260042: G1 Post-cleanup liveness printing occurs too early

Reviewed-by: sjohanss, iwalulya

! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp
! src/hotspot/share/gc/g1/g1Policy.cpp

Changeset: 81a66dfa
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2021-01-26 11:50:10 +0000
URL:       https://git.openjdk.java.net/amber/commit/81a66dfa

8259809: Remove PerfEvent class loading locking counters

Reviewed-by: redestad, iklam

! src/hotspot/share/classfile/classLoader.cpp
! src/hotspot/share/classfile/classLoader.hpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/prims/jni.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/runtime/synchronizer.cpp
! src/hotspot/share/runtime/synchronizer.hpp

Changeset: edd27074
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-26 13:04:38 +0000
URL:       https://git.openjdk.java.net/amber/commit/edd27074

8260408: Shenandoah: adjust inline hints after JDK-8255019

Reviewed-by: rkennke, ihse

! make/hotspot/lib/JvmOverrideFiles.gmk

Changeset: e080ce92
Author:    Harold Seigel <hseigel at openjdk.org>
Date:      2021-01-26 13:17:08 +0000
URL:       https://git.openjdk.java.net/amber/commit/e080ce92

8252545: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java timed out

Reviewed-by: stuefe, coleenp

! test/hotspot/jtreg/TEST.groups
! test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java
- test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java

Changeset: 5e8e0ada
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2021-01-26 13:42:40 +0000
URL:       https://git.openjdk.java.net/amber/commit/5e8e0ada

8242456: PreviewFeature.Feature enum removal of TEXT_BLOCKS

Reviewed-by: jlaskey

! src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java

Changeset: 8d2f77fd
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
Date:      2021-01-26 14:08:06 +0000
URL:       https://git.openjdk.java.net/amber/commit/8d2f77fd

8260406: Do not copy pure java source code to gensrc

Reviewed-by: alanb, erikj

! make/modules/java.base/gensrc/GensrcCharacterData.gmk
= src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java
= src/java.base/share/classes/java/lang/CharacterDataUndefined.java

Changeset: af8a08f5
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2021-01-26 15:18:56 +0000
URL:       https://git.openjdk.java.net/amber/commit/af8a08f5

8260378: [TESTBUG] DcmdMBeanTestCheckJni.java reports false positive

Reviewed-by: dcubed

! test/jdk/ProblemList-zgc.txt
! test/jdk/com/sun/management/DiagnosticCommandMBean/DcmdMBeanTestCheckJni.java

Changeset: b07797c2
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2021-01-26 15:25:01 +0000
URL:       https://git.openjdk.java.net/amber/commit/b07797c2

8260391: Remove StringCoding::err

Reviewed-by: shade, rriggs

! src/java.base/share/classes/java/lang/StringCoding.java
- src/java.base/share/native/libjava/StringCoding.c

Changeset: fd00ed74
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2021-01-26 16:46:22 +0000
URL:       https://git.openjdk.java.net/amber/commit/fd00ed74

8256298: Shenandoah: Enable concurrent stack processing

Reviewed-by: rkennke, shade

! src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp
! src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.hpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.hpp
! src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahNMethod.cpp
! src/hotspot/share/gc/shenandoah/shenandoahNMethod.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp
! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.cpp
! src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.hpp
+ src/hotspot/share/gc/shenandoah/shenandoahStackWatermark.cpp
+ src/hotspot/share/gc/shenandoah/shenandoahStackWatermark.hpp
! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.hpp

Changeset: 9f0a0436
Author:    Fernando Guallini <fguallini at openjdk.org>
Committer: Rajan Halade <rhalade at openjdk.org>
Date:      2021-01-26 18:15:26 +0000
URL:       https://git.openjdk.java.net/amber/commit/9f0a0436

8260286: Manual Test "ws/open/test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java" fails

Reviewed-by: rhalade

! test/jdk/sun/security/tools/jarsigner/compatibility/Compatibility.java
! test/jdk/sun/security/tools/jarsigner/warnings/Test.java

Changeset: 42cef27f
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2021-01-26 18:31:26 +0000
URL:       https://git.openjdk.java.net/amber/commit/42cef27f

8260343: Delete obsolete classes in the Windows L&F

Reviewed-by: aivanov, pbansal

- src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsButtonListener.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsComboBoxUI.java
! src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java

Changeset: 1bebd418
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2021-01-26 20:25:51 +0000
URL:       https://git.openjdk.java.net/amber/commit/1bebd418

8260421: Shenandoah: Fix conc_mark_roots timing name and indentations

Reviewed-by: rkennke, shade

! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp

Changeset: 19b6f61b
Author:    Xin Liu <xliu at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2021-01-26 20:52:19 +0000
URL:       https://git.openjdk.java.net/amber/commit/19b6f61b

8260334: Remove deprecated sv_for_node_id() from Compile

Reviewed-by: neliasso, chagedorn, thartmann, phh

! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/output.hpp

Changeset: 6f2be9c6
Author:    David Holmes <dholmes at openjdk.org>
Date:      2021-01-27 01:18:52 +0000
URL:       https://git.openjdk.java.net/amber/commit/6f2be9c6

8246112: Remove build-time and run-time checks for clock_gettime and CLOCK_MONOTONIC

Reviewed-by: ihse, erikj, gziemski, hseigel

! make/autoconf/flags-cflags.m4
! make/autoconf/flags-ldflags.m4
! src/hotspot/os/aix/os_aix.cpp
! src/hotspot/os/aix/os_aix.inline.hpp
! src/hotspot/os/bsd/os_bsd.cpp
! src/hotspot/os/bsd/os_bsd.hpp
! src/hotspot/os/bsd/os_bsd.inline.hpp
! src/hotspot/os/bsd/os_perf_bsd.cpp
! src/hotspot/os/linux/os_linux.cpp
! src/hotspot/os/linux/os_linux.inline.hpp
! src/hotspot/os/posix/os_posix.cpp
! src/hotspot/os/posix/os_posix.hpp
! src/hotspot/os/posix/os_posix.inline.hpp
! src/hotspot/os/windows/os_windows.inline.hpp
! src/hotspot/share/runtime/os.hpp
! src/hotspot/share/runtime/thread.cpp

Changeset: e1411fd4
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2021-01-27 02:52:37 +0000
URL:       https://git.openjdk.java.net/amber/commit/e1411fd4

6606673: Path2D.Double, Path2D.Float and GeneralPath ctors throw exception when initialCapacity is negative

Reviewed-by: psadhukhan, kizune

! src/java.desktop/share/classes/java/awt/geom/GeneralPath.java
! src/java.desktop/share/classes/java/awt/geom/Path2D.java
+ test/jdk/java/awt/geom/GeneralPath/GeneralPathExceptions.java
+ test/jdk/java/awt/geom/Path2D/Path2DExceptions.java

Changeset: c836da38
Author:    Martin Buchholz <martin at openjdk.org>
Date:      2021-01-27 04:31:29 +0000
URL:       https://git.openjdk.java.net/amber/commit/c836da38

8252412: [macos11] system dynamic libraries removed from filesystem

Co-authored-by: Dominik R?ttsches <drott at google.com>
Reviewed-by: jiangli, valeriep

! src/java.smartcardio/unix/classes/sun/security/smartcardio/PlatformPCSC.java

Changeset: bd2744dd
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-27 07:17:30 +0000
URL:       https://git.openjdk.java.net/amber/commit/bd2744dd

8260106: Shenandoah: refactor reference updating closures and related code

Reviewed-by: zgu, rkennke

! src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahMark.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkCompact.cpp
! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.hpp
! src/hotspot/share/gc/shenandoah/shenandoahOopClosures.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp
! src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.cpp

Changeset: 1c770468
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2021-01-27 07:34:46 +0000
URL:       https://git.openjdk.java.net/amber/commit/1c770468

8260404: jvm_io.h include missing in a number of files

Reviewed-by: shade, iklam, dholmes

! src/hotspot/os/posix/perfMemory_posix.cpp
! src/hotspot/share/aot/aotCodeHeap.cpp
! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp
! src/hotspot/share/interpreter/zero/bytecodeInterpreter.cpp
! src/hotspot/share/jfr/jni/jfrUpcalls.cpp
! src/hotspot/share/jfr/leakprofiler/checkpoint/objectSampleDescription.cpp
! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp
! src/hotspot/share/jvmci/jvmciEnv.cpp
! src/hotspot/share/jvmci/jvmciRuntime.hpp
! src/hotspot/share/memory/metaspaceShared.cpp
! src/hotspot/share/oops/klass.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/parse2.cpp
! src/hotspot/share/prims/methodHandles.cpp
! src/hotspot/share/runtime/handshake.cpp

Changeset: fd2641ed
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2021-01-27 07:57:32 +0000
URL:       https://git.openjdk.java.net/amber/commit/fd2641ed

8260236: better init AnnotationCollector _contended_group

Reviewed-by: coleenp, shade

! src/hotspot/share/classfile/classFileParser.cpp

Changeset: 4d004c94
Author:    Roman Kennke <rkennke at openjdk.org>
Date:      2021-01-27 09:32:08 +0000
URL:       https://git.openjdk.java.net/amber/commit/4d004c94

8260449: Remove stale declaration of SATBMarkQueue::apply_closure_and_empty()

Reviewed-by: tschatzl

! src/hotspot/share/gc/shared/satbMarkQueue.hpp

Changeset: fa40a966
Author:    Albert Mingkun Yang <ayang at openjdk.org>
Committer: Stefan Johansson <sjohanss at openjdk.org>
Date:      2021-01-27 09:57:24 +0000
URL:       https://git.openjdk.java.net/amber/commit/fa40a966

8253420: Refactor HeapRegionManager::find_highest_free

Reviewed-by: sjohanss, kbarrett

! src/hotspot/share/gc/g1/heapRegionManager.cpp

Changeset: 3e4194c4
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2021-01-27 10:43:04 +0000
URL:       https://git.openjdk.java.net/amber/commit/3e4194c4

8260022: [ppc] os::print_function_and_library_name shall resolve function descriptors transparently

Reviewed-by: mdoerr, lucy

! src/hotspot/cpu/ppc/assembler_ppc.hpp
! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp
! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.hpp
! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp
! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.hpp
! src/hotspot/share/runtime/os.cpp

Changeset: bf15c709
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-27 10:48:32 +0000
URL:       https://git.openjdk.java.net/amber/commit/bf15c709

8260460: GitHub actions still fail on Linux x86_32 with "Could not configure libc6:i386"

Reviewed-by: ihse

! .github/workflows/submit.yml

Changeset: b3c8a528
Author:    Jan Lahoda <jlahoda at openjdk.org>
Date:      2021-01-27 11:00:12 +0000
URL:       https://git.openjdk.java.net/amber/commit/b3c8a528

8259050: Error recovery in lexer could be improved

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java
! test/langtools/tools/javac/lexer/JavaLexerTest.java
! test/langtools/tools/javac/parser/JavacParserTest.java

Changeset: e696baab
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2021-01-27 11:30:28 +0000
URL:       https://git.openjdk.java.net/amber/commit/e696baab

8260448: Simplify ManagementFactory$PlatformMBeanFinder

Reviewed-by: mchung, dfuchs

! src/java.management/share/classes/java/lang/management/ManagementFactory.java

Changeset: 7ed591cc
Author:    Alexey Ivanov <aivanov at openjdk.org>
Date:      2021-01-27 12:09:48 +0000
URL:       https://git.openjdk.java.net/amber/commit/7ed591cc

8260314: Replace border="1" on tables with CSS

Reviewed-by: serb

! src/java.desktop/share/classes/java/awt/doc-files/DesktopProperties.html
! src/java.desktop/share/classes/java/awt/doc-files/Modality.html
! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/gif_metadata.html
! src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html
! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/componentProperties.html
! src/java.desktop/share/classes/javax/swing/plaf/synth/doc-files/synthFileFormat.html

Changeset: ac276bb3
Author:    Chris Hegarty <chegar at openjdk.org>
Date:      2021-01-27 14:09:15 +0000
URL:       https://git.openjdk.java.net/amber/commit/ac276bb3

8257074: Update the ByteBuffers micro benchmark

Reviewed-by: redestad, dfuchs, jvernee, bpb

! test/micro/org/openjdk/bench/java/nio/ByteBuffers.java
! test/micro/org/openjdk/bench/java/nio/CharBuffers.java
+ test/micro/org/openjdk/bench/java/nio/DoubleBuffers.java
+ test/micro/org/openjdk/bench/java/nio/FloatBuffers.java
+ test/micro/org/openjdk/bench/java/nio/IntBuffers.java
+ test/micro/org/openjdk/bench/java/nio/LongBuffers.java
+ test/micro/org/openjdk/bench/java/nio/ShortBuffers.java
+ test/micro/org/openjdk/bench/java/nio/X-Buffers-bin.java.template
+ test/micro/org/openjdk/bench/java/nio/X-Buffers.java.template
+ test/micro/org/openjdk/bench/java/nio/X-ByteBuffers-bin.java.template
+ test/micro/org/openjdk/bench/java/nio/genBuffers.sh

Changeset: f353fcf2
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
Date:      2021-01-27 15:08:39 +0000
URL:       https://git.openjdk.java.net/amber/commit/f353fcf2

8258894: C2: Forbid GCM to move stores into loops

Prevent GCM from placing memory-writing nodes (such as stores) into loops deeper
than their home loop (determined by their control input). Such placements are
invalid, as they cause memory definitions to interfere, and risk causing
miscompilations. This change complements JDK-8255763, which only addresses
invalid placements in irreducible CFGs.

Add control input to stores in generated stubs to ensure that all memory-writing
nodes have control inputs from which their home block can be derived.

Add a battery of simplified fuzzer test cases where, before this change, GCM
moves stores into deeper loops.

Reviewed-by: thartmann, kvn

! src/hotspot/share/opto/block.cpp
! src/hotspot/share/opto/block.hpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/gcm.cpp
! src/hotspot/share/opto/generateOptoStub.cpp
! src/hotspot/share/opto/node.hpp
! test/hotspot/jtreg/compiler/codegen/TestGCMStorePlacement.java

Changeset: 311a0a91
Author:    Denghui Dong <ddong at openjdk.org>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
Date:      2021-01-27 15:28:46 +0000
URL:       https://git.openjdk.java.net/amber/commit/311a0a91

8259808: Add JFR event to detect GC locker stall

Reviewed-by: sjohanss, tschatzl, egahlin

! src/hotspot/share/gc/shared/gcLocker.cpp
! src/hotspot/share/gc/shared/gcTrace.hpp
! src/hotspot/share/gc/shared/gcTraceSend.cpp
! src/hotspot/share/jfr/metadata/metadata.xml
! src/hotspot/share/prims/whitebox.cpp
! src/jdk.jfr/share/conf/jfr/default.jfc
! src/jdk.jfr/share/conf/jfr/profile.jfc
+ test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java
! test/lib/jdk/test/lib/jfr/EventNames.java
! test/lib/sun/hotspot/WhiteBox.java

Changeset: 684c8558
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2021-01-27 17:26:41 +0000
URL:       https://git.openjdk.java.net/amber/commit/684c8558

8260524: validate-source fails on test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java

Reviewed-by: bpb, iignatyev

! src/hotspot/share/gc/shared/gcLocker.cpp
! src/hotspot/share/gc/shared/gcTrace.hpp
! src/hotspot/share/gc/shared/gcTraceSend.cpp
! src/hotspot/share/jfr/metadata/metadata.xml
! src/hotspot/share/prims/whitebox.cpp
! test/jdk/jdk/jfr/event/gc/detailed/TestGCLockerEvent.java
! test/lib/jdk/test/lib/jfr/EventNames.java
! test/lib/sun/hotspot/WhiteBox.java

Changeset: 0eed2c33
Author:    Guoxiong Li <lgxbslgx at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
Date:      2021-01-27 18:12:57 +0000
URL:       https://git.openjdk.java.net/amber/commit/0eed2c33

8259359: javac does not attribute unexpected super constructor invocation qualifier, and may crash

Reviewed-by: vromero

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
+ test/langtools/tools/javac/recovery/T8259359.java

Changeset: eb923685
Author:    Stuart Marks <smarks at openjdk.org>
Date:      2021-01-27 19:02:49 +0000
URL:       https://git.openjdk.java.net/amber/commit/eb923685

8259816: Typo in java.util.stream package description

Reviewed-by: iris, lancea, naoto

! src/java.base/share/classes/java/util/stream/package-info.java

Changeset: c5ab7c32
Author:    Christian Hagedorn <chagedorn at openjdk.org>
Date:      2021-01-25 17:09:52 +0000
URL:       https://git.openjdk.java.net/amber/commit/c5ab7c32

8260284: C2: assert(_base == Int) failed: Not an Int

Reviewed-by: thartmann, kvn

! src/hotspot/share/opto/phaseX.cpp
+ test/hotspot/jtreg/compiler/loopopts/TestDivWithTopDivisor.java

Changeset: 81e730e5
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
Date:      2021-01-25 20:02:56 +0000
URL:       https://git.openjdk.java.net/amber/commit/81e730e5

8259276: C2: Empty expression stack when reexecuting tableswitch/lookupswitch instructions after deoptimization

Reviewed-by: dlong, kvn, thartmann

! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/parse2.cpp

Changeset: 408772c9
Author:    Vicente Romero <vromero at openjdk.org>
Date:      2021-01-26 16:00:41 +0000
URL:       https://git.openjdk.java.net/amber/commit/408772c9

8259025: Record compact constructor using Objects.requireNonNull

Reviewed-by: mcimadamore

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! test/langtools/tools/javac/records/RecordCompilationTests.java

Changeset: c52212b1
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
Date:      2021-01-27 20:56:26 +0000
URL:       https://git.openjdk.java.net/amber/commit/c52212b1

Merge

! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/parse2.cpp
! src/hotspot/share/opto/phaseX.cpp
! src/hotspot/share/opto/graphKit.cpp
! src/hotspot/share/opto/parse2.cpp
! src/hotspot/share/opto/phaseX.cpp

Changeset: c7661aed
Author:    Roger Riggs <rriggs at openjdk.org>
Date:      2021-01-27 22:37:43 +0000
URL:       https://git.openjdk.java.net/amber/commit/c7661aed

8260561: [doc] HexFormat has incorrect @since tag

Reviewed-by: darcy, naoto, bpb, lancea

! src/java.base/share/classes/java/util/HexFormat.java

Changeset: 7030d2e0
Author:    Hamlin Li <mli at openjdk.org>
Date:      2021-01-28 00:45:16 +0000
URL:       https://git.openjdk.java.net/amber/commit/7030d2e0

8260200: G1: Remove unnecessary update in FreeRegionList::remove_starting_at

Reviewed-by: ayang, sjohanss, tschatzl

! src/hotspot/share/gc/g1/heapRegionSet.cpp
! src/hotspot/share/gc/g1/heapRegionSet.hpp

Changeset: e28e1111
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
Date:      2021-01-27 10:29:59 +0000
URL:       https://git.openjdk.java.net/amber/commit/e28e1111

8260370: C2: LoopLimit node is not eliminated

Reviewed-by: kvn, thartmann

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/loopnode.cpp

Changeset: 62ffe75b
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
Date:      2021-01-28 03:38:32 +0000
URL:       https://git.openjdk.java.net/amber/commit/62ffe75b

Merge

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/loopnode.cpp

Changeset: 396a496f
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2021-01-28 04:24:04 +0000
URL:       https://git.openjdk.java.net/amber/commit/396a496f

8260467: Move well-known classes from systemDictionary.hpp to vmClasses.hpp

Reviewed-by: dholmes, coleenp

! src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp
! src/hotspot/cpu/aarch64/methodHandles_aarch64.hpp
! src/hotspot/cpu/arm/methodHandles_arm.cpp
! src/hotspot/cpu/arm/methodHandles_arm.hpp
! src/hotspot/cpu/ppc/methodHandles_ppc.cpp
! src/hotspot/cpu/ppc/methodHandles_ppc.hpp
! src/hotspot/cpu/s390/methodHandles_s390.cpp
! src/hotspot/cpu/s390/methodHandles_s390.hpp
! src/hotspot/cpu/x86/methodHandles_x86.cpp
! src/hotspot/cpu/x86/methodHandles_x86.hpp
! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/ci/ciEnv.hpp
! src/hotspot/share/ci/ciObjArrayKlass.cpp
! src/hotspot/share/ci/ciObjectFactory.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/classfile/systemDictionaryShared.hpp
+ src/hotspot/share/classfile/vmClassID.hpp
+ src/hotspot/share/classfile/vmClassMacros.hpp
+ src/hotspot/share/classfile/vmClasses.cpp
+ src/hotspot/share/classfile/vmClasses.hpp
! src/hotspot/share/memory/archiveBuilder.cpp
! src/hotspot/share/memory/archiveBuilder.hpp
! src/hotspot/share/memory/filemap.cpp
! src/hotspot/share/memory/metaspaceShared.cpp
! src/hotspot/share/memory/universe.hpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/prims/methodHandles.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/hotspot/share/utilities/vmEnums.hpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/SystemDictionary.java
! test/hotspot/jtreg/serviceability/sa/ClhsdbPrintStatics.java

Changeset: 11a70d11
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2021-01-28 07:35:58 +0000
URL:       https://git.openjdk.java.net/amber/commit/11a70d11

8260426: awt debug_mem.c DMem_AllocateBlock might leak memory

Reviewed-by: psadhukhan, aivanov

! src/java.desktop/share/native/common/awt/debug/debug_mem.c

Changeset: 316d52c1
Author:    Roman Kennke <rkennke at openjdk.org>
Date:      2021-01-28 09:50:21 +0000
URL:       https://git.openjdk.java.net/amber/commit/316d52c1

8260497: Shenandoah: Improve SATB flushing

Reviewed-by: shade, zgu

! src/hotspot/share/gc/shared/satbMarkQueue.hpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp
! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp
! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahSATBMarkQueueSet.hpp
! src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp
! src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp

Changeset: a97aedff
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-28 10:24:37 +0000
URL:       https://git.openjdk.java.net/amber/commit/a97aedff

8256215: Shenandoah: re-organize saving/restoring machine state in assembler code

Reviewed-by: rkennke, zgu

! src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp

Changeset: ecde52ec
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2021-01-28 11:13:26 +0000
URL:       https://git.openjdk.java.net/amber/commit/ecde52ec

8260506: VersionHelper cleanup

Reviewed-by: alanb, dfuchs, aefimov

! src/java.naming/share/classes/com/sun/naming/internal/VersionHelper.java

Changeset: 8fe1323d
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2021-01-28 11:14:35 +0000
URL:       https://git.openjdk.java.net/amber/commit/8fe1323d

8260520: Avoid getting permissions in JarFileFactory when no SecurityManager installed

Reviewed-by: alanb, dfuchs, michaelm, mullan

! src/java.base/unix/classes/sun/net/www/protocol/jar/JarFileFactory.java
! src/java.base/windows/classes/sun/net/www/protocol/jar/JarFileFactory.java

Changeset: 87522573
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2021-01-28 11:39:06 +0000
URL:       https://git.openjdk.java.net/amber/commit/87522573

8260502: [s390] NativeMovRegMem::verify() fails because it's too strict

Reviewed-by: lucy, rrich

! src/hotspot/cpu/s390/nativeInst_s390.cpp
! src/hotspot/cpu/s390/nativeInst_s390.hpp

Changeset: a68c6c2a
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-28 12:00:59 +0000
URL:       https://git.openjdk.java.net/amber/commit/a68c6c2a

8260579: PPC64 and S390 builds failures after JDK-8260467

Reviewed-by: mdoerr

! src/hotspot/cpu/ppc/methodHandles_ppc.cpp
! src/hotspot/cpu/s390/methodHandles_s390.cpp

Changeset: d07af2b8
Author:    Jorn Vernee <jvernee at openjdk.org>
Date:      2021-01-28 12:26:32 +0000
URL:       https://git.openjdk.java.net/amber/commit/d07af2b8

8255531: MethodHandles::permuteArguments throws NPE when duplicating dropped arguments

Reviewed-by: redestad

! src/java.base/share/classes/java/lang/invoke/LambdaFormBuffer.java
! test/jdk/java/lang/invoke/MethodHandlesPermuteArgumentsTest.java

Changeset: 11d6467c
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2021-01-28 12:27:40 +0000
URL:       https://git.openjdk.java.net/amber/commit/11d6467c

8260407: cmp != __null && cmp->Opcode() == Op_CmpL failure with -XX:StressLongCountedLoop=200000000 in lucene

Reviewed-by: thartmann, kvn

! src/hotspot/share/opto/loopopts.cpp
+ test/hotspot/jtreg/compiler/longcountedloops/TestLongCountedLoopSplitIf.java

Changeset: 20e7df50
Author:    Harold Seigel <hseigel at openjdk.org>
Date:      2021-01-28 13:17:22 +0000
URL:       https://git.openjdk.java.net/amber/commit/20e7df50

8260466: Test TestHeapDumpOnOutOfMemoryError.java needs multiple @test sections

Reviewed-by: shade, lmesnik

! test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java

Changeset: baf46bac
Author:    Sean Mullan <mullan at openjdk.org>
Date:      2021-01-28 14:28:27 +0000
URL:       https://git.openjdk.java.net/amber/commit/baf46bac

8259801: Enable XML Signature secure validation mode by default

Reviewed-by: weijun, rhalade

! src/java.base/share/conf/security/java.security
! src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/dom/DOMValidateContext.java
! test/jdk/javax/xml/crypto/dsig/GenerationTests.java

Changeset: 13ca433f
Author:    Patrick Concannon <pconcannon at openjdk.org>
Date:      2021-01-28 15:01:38 +0000
URL:       https://git.openjdk.java.net/amber/commit/13ca433f

8259628: jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java fails intermittently

Reviewed-by: dfuchs

! test/jdk/jdk/net/ExtendedSocketOption/AsynchronousSocketChannelNAPITest.java

Changeset: abc4300d
Author:    Poonam Bajaj <poonam at openjdk.org>
Date:      2021-01-28 15:07:03 +0000
URL:       https://git.openjdk.java.net/amber/commit/abc4300d

8257746: Regression introduced with JDK-8250984 - memory might be null in some machines

Reviewed-by: hseigel

! src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java

Changeset: 3aabbd72
Author:    Matthias Baesken <mbaesken at openjdk.org>
Date:      2021-01-28 15:20:57 +0000
URL:       https://git.openjdk.java.net/amber/commit/3aabbd72

8260432: allocateSpaceForGP in freetypeScaler.c might leak memory

Reviewed-by: shade, stuefe

! src/java.desktop/share/native/libfontmanager/freetypeScaler.c

Changeset: bbbfaa58
Author:    Calvin Cheung <ccheung at openjdk.org>
Date:      2021-01-28 16:17:46 +0000
URL:       https://git.openjdk.java.net/amber/commit/bbbfaa58

8249262: Initialize InstanceKlass::_package_entry during CDS dump time

Reviewed-by: iklam, minqi

! src/hotspot/share/classfile/classLoaderDataShared.cpp
! src/hotspot/share/classfile/classLoaderDataShared.hpp
! src/hotspot/share/classfile/packageEntry.cpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/classfile/systemDictionaryShared.hpp
! src/hotspot/share/memory/metaspaceShared.cpp
! src/hotspot/share/oops/instanceKlass.cpp

Changeset: 1de3c554
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-28 16:31:45 +0000
URL:       https://git.openjdk.java.net/amber/commit/1de3c554

8260584: Shenandoah: simplify "Concurrent Thread Roots" logging

Reviewed-by: rkennke, zgu

! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp

Changeset: 2b166d81
Author:    Weijun Wang <weijun at openjdk.org>
Date:      2021-01-28 17:54:09 +0000
URL:       https://git.openjdk.java.net/amber/commit/2b166d81

8260596: Comment cleanup in BigInteger

Reviewed-by: bpb

! src/java.base/share/classes/java/math/BigInteger.java

Changeset: 81e9e6a7
Author:    Martin Buchholz <martin at openjdk.org>
Date:      2021-01-28 18:06:55 +0000
URL:       https://git.openjdk.java.net/amber/commit/81e9e6a7

8260461: Modernize jsr166 tck tests

Reviewed-by: dl

! test/jdk/java/util/concurrent/tck/AbstractExecutorServiceTest.java
! test/jdk/java/util/concurrent/tck/AbstractQueueTest.java
! test/jdk/java/util/concurrent/tck/ArrayBlockingQueueTest.java
! test/jdk/java/util/concurrent/tck/ArrayDeque8Test.java
! test/jdk/java/util/concurrent/tck/ArrayDequeTest.java
! test/jdk/java/util/concurrent/tck/ArrayListTest.java
! test/jdk/java/util/concurrent/tck/Atomic8Test.java
! test/jdk/java/util/concurrent/tck/AtomicBooleanTest.java
! test/jdk/java/util/concurrent/tck/AtomicIntegerArrayTest.java
! test/jdk/java/util/concurrent/tck/AtomicIntegerTest.java
! test/jdk/java/util/concurrent/tck/AtomicLongArrayTest.java
! test/jdk/java/util/concurrent/tck/AtomicLongTest.java
! test/jdk/java/util/concurrent/tck/AtomicMarkableReferenceTest.java
! test/jdk/java/util/concurrent/tck/AtomicReference9Test.java
! test/jdk/java/util/concurrent/tck/AtomicReferenceArray9Test.java
! test/jdk/java/util/concurrent/tck/AtomicReferenceArrayTest.java
! test/jdk/java/util/concurrent/tck/AtomicReferenceFieldUpdaterTest.java
! test/jdk/java/util/concurrent/tck/AtomicReferenceTest.java
! test/jdk/java/util/concurrent/tck/AtomicStampedReferenceTest.java
! test/jdk/java/util/concurrent/tck/BlockingQueueTest.java
! test/jdk/java/util/concurrent/tck/Collection8Test.java
! test/jdk/java/util/concurrent/tck/CompletableFutureTest.java
! test/jdk/java/util/concurrent/tck/ConcurrentHashMap8Test.java
! test/jdk/java/util/concurrent/tck/ConcurrentHashMapTest.java
! test/jdk/java/util/concurrent/tck/ConcurrentLinkedDequeTest.java
! test/jdk/java/util/concurrent/tck/ConcurrentLinkedQueueTest.java
! test/jdk/java/util/concurrent/tck/ConcurrentSkipListMapTest.java
! test/jdk/java/util/concurrent/tck/ConcurrentSkipListSetTest.java
! test/jdk/java/util/concurrent/tck/ConcurrentSkipListSubMapTest.java
! test/jdk/java/util/concurrent/tck/ConcurrentSkipListSubSetTest.java
! test/jdk/java/util/concurrent/tck/CopyOnWriteArrayListTest.java
! test/jdk/java/util/concurrent/tck/CopyOnWriteArraySetTest.java
! test/jdk/java/util/concurrent/tck/CountedCompleterTest.java
! test/jdk/java/util/concurrent/tck/DelayQueueTest.java
! test/jdk/java/util/concurrent/tck/ExchangerTest.java
! test/jdk/java/util/concurrent/tck/ExecutorCompletionService9Test.java
! test/jdk/java/util/concurrent/tck/ExecutorCompletionServiceTest.java
! test/jdk/java/util/concurrent/tck/ExecutorsTest.java
! test/jdk/java/util/concurrent/tck/ForkJoinPool8Test.java
! test/jdk/java/util/concurrent/tck/ForkJoinPoolTest.java
! test/jdk/java/util/concurrent/tck/ForkJoinTask8Test.java
! test/jdk/java/util/concurrent/tck/ForkJoinTaskTest.java
! test/jdk/java/util/concurrent/tck/FutureTaskTest.java
+ test/jdk/java/util/concurrent/tck/Item.java
! test/jdk/java/util/concurrent/tck/JSR166TestCase.java
! test/jdk/java/util/concurrent/tck/LinkedBlockingDeque8Test.java
! test/jdk/java/util/concurrent/tck/LinkedBlockingDequeTest.java
! test/jdk/java/util/concurrent/tck/LinkedBlockingQueue8Test.java
! test/jdk/java/util/concurrent/tck/LinkedBlockingQueueTest.java
! test/jdk/java/util/concurrent/tck/LinkedListTest.java
! test/jdk/java/util/concurrent/tck/LinkedTransferQueueTest.java
! test/jdk/java/util/concurrent/tck/MapTest.java
! test/jdk/java/util/concurrent/tck/NonNestmates.java
! test/jdk/java/util/concurrent/tck/PhaserTest.java
! test/jdk/java/util/concurrent/tck/PriorityBlockingQueueTest.java
! test/jdk/java/util/concurrent/tck/PriorityQueueTest.java
! test/jdk/java/util/concurrent/tck/RecursiveActionTest.java
! test/jdk/java/util/concurrent/tck/RecursiveTaskTest.java
! test/jdk/java/util/concurrent/tck/ScheduledExecutorSubclassTest.java
! test/jdk/java/util/concurrent/tck/ScheduledExecutorTest.java
! test/jdk/java/util/concurrent/tck/StampedLockTest.java
! test/jdk/java/util/concurrent/tck/SubmissionPublisherTest.java
! test/jdk/java/util/concurrent/tck/SynchronousQueueTest.java
! test/jdk/java/util/concurrent/tck/ThreadLocalTest.java
! test/jdk/java/util/concurrent/tck/ThreadPoolExecutorSubclassTest.java
! test/jdk/java/util/concurrent/tck/ThreadPoolExecutorTest.java
! test/jdk/java/util/concurrent/tck/TreeMapTest.java
! test/jdk/java/util/concurrent/tck/TreeSetTest.java
! test/jdk/java/util/concurrent/tck/TreeSubMapTest.java
! test/jdk/java/util/concurrent/tck/TreeSubSetTest.java
! test/jdk/java/util/concurrent/tck/VectorTest.java

Changeset: 71128cf4
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2021-01-28 19:04:50 +0000
URL:       https://git.openjdk.java.net/amber/commit/71128cf4

8260586: Shenandoah: simplify "Concurrent Weak References" logging

Reviewed-by: rkennke, zgu

! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp

Changeset: 15196325
Author:    Igor Veresov <iveresov at openjdk.org>
Date:      2021-01-28 20:51:12 +0000
URL:       https://git.openjdk.java.net/amber/commit/15196325

8251462: Simplify compilation policy

Reviewed-by: cjplummer, kvn

! src/hotspot/cpu/aarch64/c1_LIRGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/c1_globals_aarch64.hpp
! src/hotspot/cpu/aarch64/c2_globals_aarch64.hpp
! src/hotspot/cpu/aarch64/gc/shenandoah/c1/shenandoahBarrierSetC1_aarch64.cpp
! src/hotspot/cpu/aarch64/globals_aarch64.hpp
! src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/templateTable_aarch64.cpp
! src/hotspot/cpu/arm/globals_arm.hpp
! src/hotspot/cpu/arm/templateInterpreterGenerator_arm.cpp
! src/hotspot/cpu/arm/templateTable_arm.cpp
! src/hotspot/cpu/ppc/c1_globals_ppc.hpp
! src/hotspot/cpu/ppc/c2_globals_ppc.hpp
! src/hotspot/cpu/ppc/interp_masm_ppc.hpp
! src/hotspot/cpu/ppc/interp_masm_ppc_64.cpp
! src/hotspot/cpu/ppc/templateInterpreterGenerator_ppc.cpp
! src/hotspot/cpu/ppc/templateTable_ppc_64.cpp
! src/hotspot/cpu/s390/c1_globals_s390.hpp
! src/hotspot/cpu/s390/c2_globals_s390.hpp
! src/hotspot/cpu/s390/templateInterpreterGenerator_s390.cpp
! src/hotspot/cpu/s390/templateTable_s390.cpp
! src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp
! src/hotspot/cpu/x86/c1_globals_x86.hpp
! src/hotspot/cpu/x86/c2_globals_x86.hpp
! src/hotspot/cpu/x86/globalDefinitions_x86.hpp
! src/hotspot/cpu/x86/globals_x86.hpp
! src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
! src/hotspot/cpu/x86/templateTable_x86.cpp
! src/hotspot/cpu/x86/vm_version_x86.cpp
! src/hotspot/cpu/zero/globals_zero.hpp
! src/hotspot/share/aot/aotCodeHeap.cpp
! src/hotspot/share/aot/aotCompiledMethod.cpp
! src/hotspot/share/aot/aotCompiledMethod.hpp
! src/hotspot/share/c1/c1_Compilation.cpp
! src/hotspot/share/c1/c1_Compilation.hpp
! src/hotspot/share/c1/c1_GraphBuilder.cpp
! src/hotspot/share/c1/c1_LIRAssembler.cpp
! src/hotspot/share/c1/c1_LIRGenerator.cpp
! src/hotspot/share/c1/c1_Runtime1.cpp
! src/hotspot/share/c1/c1_globals.hpp
! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/ci/ciEnv.hpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/ci/ciReplay.cpp
! src/hotspot/share/code/codeCache.cpp
! src/hotspot/share/code/codeCache.hpp
! src/hotspot/share/compiler/compilationPolicy.cpp
! src/hotspot/share/compiler/compilationPolicy.hpp
! src/hotspot/share/compiler/compileBroker.cpp
! src/hotspot/share/compiler/compileTask.cpp
! src/hotspot/share/compiler/compilerDefinitions.cpp
! src/hotspot/share/compiler/compilerDefinitions.hpp
! src/hotspot/share/compiler/compilerDirectives.cpp
! src/hotspot/share/compiler/compiler_globals.hpp
! src/hotspot/share/compiler/oopMap.cpp
- src/hotspot/share/compiler/tieredThresholdPolicy.cpp
- src/hotspot/share/compiler/tieredThresholdPolicy.hpp
! src/hotspot/share/gc/shared/cardTableBarrierSet.cpp
! src/hotspot/share/gc/shared/genCollectedHeap.cpp
! src/hotspot/share/gc/shared/referenceProcessor.cpp
! src/hotspot/share/gc/shared/threadLocalAllocBuffer.cpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp
! src/hotspot/share/interpreter/interpreterRuntime.hpp
! src/hotspot/share/interpreter/invocationCounter.cpp
! src/hotspot/share/interpreter/invocationCounter.hpp
! src/hotspot/share/interpreter/templateInterpreterGenerator.hpp
! src/hotspot/share/jvmci/compilerRuntime.cpp
! src/hotspot/share/jvmci/jvmciCompiler.cpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/oops/method.hpp
! src/hotspot/share/oops/methodCounters.cpp
! src/hotspot/share/oops/methodCounters.hpp
! src/hotspot/share/oops/methodData.cpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/abstract_vm_version.cpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/flags/jvmFlagConstraintsCompiler.cpp
! src/hotspot/share/runtime/globals_shared.hpp
! src/hotspot/share/runtime/safepoint.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/hotspot/share/utilities/macros.hpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/Method.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodCounters.java
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/oops/MethodData.java
! test/hotspot/jtreg/TEST.quick-groups
! test/hotspot/jtreg/compiler/jvmci/compilerToVM/MaterializeVirtualObjectTest.java
! test/hotspot/jtreg/compiler/whitebox/ClearMethodStateTest.java
! test/hotspot/jtreg/compiler/whitebox/CompilerWhiteBoxTest.java
- test/hotspot/jtreg/vmTestbase/jit/tiered/Test.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/MyThread.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/hotswap/HS203/hs203t004/hs203t004.java

Changeset: 98fa71a5
Author:    duke <duke at openjdk.org>
Date:      2021-01-28 22:01:52 +0000
URL:       https://git.openjdk.java.net/amber/commit/98fa71a5

Automatic merge of master into stats-before-this-super

! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java


From scolebourne at joda.org  Thu Jan 28 22:45:32 2021
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 28 Jan 2021 22:45:32 +0000
Subject: Feedback: Guards and static/instance pattern declarations
In-Reply-To: <be02d61b-ea8c-c2c4-9822-a4b27decd7ce@oracle.com>
References: <CACzrW9Cueut29tXJQDh+H-eKW-ktSJ2Ly8yBdgaBUuJUOyFZpQ@mail.gmail.com>
 <be02d61b-ea8c-c2c4-9822-a4b27decd7ce@oracle.com>
Message-ID: <CACzrW9CWJ+OBQ7YPT06QN0XffrEmYfwHNqOpGQRHc=GHrUucpQ@mail.gmail.com>

On Thu, 28 Jan 2021 at 19:19, Brian Goetz <brian.goetz at oracle.com> wrote:
> Here's a more concrete example of where this approach starts to lose it
> when we get past trivial guards.   If we try to interpret an arbitrary
> boolean expression as pattern, when it is the right operand of a &&
> whose left operand is a pattern, what do we do with this:
>
>       t instanceof Foo(var x) && x instanceof Bar(var y) && Q:
>
> `x instanceof Bar(var y)` is surely an allowable boolean expression, but
> now it is really not clear whether the user meant to match t to Foo(var
> x) and to Q, subject to the guard that x is a Bar(var y), or meant to do
> to separate instanceof tests, the second to "Bar(var y) && Q".

>From this, I understand that the main problem is how to determine
which target applies to Q - t or x.

I agree that in general this is a real problem as the syntax is
currently structured. I also think that for complex patterns, there is
probably no avoiding the problem. But here are a 2 orthogonal
thoughts:

1) Use when instead of true/false

  t instanceof (Foo(var x) & when(x instanceof Bar(var y)) & Q)

This reads more naturally and looks less artificial. I'm not convinced
having the choice of true or false to write a guard is actually that
helpful anyway - if statements and ternary expressions don't have a
choice of a true and a false version.


2) Treat patterns more like objects:

Build on normal method chaining and params:

  if (t instanceof Foo(var x).and(x instanceof Bar(var y)).and(Q)) {...}
vs
  if (t instanceof Foo(var x).and(x instanceof Bar(var y).and(Q))) {...}

This has the same basic idea as `containsKey(k).get(var v)`. Allowing
different bits of a pattern to be flexibly joined as though by method
call. I recognise that this is a leap in how patterns are designed,
but making parts of a pattern combine like library methods does seems
like a win as it builds on existing knowledge of method chaining. If a
genuine pattern object is created (that can be assigned to a local
variable) then this becomes an even more natural way to think about
the problem. (Lambdas aren't special, they are just objects. That is a
key part of why they fit into Java so well. I think patterns deserve
the same treatment)

Stephen

From brian.goetz at oracle.com  Thu Jan 28 22:57:57 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 28 Jan 2021 17:57:57 -0500
Subject: Feedback: Guards and static/instance pattern declarations
In-Reply-To: <CACzrW9CWJ+OBQ7YPT06QN0XffrEmYfwHNqOpGQRHc=GHrUucpQ@mail.gmail.com>
References: <CACzrW9Cueut29tXJQDh+H-eKW-ktSJ2Ly8yBdgaBUuJUOyFZpQ@mail.gmail.com>
 <be02d61b-ea8c-c2c4-9822-a4b27decd7ce@oracle.com>
 <CACzrW9CWJ+OBQ7YPT06QN0XffrEmYfwHNqOpGQRHc=GHrUucpQ@mail.gmail.com>
Message-ID: <f8ad25cb-68cb-67ba-57ae-ce43856a36f8@oracle.com>



On 1/28/2021 5:45 PM, Stephen Colebourne wrote:
> On Thu, 28 Jan 2021 at 19:19, Brian Goetz <brian.goetz at oracle.com> wrote:
>> Here's a more concrete example of where this approach starts to lose it
>> when we get past trivial guards.   If we try to interpret an arbitrary
>> boolean expression as pattern, when it is the right operand of a &&
>> whose left operand is a pattern, what do we do with this:
>>
>>        t instanceof Foo(var x) && x instanceof Bar(var y) && Q:
>>
>> `x instanceof Bar(var y)` is surely an allowable boolean expression, but
>> now it is really not clear whether the user meant to match t to Foo(var
>> x) and to Q, subject to the guard that x is a Bar(var y), or meant to do
>> to separate instanceof tests, the second to "Bar(var y) && Q".
>  From this, I understand that the main problem is how to determine
> which target applies to Q - t or x.

That's not even really the main problem, though that's surely a problem 
that pops out of this particular example.? My point is a broader one, 
which is that, while P&&e is fine as a pattern combinator when there's 
just one pattern and expression, it becomes much harder to disentangle 
what is going on when it's P && e && Q && f, even if the compiler can 
figure out a way to parse it.? The desire to "get rid of the noise" 
(which works fine in trivial cases) creates a bigger problem, which 
makes the code much harder to read.? The cure is to be explicit about 
the boundary between "pattern world" and "expression world."



From scolebourne at joda.org  Thu Jan 28 23:12:55 2021
From: scolebourne at joda.org (Stephen Colebourne)
Date: Thu, 28 Jan 2021 23:12:55 +0000
Subject: Pattern method names based on existing library conventions [was
 Re: Pattern matching for nested List with additional size constraints]
In-Reply-To: <5d3f83f0-e861-a57b-fcd9-0d30f5168c89@oracle.com>
References: <CAGZD2TCbAH+8NzaFfHqqzQQh18Xf2xCbvuzzpj_idH0caWhDzg@mail.gmail.com>
 <ea9187bb-e33f-fc38-9497-33d80ebd5a2d@oracle.com>
 <CACzrW9CWTxv_L2ib6RykS7V23722Ojg6P2_3xo3mV8C062UmRA@mail.gmail.com>
 <5d3f83f0-e861-a57b-fcd9-0d30f5168c89@oracle.com>
Message-ID: <CACzrW9AC-f3ftzca_jcv0J=7ySqfDWK1dmfPUU1i8QFEL9aWOw@mail.gmail.com>

On Thu, 28 Jan 2021 at 16:42, Brian Goetz <brian.goetz at oracle.com> wrote:
> if a class has _only_ one name of factory method (make, newFoo), I think
> the idiom of "deconstruct those with a deconstructor" might be a
> reasonable option, because deconstructors don't need this degree of
> flexibility, and the name chosen by the API designer isn't really adding
> any value, since they're all the same.

The Optional class is weird here. Reading this again, I agree that the
"empty" name is important. But the "of" name is noise. Because I think
Optional is really very record-like.

  switch (opt) {
    case Optional(var v) ...
    case Optional.empty() ...
  }

I understand the shudder from the inconsistency, but I think this is
actually fully consistent.

The criteria for "deconstruct with a deconstructor" should be whether
the class has a single standard internal state that it fully exposes,
just like a record would. If this rule were widely adopted then the
apparent Optional inconsistency wouldn't seem odd at all. All my
examples meet the rule: LocalDate(year, month, day), List(items) and
Map.Entry(key, value).

Stephen

From brian.goetz at oracle.com  Thu Jan 28 23:42:15 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Thu, 28 Jan 2021 18:42:15 -0500
Subject: Pattern method names based on existing library conventions [was
 Re: Pattern matching for nested List with additional size constraints]
In-Reply-To: <CACzrW9AC-f3ftzca_jcv0J=7ySqfDWK1dmfPUU1i8QFEL9aWOw@mail.gmail.com>
References: <CAGZD2TCbAH+8NzaFfHqqzQQh18Xf2xCbvuzzpj_idH0caWhDzg@mail.gmail.com>
 <ea9187bb-e33f-fc38-9497-33d80ebd5a2d@oracle.com>
 <CACzrW9CWTxv_L2ib6RykS7V23722Ojg6P2_3xo3mV8C062UmRA@mail.gmail.com>
 <5d3f83f0-e861-a57b-fcd9-0d30f5168c89@oracle.com>
 <CACzrW9AC-f3ftzca_jcv0J=7ySqfDWK1dmfPUU1i8QFEL9aWOw@mail.gmail.com>
Message-ID: <899b9ba6-61cb-f01d-379d-c6bdfbacc8ed@oracle.com>


> Reading this again, I agree that the
> "empty" name is important. But the "of" name is noise.

While I understand where you are coming from in this particular example, 
I think you are still stuck in the "old" mental model. (Which is 
understandable, you have to give yourself time with it.)

There's a powerful symmetry between `Optional.of(x)` and `case 
Optional.of(var x)`; it underscores the inverse relationship of the two 
members (actually: embedding-projection.)?? I think you are still 
valuing that at zero, when in fact it is worth a lot, and you're tossing 
it away to avoid a few characters of "noise".

To recap: one of the values of this symmetry is that it provides us with 
a basis for interpreting

 ??? case Foo(var x, var y):

as "Could I have constructed this thing from `new Foo(x, y)`, for some x 
and y, and if so, which?"? You don't have to run to the Javadoc to 
understand what the pattern does, because it does exactly the opposite 
of what its dual member does.? (If you actually code like this, the 
duality enables some really powerful things to be mechanically layered 
atop matching ctor/dtor pairs.?? Records will automatically work like 
this.)

To make a possibly bad analogy, one of the few redeeming things about 
the JavaBean coding conventions is that they allowed tools and 
frameworks to reason mechanically about things like "getX and setX refer 
to the same abstract property X" (assuming suitable ad-hoc constraints 
on naming and signatures.)? This allows DSLs to let you say things like 
`x = x + 1` and have it mechanically map to `setX(getX() + 1)`.? Imagine 
the confusion on the part of both users and tools if there was no way to 
relate the getter and setter for a given property without consulting a 
complex decoder chart because arbitrarily different mechanisms were used 
for the two.

I think you're trying to make "locally optimal" choices, which makes 
sense, but when the decisions are related, this may well not result in a 
globally optimal outcome.



From forax at univ-mlv.fr  Fri Jan 29 07:28:04 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 29 Jan 2021 08:28:04 +0100 (CET)
Subject: Pattern method names based on existing library conventions [was
 Re: Pattern matching for nested List with additional size constraints]
In-Reply-To: <CACzrW9AC-f3ftzca_jcv0J=7ySqfDWK1dmfPUU1i8QFEL9aWOw@mail.gmail.com>
References: <CAGZD2TCbAH+8NzaFfHqqzQQh18Xf2xCbvuzzpj_idH0caWhDzg@mail.gmail.com>
 <ea9187bb-e33f-fc38-9497-33d80ebd5a2d@oracle.com>
 <CACzrW9CWTxv_L2ib6RykS7V23722Ojg6P2_3xo3mV8C062UmRA@mail.gmail.com>
 <5d3f83f0-e861-a57b-fcd9-0d30f5168c89@oracle.com>
 <CACzrW9AC-f3ftzca_jcv0J=7ySqfDWK1dmfPUU1i8QFEL9aWOw@mail.gmail.com>
Message-ID: <1192198205.784137.1611905284071.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Stephen Colebourne" <scolebourne at joda.org>
> ?: "amber-dev" <amber-dev at openjdk.java.net>
> Envoy?: Vendredi 29 Janvier 2021 00:12:55
> Objet: Re: Pattern method names based on existing library conventions [was Re: Pattern matching for nested List with
> additional size constraints]

> On Thu, 28 Jan 2021 at 16:42, Brian Goetz <brian.goetz at oracle.com> wrote:
>> if a class has _only_ one name of factory method (make, newFoo), I think
>> the idiom of "deconstruct those with a deconstructor" might be a
>> reasonable option, because deconstructors don't need this degree of
>> flexibility, and the name chosen by the API designer isn't really adding
>> any value, since they're all the same.
> 
> The Optional class is weird here. Reading this again, I agree that the
> "empty" name is important. But the "of" name is noise. Because I think
> Optional is really very record-like.
> 
>  switch (opt) {
>    case Optional(var v) ...
>    case Optional.empty() ...
>  }
> 
> I understand the shudder from the inconsistency, but I think this is
> actually fully consistent.


I think a deconstructor should never be partial but always total.
Here, case Optional(var v) means that the deconstructor is partial.

Having partial deconstructors means that instanceof can return false even if it's the right instance,
which is a surprising semantics in a bad way.

  Object o = Optional.empty();
  ...
  if (o instanceof Optional(var v) {
    // not called
  }



> 
> The criteria for "deconstruct with a deconstructor" should be whether
> the class has a single standard internal state that it fully exposes,
> just like a record would. If this rule were widely adopted then the
> apparent Optional inconsistency wouldn't seem odd at all. All my
> examples meet the rule: LocalDate(year, month, day), List(items) and
> Map.Entry(key, value).
> 
> Stephen

R?mi